Import Export table and alarm delivery troubleshooting procedures for CX, Infinet controllers, and Cyberstation

[Product_Support]

Issue

Import Export table and alarm delivery troubleshooting procedures for CX, Infinet controllers, and Cyberstation

Environment

• CX
• Infinet controllers
• Cyberstation

Cause

The below troubleshooting outline can be used when trying to determine why point values are not being transferred from one controller to another. Also there is a section to troubleshoot why alarms are not being delivered correctly from the controllers.

Resolution

Programming import export problems:

1. Open point editors for the source and destination points, verify whether or not the point value is being transferred.
2. If the values are not being transferred then verify the program that is transferring the values is enabled and active. If the program is disabled then go to the runtime tab and determine why the program is disabled. If the program is not disabled then manually run the program, if it is a fall through, and see if the values update. If the values update when manually running the program then the problem is not an import/export problem but a programming problem.
3. If everything with the programming side of things checks out then get a dumb terminal dump of the source and destination controllers. Use the command “Dump All” at the R prompt through dumb terminal.
4. Look at the Import/Export entries in the source controller’s dump file and see if the Import/Export entry is in the dump file in the Import/Export section of the dump file. The format of the entry should look similar to the below.
5. If the Import/Export entry is in the dump file then the problem is not an import/export problem but more than likely a communications problem. Verify the integrity of the Infinet bus and see if there are any problems there. If the bus integrity looks good then the problem could possibly be an intermittent communications problem. If the transfer of these point values are critical then one recommendation would be to add a “Point refresh” program that runs at certain intervals.
6. If the import/export entry is not in the controller dump file then try selecting the first option, “Do not reload attached objects”, in the “Send to Controller” options and reload the controller. What this will do is resend just the Import/Export table down to the controller.
7. Check to see if the point is now sharing correctly via the point editors. If so then the problem was a corrupt Import/Export entry in the controller. If the problem still exists then go to the next step.
8. If the problem is still there then get another dumb terminal dump of the source and destination controllers and verify whether or not the Import/Export entries are in the controller. If the entries are there then review step 5.
9. If the Import/Export entries are not there then run the Import/Export fix up utility against the database and repeat steps 6 through 8.
10. If after going back to steps 6 through 8 the entry is still not there then backup the database and send it to TSD with all the specifics on the points that are not sharing, controller names that owns the points, and programs that transfer the point values.
11. Open the point transfer program and re-save it. Go back to step 7 only.

Alarm Import/Export problems. The below describes how to check to see if an alarm delivery problem is Import/Export table related.

1. Did the alarm get logged into the database? If the alarm did get logged then this is not an Import/Export problem.
2. If the point is still in alarm does the point editor reflect that the point is in alarm? If not then this is not an Import/Export problem.
3. If the point is in alarm and it is not logged check the NewAlarmCount system variable on the CX level controller. If the value of NewAlarmCount is NOT zero then this is not an Import/Export problem.
4. If the point is in alarm and the NewAlarmCount system variable in the CX is zero and the alarm is not logged then this could be an Import/Export problem.
5. If you disable the point and cycle it out of alarm and then back into alarm does the alarm come in? If the alarm comes in then this is more than likely a communications problem and not an Import/Export problem.
6. Check the Continuum error log and see if there are any errors being posted for the delivery if this alarm.
7. Run the ACCTrace utility, from the workstation that is supposed to be logging the alarm, when cycling the point in and out of alarm. Send trace file to TSD for review. To determine which workstation is logging the alarms use the below calculation: The Netcontroller will take it’s own AccNetid and mask it with 63 stripping off the 2 high bits of it’s id leaving a result in the range of 1 to 63. For those of you who are binary mask challenged, NetControllers with Ids between 1 and 63, result is their ID NetControllers with Ids between 64 and 127, result is their ID - 64 (ID range of 0 to 63) NetControllers with Ids between 128 and 190, result is their ID - 128 (ID range of 0 to 62) That result is then added to 190 and that is the ID of the first Workstation to get the Alarm and Log it in the Database. If there is no Workstation with that ID (or the workstation with that ID is offline), the NetController will send the alarm to the Workstation with the next highest ID above the one calculated by the ratcheting algorithm. If no Workstation Ids are higher than the one calculated, the routine will loop around and use the lowest Workstation ID to send to first.
8. Do a dumb terminal dump of the controller that is having the problem. The command to dump it is “Dump All”. Capture this dump file to a text file and check the Import/Export table section of the dump file. The Import/Export section of the dump file should have an entry for the points that have alarms attached to them. The format of the entry is: pointname to Alarm.
9. If the Import/Export entry is in the dump file then the problem is not an import/export problem but more than likely a communications problem. Verify the integrity of the Infinet bus and see if there are any problems there. If the bus integrity looks good then the problem could possibly be an intermittent communications problem. If the transfer of these point values are critical then one recommendation would be to add a “Point refresh” program that runs at certain intervals.
10. Using the calculation above to determine which workstation is logging the alarm verify that workstation exists in the database. If that workstation does exist in the database make sure that that workstation is pointing to the correct database. We have run into situations where one workstation switches between databases using the same workstation ACCNet ID and IP Address. Doing this will cause problems with alarm and Access Event delivery. If you are doing this kind of installation you must have a unique ACCNet ID and IP address for each database.
11. If the import/export entry is not in the controller dump file then try selecting the first option, “Do not reload attached objects”, in the “Send to Controller” options and reload the controller. What this will do is resend just the Import/Export table down to the controller, it does not reset the controller.
12. Go back and retest the point and see if it goes into alarm and delivers the alarm correctly. If so then the Import/Export entry for the point was corrupted in the controller.
13. If the alarm still is not logged or delivered do step 8 again.
14. If the Import/Export entries are not there then run the Import/Export fix up utility against the database and do steps 10 and 11 again.
15. If the alarm is still not logged then backup the database and send it to TSD with all the specifics on the points that are not sending the alarms. Please include the controller names that owns the point and also what alarm link is not working correctly.
16. Edit the point, remove the alarm attachment and save the point. Then re-edit the point, re-attach the alarm and resave the point. Check and verify that the alarm functions as it should.