AB 1734-AENT - Start up Time determined by number of modules?

As part of a start up alarm handling routine we use GSV to return the Entry status for each AENT on the network.


All but one unit takes around 9500ms after the first scan to report they are running,

• 16#4000. Running. All connections to the module are established and data is transferring.


However, one unit continues to report faulted up until 20s when the start up routine times out,

• 16#1000. Faulted. Any of the Module object’s connections to the associated module fail. This value should not be used to determine if the module failed because the Module object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state.


This module has 21 slots occupied whilst the others have 6-12. At some time soon after it does move to running status and does not fault during operation.


Is anyone aware that as we add more slots the start up time for an AENT increases?

Or does the longer start up time indicate that the AENT or one of the modules is now suspect?

Do we need more patience or to turn our attention to troubleshooting and a spare parts order?

Here are some timing results from both a running and test system

No. Slots Time to register running status
on AENT after S:FS bit is set (ms)
===== ===================
1 9324
9 9851
12 9879
20 >20000
5 9879
6 9932
8 9885


The attached image shows the slot list on the suspect AENT.

If we trend the GSV Entry Status and then power cycle the AENT we can record the module cycling through the following status codes.

It takes 15s after power to reach running status.

The question follows if this trend would look significantly different as more modules are added to the AENT?



==================



Here are the details on the GSV for Entry Status:

Specifies the current state of the specified map entry. The lower 12 bits should be masked when performing a comparison operation. Only bits 12...15 are valid. Each value has a specific meaning:
• 16#0000. Standby. The controller is powering up.
• 16#1000. Faulted. Any of the Module object’s connections to the associated module fail. This value should not be used to determine if the module failed because the Module object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.
• 16#2000. Validating. The Module object is verifying Module object integrity prior to establishing connections to the module.
• 16#3000. Connecting. The Module object is initiating connections to the module.
• 16#4000. Running. All connections to the module are established and data is transferring.
• 16#5000. Shutting down. The Module object is in the process of shutting down all connections to the module.
• 16#6000. Inhibited. The Module object is inhibited (the inhibit bit in the Mode attribute is set).
• 16#7000. Waiting. The parent object upon which this Module object depends is not running.
• 16#9000. Firmware Updating. Firmware supervisor is attempting to flash the module.
• 16#A000. Configuring. Controller is downloading configuration to the module

https://literature.rockwellautomati...ure/documents/rm/1756-rm003_-en-p.pdf#page215