Issue What should I set the Access Server System variable to on Continuum access controllers? Environment CX9200, CX99xx, ACX57xx or CX9702 controller with an ACX780 or ACX700 controller. Access Server, AccessServer Cause Below are the different configurations and what their different AccessServer system variable settings mean. Unlike Infinity when changing the setting in the controllers the controller does not reset. It is best if you set the AccessServer setting to the ACC Net ID of the Primary Access server workstation. This will keep the Access Control system operational should there be any distribution problems. Resolution CX9200, CX99xx,  or CX9702 controller with an ACX780 or ACX700 controller. The CX can stay at the default of it’s own ACC Net ID. In the above configuration the AccessServer variable in the CX is ignored. The AccessServer variable in the ACX controller can be one of the following: AccessServer value set to 0 in the ACX (Default setting).This means that access validation of personnel records will only be done locally in the ACX. If the person is not found in the ACX or the person is denied access locally in the ACX the person will not get in. AccessServer in the ACX controller set to the ACC Net ID of the Primary Access Server workstation (valid values are 191-253). This means that access validation of personnel records will be done locally in the ACX first. If the person is not found in the ACX or if the person is denied access the controller will double check at the workstation to verify whether or not the person is supposed to have access. If the person is also denied access at the workstation then the person will not get in. If the AccessServer value in the ACX controller is set to the ACC Net ID of the parent CX controller it has no effect and is ignored. CX99xxor CX9680 controller with AC1 modules  or ACX57xx. The CX can stay at the default of it’s own ACC Net ID.  AccessServer value set to the CX’s own ACC Net ID (Default). This means that access validation of personnel records will only be done locally in the CX. If the person is not found in the CX or the person is denied access locally in the CX the person will not get in. AccessServer value set to the ACC Net ID of the Primary Access Server workstation (valid values are 191-253). This means that access validation of personnel records will be done locally in the CX first. If the person is not found in the CX or if the person is denied access the controller will double check at the workstation to verify whether or not the person is supposed to have access. If the person is also denied access at the workstation then the person will not get in. AccessServer value set to 0. This is not a valid setting for a CX controller.

Issue Renamed SQL server or Single User Cyberstation and now workstation will not connect to the database Environment SQL Server Single User Cyberstation Cause When initially installing the database the computer name is registered as part of the SQL Server/MSDE install. If after the SQL server/MSDE you change the computer name the database will not start up which in turn causes Cyberstation not to start up. Resolution The correct method to change the computer name of the computer running the SQL Server/MSDE database is to: Backup the database Uninstall SQL Server/MSDE Change the computer name Re-install SQL Server/MSDE Re-initialize a blank Continuum database Restore the backup database

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: Open point editors for the source and destination points, verify whether or not the point value is being transferred. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Did the alarm get logged into the database? If the alarm did get logged then this is not an Import/Export problem. 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. 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. 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. 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. Check the Continuum error log and see if there are any errors being posted for the delivery if this alarm. 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. 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. 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. 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. 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. 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. If the alarm still is not logged or delivered do step 8 again. 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. 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. 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.

Issue Continuum BACnet controllers are sending out incorrect or large amounts of unnecessary COV data on the network. Environment Continuum BACnet controllers Cause The Continuum BACnet controllers cannot be programmed the same as the Non BACnet Continuum controllers when it comes to points that are being exported to other controllers. There are 2 main differences that the programmer must be aware of when programming these exported points. Resolution The first difference to be aware of is that in a Continuum BACnet controller every change of the value of an exported point is immediately sent out at the time of the change regardless of when the point changed within the controller program scan. What this means is that unlike standard continuum programming which latches and exports the final value of a point after the entire controller scan is completed, the Continuum BACnet controller will send out any change it sees during the scan. So if you were toggling a point's value several times within the same program or within multiple programs, all the changes to the value are sent to recipient controllers during the scan, not just the final value. This will cause both incorrect and unnecessary data exports. The second difference is that, in the case of standard Continuum points such as InfinityNumerics and InfinityOutputs, some values can be sent to them that are not reflected directly when the values are translated into BACnet. For example if you had an InfinityNumeric and used it as a binary value in the BACnet world, a program could set it to "On" and later in a program you may perform Boolean logic on it and it would be set to a logical "1", or "true". In the Standard Continuum, these values would be different, however in BACnet, both of these values would be translated to the same value. Because the evaluation of the COV point change is done before we translate it to the BACnet standard we would transmit this as a change of value even though the value transmitted in both cases would be the same. In this case we would transmit the COV during the scan every time we saw this value toggled to what BACnet would think was no change. This would cause unnecessary COV data to be transmitted. The bottom line is that if you, through "Plain English" need your logic to set a value to a Continuum BACnet object more than once during the program scan and it is being exported, you will need to use an intermediate point such as a local variable or an InfinityNumeric to store the changes and only commit the final value to the exported point at the end of the manipulation.

Issue When swiping a card, an Invalid Parity error occurs in the Active Event view or in the Access Event log. Environment Active Event view Access Event log Cause This can either be caused by a reader malfunction or the reader being wired incorrectly. Specifically on the reader wiring they may have swapped the Data and Clock lines. Resolution Try swapping the Data and Clock line on the connector of the controller/IOU module.

Issue What is the pin out for a cable to commission a netcontroller (CX99xx)? Environment CX99xx Cause Need to create a cable to commission a controller. Resolution RJ Connector <- - - - -> 9 Pin RS232 PC Controller Comm3 Pin 1 - DTR <- - - - -> Pin 1 - CXD Pin 2 - CTS <- - - - -> Pin 7 - RTS Pin 3 - CXD <- - - - -> Pin 4 - DTR Pin 4 - RTS <- - - - -> Pin 8 - CTS Pin 5 - GND <- - - - -> Pin 5 - GND Pin 6 - RD <- - - - -> Pin 3 - TD Pin 7 - DSR <- - - - -> Pin 6 - DSR Pin 8 - TD <- - - - -> Pin 2 - RD On the RJ connector for the controller's comm3, Pin 1 is the furthest to the left with the insert clip facing away from you and the gold teeth facing you.

Issue What is the difference between the TimeOfLog and TimeStamp columns in an Alarm or AccessEvent listview? Environment Alarm or AccessEvent listview Cause One reason as to why there could be a difference between the two is that the controller did not have communications with the workstation that is logging the events so it buffered the events until such time as it could send them. Another reason is that this is a remote site (RAS) setup and the controller was buffering the events until the controller or workstation requested an update of the alarms and events. Resolution Generally these two timestamps should be close to the same value. The difference between these 2 columns is that the TimeStamp column is actually when the Alarm or Access Event happened, the TimeOfLog column is when these events were logged into the database. 

Issue What does a network switch need to be configured as to connect to a Continuum controller? Environment Network switch CX99xx CX94xx CX92xx CX9702 B4920 BCX series controllers  Cause The configuration depends on what model of controller is being connected to the Ethernet switch. Resolution If you are connecting any of the CX99xx, CX94xx, or CX92xx models of controllers: The switch port needs to be configured as 10 Mb Half duplex. These series controllers only support a 10 Mb connection type and they do not auto detect the connection type.  If you are using any of the newer model controllers like the CX9702, B4920, or BCX series controllers  they support an auto detect connection type of 10/100 Mb connection. These newer controllers will also auto detect the mode for either full or half duplex. An additional feature on the BCX series controllers is that they will also auto detect whether the CAT5 cable being used is a Cross over cable or Straight through cable.

Issue  "Maximum IOU/Infinet controllers reached" when adding an IOU module or Infinet controller. Environment IOU module Infinet controller Cause This generally means exactly what the message states. You have a node limited controller and you have reached the maximum number of nodes. Resolution Edit the controller through Continuum Explorer Click on the options tab. Verify the node counts on the controller on the options tab. If you have reached the maximum number of nodes contact the repair department to get a node upgrade flash file. There is a cost associated with this option.

Issue The time keeps changing between the workstation and the controller. Environment Continuum controllers Cause UTC offsets handle time zone differences between controllers and workstations and may need to be set. Also, a time synchronization program may be required to keep the times the same. Resolution Check the UTC offsets in Cyberstation Explorer. Verify that the Network UTC offset matches the Workstation's UTC offset. Check and verify you have a Time Sync program that synchronizes the time between the workstation and controller.

Issue After running a listview of Personnel records and sorting it by card number, the sort is incorrect. What is the proper procedure to sort Personnel records by Card number? Environment Personnel records Cause The sort is looking at the wrong attribute. Resolution Edit the listview and change your sort to sort based on the attribute NonABACardNumber.

Issue Bit Count not Supported errors in the Active Event view and Event log Environment Active Event view Event log Cause Custom cards will be required if bit count is not supported. Resolution On the door configuration screens make sure the correct card type is selected. (Note: On the door you can select multiple card types). If the card bit count and/or format is not one that is supported natively by the door then it may be necessary to configure a custom card.

Issue Since I have upgraded my CyberStation it seems that my distribution of Personnel records takes a very long time. Also I have noticed that I am having intermittent communication problems with my field bus controllers, why is this happening? Environment Cyberstation Cause This could be caused by the new personnel distribution engine. The new personnel distribution system takes advantage of all the workstations running CyberStation to load balance the distribution so not just one workstation will do this. With this feature added it was also necessary to include settings to adjust to optimize the process. Below are the settings and where they can be found. Resolution Workstation preferences can be found on the Preferences tab of the workstation editor. Workstation preferences Line 19 (Added in the 1.62 Version of CyberStation) Enables and disables the immediate distribution of personnel records from this workstation to controllers on the local area network (LAN). A value of “True” is the default. When this feature is enabled, the workstation inspects the status of the database, and if there are pending personnel distribution transactions, it performs the distributions. When to disable this preference — Typically, you would set this preference to “False” if the workstation is running a lot of applications, such as graphics. If there are several workstations at this site, disabling it on the web server may result in better performance. It also gives you the choice of turning it off for a workstation that is shut down at the end of a day. When to enable this preference — Typically, you would set this preference to “True” for workstations that are dedicated servers (running 24 hours per day and seven days per week, typically in a back room) and for other workstations based on the number of distributions and throughput. The more workstations that are distributing, the faster the distribution occurs. NOTE: If you have too many workstations with the above set to true it could actually slow down the distribution to field bus controllers by overwhelming them from different workstations. This could result in slow or no response from field bus controllers when polling them for information. It also could result in very slow personnel distributions to the field bus controllers. It is recommended not to set this to true for all the workstations but only to set it true for a few. Workstation Preferences Line 20 (Added in the 1.62 Version of CyberStation) Enables and disables the immediate distribution of personnel records from this workstation to controllers on remote access services (RAS) networks. If there are no RAS networks on this site you want to make sure this setting is false, true is the default. This feature should only be set to “True” on workstations that have modems in them used to connect to remote sites. When this feature is enabled, the workstation inspects the status of the database, and if there are pending access distributions, it performs the distributions. General Preferences are found by right-clicking on the Infinity icon in the task tray and selecting General Preferences. General Preferences Line 12 (Added in the 1.73 version of CyberStation) Number of Concurrent Fieldbus Personnel Distributions — This is the number of concurrent personnel distributions that are sent from each workstation to controllers on each field bus network. The default (and minimum) value is 1. Maximum value is 4. This setting, which works in conjunction with setting 13, improves performance by preventing or large numbers of personnel records from flooding field bus controllers. General Preferences Line 13 (Added in the 1.73 version of CyberStation) Time Interval Between Fieldbus Personnel Distributions — This is the amount of time (in milliseconds) that CyberStation waits before it sends another personnel distribution to controllers on the same fieldbus network. The default value is 30. Minimum value is 0. Maximum value is 15000 (15 seconds). This setting, which works in conjunction with setting 12, improves performance by preventing large numbers of records from flooding field bus controllers. It is also useful when there are many workstations performing access distribution. (That is, set it higher if there are many workstations.)

Issue Access Event messages say, "Access Mode No Communications." What does this mean? Environment IOU module Access Server Cause This message means that the controller/IOU module is losing communications with the Access Server (Workstation that is selected as either the Primary or Secondary Access Server). Resolution  Troubleshoot your communications network. Note: When you are in No Communications mode, your personnel records will be validated based on of how you configured the door to validate while in No Communications mode.

Issue Access Event messages are showing that are say, "Access Mode NoDatabase." What does this mean? Environment Access Server Cause This means that the controller cannot get to the personnel database to validate a personnel record.  Resolution Generally this means that the controller has lost its personnel database and needs to be reloaded. Note: When you are in No Database mode your personnel records will be validated based on of how you configured the door to validate while in No Database mode.

Issue Change the LED pattern on card readers Environment Continuum Site Cause How to Change the LED pattern on card readers Resolution On the ACX line of Infinet controllers and also the AC1+ modules you can change the dynamics of the reader LED. The Alternate LED pattern is selected by creating a numeric point whose name is AccessLEDPattern. When this point exists, the Alternate LED pattern will be employed by the access controller. When this point does not exist, the standard LED pattern will be employed. It should be noted that cold-starting or resetting the access controller does not delete or destroy the AccessLEDPattern.

Issue An ACX781 controller or AC1 IOU module keeps locking up and going offline. What can be done to determine why this is happening? Environment ACX781 AC1 IOU module Cause The most common cause of communication problems is electrical noise getting to the controller. Resolution Rule out any kind of hardware failure The most common scenario resulting in electrical noise and controllers going online and offline is that there are no 39v MOVs installed at the door strikes. The reason for needing these MOVs is that when the door strike relay de-energizes it creates a field collapse electrical spike that can travel back down the output wiring to the controller. When this happens, it generally will not damage any of the hardware in the controller but it could cause it to reset or cause its memory to get scrambled. Generally a reset and reload of the controller clears out the problem. It is strongly recommended to put MOVs on all outputs that have relays on them.  Put the MOVs at the end device and not the controller end.

Issue Access Event messages say, "Access Mode Normal." What does this mean? Environment Access Event messages Cause This is generally seen after you see either "Access Mode No Database" or "Access Mode No Communications" messages and the problem has been corrected. Resolution This means the system is running Normally again. Note: When in Normal mode, personnel records will be validated based on how the door is configured to validate while in Normal mode .

Issue What is the difference between Remote validation and Local validation of personnel records? Environment Personnel Records Cause Differences in remote and location validation scenarios. Resolution The difference between Remote and Local validation of personnel records is: Local validation - the personnel records are validated at the controller itself Remote validation - the personnel records are validated at the workstation.

Issue When right clicking on some BACnet objects within Cyberstation (like EventEnrollments and Schedules) and clicking on "Rename", you may receive the following error message when you click Finish: "Cannot set the Name. An attempt has been made to write to a BACnet property with a value that is outside the range of values defined for the property." Environment CyberStation Cause This issue occurs when you specify a Name that does not conform to Alias constraints (16 characters, letters, numbers, period, and underscore only). Resolution Rename the object through its properties page to work around this limitation.