As per controller data sheet, IO COM light is steady ON when IO communications are good, flashes indicating a fault, and is OFF when no IO communication is in use (no IO modules on railbus). However, in actual use, the IO COM light would flash randomly (1 or 2 times per minute) when no module was installed in slot 1. If a module is installed in slot 1, even if the module does not exist in the project configuration, the light seemed to be steady on.

To make LED function meaningful, this release changes its operation as follows:

ON: All railbus transactions performed within the last two seconds succeeded.

Flash: At least one railbus transactions performed within the last two seconds failed.

OFF: No railbus transactions have taken place within the last two seconds.

Saving retained variables while doing a strategy download may cause ISaGRAF to start incorrectly.

Saving retained variable while doing a strategy download may cause both controllers to go "off-line"

The saving of retained variables is not allowed while a strategy download is active.

Once a strategy download has been completed, if a pending ratained variables request is active this will then be triggered. If the strategy download was "with initialization" the initialized variables will be assigned to the appropriate Modbus registeres and then saved. However, if the strategy download is "without initialization" the new values will be saved.

Whenever the controller loses communication with remote controller, it should wait 2 times configured scan rate, before applying failsafe values due to communication failure. If connection restores within 2 times the configured scan rate from the last valid Modbus response, the controller should not apply failsafe values. The controller was applying failsafe values as soon as communication to remote controller was lost.

Build 2.14 fixes this issue. Whenever, controller loses communication with remote controller, it waits for 2 times the configured scan rate from the last valid Modbus response. If no communication is restored in this period, controller takes the channels to the pre-configured failsafe values.

A problem observed on 8142-DO-DC module in the following scenario.

8142-DO-DC channel failsafe state is configured is OFF.

Line fault occur on a particular channel.

8142-DO-DC module enters failsafe state. **

Line fault condition is removed on that particular channel.

8142-DO-DC module is taken out of failsafe state.

In this scenario even though no line fault exist on that particular channel, it continues to report a line fault and the channel LED will be in blink state.

* Note: The module can enter failsafe state for several reasons. For example, if configured, HMI timeout can place all modules in failsafe state. Also modules can be commanded to enter failsafe state.

When 8142-DO-DC module is configured, an event log message shows that "channel properties block" does not match between controller and 8142-DO-DC module. A message appears in event log similar to the one given below

CPB 1 is different 1 1 10

This issue is addressed in 02.14 firmware release. In combination with 02.14 controller firmware, it is required t o use 01.04 version of 8142-DO-DC module firmware to have this issue resolved.

Controlelr is not generating the modbus write command for Modbus coil write request with value 0. Due to this end user was not able to write coils with value 0.

Build 02.14 resolves this issue and it makes sure the Modbus coil write requests are generated as per the user's request for both setting and resetting of the coil.

While upgrading or downgrading firmware on a duplex system, sometimes the standby controller remains offline with firmware downloader tool showing the error message "Get NVM details control Package B." When this has occurred, follow either of the methods listed below.

• Press the Change State button on the standby controller. The standby controller will be properly synchronized with the master controller.

OR

• Select the firmware version a second time from the firmware downloader tool and update firmware on the standby controller.

When a new RTU controller (without IP settings) is inserted next to the master controller running in simplex mode, the new controller, which is in BOOTP mode, fails to sync with Master controller. The event log will show the following message.

"Abort due to MmuDtmLISR Data Address”.

When this happens, press the Change State button on the standby controller or power cycle it. The standby controller will get properly synchronized with the Master.

On rare occasions a “Refresh warm init took too long” event may occur after a persistent queue rollover (see the “Persistent Queue Rollover“ operational note on page 9) or a refresh. When this occurs the standby will be unable to refresh with the master and will remain offline.

If this problem occurs the IO Configurator should be used to do a clean flash of the “DNP Data Logging” on the master with the standby powered down. The standby should then be able to refresh successfully when powered on.

After power cycling the master, taking the standby from offline to online, or resetting the master via the xxx_AXE_Reset_Coil (8449) the new standby may occasionally fail to refresh and report a “Download Persistent Queue CSC_CORRUPT” event. When this occurs the standby will be unable to refresh with the master and will remain offline.

If this problem occurs the IO Configurator should be used to do a clean flash of the “DNP Data Logging” on the master with the standby powered down. The standby should then be able to refresh successfully when powered on

Occasionally a clean flash will result in an abort due to “RtosFree NU_Deallocate_Memory NU_INVALID_MEMORY”.

If this failure occurs a subsequent clean flash will succeed.

If the ISaGRAF strategy exceeds the maximum supported size the download will be rejected and an “ISaGRAF strategy too large” event is logged. When this occurs an attempt to clean flash may result in a controller abort due to “MmuDtmLISR Data Address invalid”. The abort will occur on both controllers in a duplex system. Further attempts to clean flash should be successful.

If this problem is encountered reduce the size of the ISaGRAF strategy, clean flash, and download the smaller strategy.

When retained variables are used a power cycle with a downtime close to the configured “Retained Variables Delay” may result in the standby remaining offline. The standby will report that it has newer retained variables than the master.

If the problem occurs the IO Configurator should be used to do a clean flash of the standby with the master powered down. The standby should then be able to refresh successfully with the master.

To avoid this configure the “Retained Variables Delay” to be a longer time than the “Warm Start Time” in the controller configuration.

Power cycling both controllers may cause a “DDA CRC NvmQ pool different” event upon completion of the refresh. When this occurs the standby will be unable to refresh with the master.

If the problem occurs the IO Configurator should be used to do a clean flash of the “DNP Data Logging” on the master with the standby powered down. The standby should then be able to refresh successfully when powered on.

Commands to pulse a DNP point on or off cause the point to latch that value rather than pulse.

If a pulse is needed, consecutive latch commands can be used to manually generate a pulse.

On rare occasions in a duplex system after resetting the master via the xxx_AXE_Reset_Coil (8449) the new standby may enter into a continuous reset state. When this occurs the standby will be unable to refresh with the master and will remain offline.

If this problem occurs the controller should be powered on in a simplex configuration with the Change State button held until power up completes. After the controller powers up the IO Configurator should be used to do a clean flash with all options selected. The standby should then be able to refresh successfully with the master.

On rare occasions power cycling a duplex system may result in the standby coming up in the failed state with an “Abort due to DmaFinish Copy”.

After this problem occurs resetting or power cycling the standby will allow it to successfully refresh with the master.

In systems running high execution cycle times (>200ms) an additional refresh may occur after a power cycle due to a rendezvous timeout on the initial refresh. In this case a “Force standby, rendezvous timeout” event will be logged. The second refresh may be successful or the standby may be unable to refresh with the master and remain offline.

To avoid the problem, the sustained execution cycle times should be maintained below 150ms.

Resetting both controllers in a duplex pair while a Retained Variables save is in progress may result in the standby aborting on the subsequent powerup.

After this problem occurs resetting or power cycling the standby will allow it to successfully refresh with the master.

Occasionally a rendezvous timeout will occur when opening DNP channel. When this occurs the standby will remain offline.

The standby can be commanded to exit offline by pushing the Change State button on the controller carrier or issuing a “Simulate Button Press” command via the Network Configurator utility.

Powering up a controller with no strategy or configuration downloaded sometimes results in a controller abort. The event log will indicate “Abort due to MmuDtmLISR Data Address invalid” if this occurs.

This issue has no impact on operation and can be ignored under these circumstances.

When the PAC8000 controller is used as a Modbus Master and an option other than “No Packing” is selected from the WorkBench, the controller could return erroneous Modbus values to the slave. The issue occurs only for discrete Modbus registers.

Ensure that the “No Packing” option is selected if the PAC8000 controller is used as a Modbus Master.

DNP points are sampled for change every execution cycle. Events are recorded every one second, however. Points changing that occur more frequently than once per second will be detected but not reported. This may also result in consecutive events with the same value when a point changes and then changes back to the original value.

It should be noted that events are not recorded at exactly one second intervals. They are recorded during the execution cycle and therefore the maximum time between recorded events will be one second plus the execution cycle time.

Only one method of time synchronization should be enabled on the controller. If using DNP3 time synchronization SNTP and PAC8000 to PAC8000 time synchronization should be disabled. To disable SNTP, simply do not configure time servers on the controller “Attributes” tab in the IO Configurator. To disablePAC8000 to PAC8000 time synchronization uncheck the “Act as Time Master” option on the controller “System” tab for all controllers on the network.

Note that some DNP masters automatically synchronize time and do not allow this functionality to be disabled.

The persistent queue that stores DNP events uses flash memory for non-volatile storage. Write and erase cycles will cause wear to the flash storage eventually causing the component to fail. Changes in class1 or higher DNP points cause changes to the persistent queue. Therefore large numbers of these points or frequent changes to these points will accelerate wear of the flash storage.

If the flash component fails, the event log will contain “Flash sector xx write failed” or “Flash sector xx write timeout” events.

The RTU does not support the cold and warm start DNP functions.

A controller can be reset using the xxx_AXE_Reset coil (8449). This can be written via DNP if the point is mapped as a DNP point. This can also be done from application logic or written via Modbus. In duplex systems this will only reset the master controller.

After a failover from Master to standby, controller may resend some of the events that it has already sent to DNP Master. When this occurs some of the events will have same time stamp and value as the old events.

This will happen if the controller failover occurs while the RTU is waiting for a confirmation message from the DNP master. In this case the confirmation message will be lost, and the new Master controller will detect a confirmation message timeout and send the events again.

If a DNP read or write is in progress when a failover occurs, the DNP request may not be responded to. This will cause the DNP master to detect a timeout for that request. Further behavior is dependent on the actions of the DNP master.

If this occurs, the RTU will respond to further DNP requests.