Has the network been changed within the last 10 years? Have extra devices been added?
Managed switches would be a better bet when using remote I/O
ControlLogix Inputs Blinking
- Thread starter Bit_Bucket_07
- Start date
Has the network been changed within the last 10 years? Have extra devices been added?
Managed switches would be a better bet when using remote I/O
Bit_Bucket_07
Member
OP
No. Why do you believe that managed switches are preferable on a private network consisting of 5 devices with fixed IP addresses?
Bit_Bucket_07
Member
OP
Follow Up: A failed Ethernet switch was indeed the culprit.
Bit_Bucket_07 said:
You may or may not still want this question answered, but seeing as you asked it, and seeing as the apparent consensus appears to be incorrect; I will answer it...
Regardless of which Distributed I/O communications adapter is used, a ControlLogix controller will not reset the input data for Distributed I/O input modules.
If communications media to a Distributed I/O chassis is unplugged or broken...
Or, if a Distributed I/O adapter is physically removed from the chassis...
Or, if a Distributed I/O input module is physically removed from the chassis...
Or, the Distributed I/O chassis is powered down...
Then the input data in the ControlLogix controller is held at its Last State. How one monitors for this state, and handles the input data and its usage during this state, is optional.
Once communications have been re-established, a Distributed I/O input module will resume reporting of the actual input states.
Distributed I/O output modules are handled differently. Because they may be driving field devices, a loss of communications could result in undesirable operations, to say the least. For this reason, one has the option to configure the fault/idle action for output modules and their output data as any one of the following...
Set to OFF...
Hold Last State...
Apply Safe State Value
Note: the above is related to the use of ControlLogix controllers and Distributed I/O. 1769 I/O modules themselves do support such features, but their compatible controllers do not. Namely, the older and newer CompactLogix controllers, and the MicroLogix 1500 controller.
Regards,
George
Bit_Bucket_07
Member
OP
Thanks for the information, George. I knew that most PLCs that I have worked with over the years would have left the inputs in their last valid state in the event of a comms loss. I don't know why these inputs were being reset, but I know that replacing an Ethernet switch has made their problem disappear -- at least, for now.
Blink and You Will Miss It!...
I might also have a possible explanation for your above query...
If we go back to your earlier descriptions of the "blinking" inputs that were trapped in the processor...
Working on the assumption that the inputs in question here should remain in the ON state during normal operations and, based on the above knowledge, should hold this ON state throughout a communications loss and return, intermittent or otherwise.
When communications are lost to the Distributed 1756-ENBT adapter the input data should hold its last state. However, when communications are re-established to the adapter the input data may be seen to be reset to the OFF state for one scan of the processor.
Why might this happen?...
If the 1756 Distributed I/O adapter is configured for Rack Optimized connection then the adapter, as a scanner, will first poll its child modules for all their input data (we'll not concern ourselves with any output data here). Once the adapter's image is updated it then transmits the input data back to the Local chassis adapter and then to the processor. This is the normal procedure when a Rack Optimized connection has been established to the processor.
When communications are interrupted from the Local adapter to the Distributed adapter the Rack Optimized connection is torn down. The input data is held at the last state, which in this case we expect to be the ON state. When communications are re-established then the Distributed adapter is now said to be in scanner mode and is already producing data back to the controller.
However, the Distributed adapter has not yet established a connection to its child input modules across the Distributed chassis backplane. So the adapter's image is initially all zeros and this is what is transmitted back to the Local chassis. This OFF state input data is only present for one scan. After one processor scan the Distributed adapter will have received the first update from its child input modules and then valid input data begins transmitting again. This "bump" in the input data, where input values may transition from ON>OFF>ON for one scan, may only be experienced during communications loss and return, intermittent or otherwise, when a Rack Optimized connection is used.
If Direct connections are used with Distributed input modules, then the processor, via the Local adapter, will establish a direct connection with the input modules, via the Distributed adapter. The input modules will then produce their input data directly to the processor, via the Distributed adapter. Here, the Distributed adapter is said to be in adapter mode. It is only passing data through and is not scanning, or polling for data from its child modules. Therefore, when using Direct connections, and communications are lost and returned, intermittent or otherwise, the input modules will begin immediately producing valid input data to the processor.
What the "trap" logic most likely captured were intermittent loss and return events of communications between the Local and Distributed adapter, where a Rack Optimized connection is configured. The "trap" most likely caught OFF state "bumps" which are only present for one scan, but could have been happening infrequently during any given day. Hence, several events may have been captured.
In short, the apparently faulty Unmanaged Ethernet switch was likely to have been causing connection dropouts and the "trap" logic was seeing the normal, but nuisance anomaly of one scan OFF states for the input data.
--------------------------------
Fundamental issue Flag!...
Questions were also raised as to whether such switches should be Managed or Unmanaged here. But that discussion is a whole other thread. However, based on your replies, what I will at the very least suggest is that you consider this...
It is not just the size or architecture of a network that should determine whether to use Managed or Unmanaged Ethernet switches...
The type of and required priority of Ethernet data traffic on the wire, even on a relatively small network, is a very important consideration when deciding which switch type to use.
Just one reason why it may be important...
Distributed I/O, as is used in this case, can involve time-critical CIP I/O data. This traffic type may require a relatively high priority on the network. Because the EtherNet/IP protocol "rides atop" the standard Ethernet Stack it may be sharing bandwidth with other types of less critical Ethernet traffic. In some cases, the more critical EtherNet/IP data may not be "riding atop", but rather, "sinking below". To assist in prioritizing data on the network, Quality of Service (QoS) techniques may be implemented. However, to implement such techniques, the devices used must be QoS capable.
Unmanaged switches, while they do inherently and automatically handle the prioritizing and egress queuing of data on their ports, they do not provide a means to manage and configure their QoS features. You cannot tell them which traffic has higher priority over others. They will not reserve bandwidth for the traffic you deem to be of a higher priority.
Managed switches do provide such QoS techniques, and at various levels, depending on the type of managed switch used (Smart Switches, Layer 2 or Layer 3). Also, many newer Dual Port Embedded Switch devices are default enabled to use QoS techniques to more efficiently pass or consume the data ingressing and egressing their ports. These QoS capable switches and end devices form what is known as end-to-end QoS. Each device then has the ability to recognize ODVA approved priority tagged data packets. For instance, CIP I/O data packets may be tagged as "high CIP 1". QoS identifies and places these packets in the relevant priority queue so they are sent before less critical network traffic.
And on and on...
If this system has been running OK for 10+ years with unmanaged switches then it is likely that the bandwidth usage and CPU utilization levels are relatively low. So the likes of the CIP I/O traffic, and whatever other traffic might be present on the network, has never struggled to achieve timely throughput.
However, what using unmanaged switches did not provide here was a means to diagnose the issue at source. If an unmanaged switch is suspected then you cannot access its media counters and errors to get a better insight. You have to attack it from both sides, like trapping the unwanted data changes in the program or analyzing counters and errors from nodes that communicate with the switch appliance.
There is nothing wrong or right about using unmanaged switches, once you understand the pros and cons and can make an informed decision for your intended application. But, when used in the wrong situation, they can often create more costly problems in the long run than the perceived cost saving at the outset.
Regards,
George
Bit_Bucket_07 said:
I might also have a possible explanation for your above query...
If we go back to your earlier descriptions of the "blinking" inputs that were trapped in the processor...
Bit_Bucket_07 said:
Working on the assumption that the inputs in question here should remain in the ON state during normal operations and, based on the above knowledge, should hold this ON state throughout a communications loss and return, intermittent or otherwise.
When communications are lost to the Distributed 1756-ENBT adapter the input data should hold its last state. However, when communications are re-established to the adapter the input data may be seen to be reset to the OFF state for one scan of the processor.
Why might this happen?...
If the 1756 Distributed I/O adapter is configured for Rack Optimized connection then the adapter, as a scanner, will first poll its child modules for all their input data (we'll not concern ourselves with any output data here). Once the adapter's image is updated it then transmits the input data back to the Local chassis adapter and then to the processor. This is the normal procedure when a Rack Optimized connection has been established to the processor.
When communications are interrupted from the Local adapter to the Distributed adapter the Rack Optimized connection is torn down. The input data is held at the last state, which in this case we expect to be the ON state. When communications are re-established then the Distributed adapter is now said to be in scanner mode and is already producing data back to the controller.
However, the Distributed adapter has not yet established a connection to its child input modules across the Distributed chassis backplane. So the adapter's image is initially all zeros and this is what is transmitted back to the Local chassis. This OFF state input data is only present for one scan. After one processor scan the Distributed adapter will have received the first update from its child input modules and then valid input data begins transmitting again. This "bump" in the input data, where input values may transition from ON>OFF>ON for one scan, may only be experienced during communications loss and return, intermittent or otherwise, when a Rack Optimized connection is used.
If Direct connections are used with Distributed input modules, then the processor, via the Local adapter, will establish a direct connection with the input modules, via the Distributed adapter. The input modules will then produce their input data directly to the processor, via the Distributed adapter. Here, the Distributed adapter is said to be in adapter mode. It is only passing data through and is not scanning, or polling for data from its child modules. Therefore, when using Direct connections, and communications are lost and returned, intermittent or otherwise, the input modules will begin immediately producing valid input data to the processor.
What the "trap" logic most likely captured were intermittent loss and return events of communications between the Local and Distributed adapter, where a Rack Optimized connection is configured. The "trap" most likely caught OFF state "bumps" which are only present for one scan, but could have been happening infrequently during any given day. Hence, several events may have been captured.
In short, the apparently faulty Unmanaged Ethernet switch was likely to have been causing connection dropouts and the "trap" logic was seeing the normal, but nuisance anomaly of one scan OFF states for the input data.
--------------------------------
Fundamental issue Flag!...
Questions were also raised as to whether such switches should be Managed or Unmanaged here. But that discussion is a whole other thread. However, based on your replies, what I will at the very least suggest is that you consider this...
Bit_Bucket_07 said:
It is not just the size or architecture of a network that should determine whether to use Managed or Unmanaged Ethernet switches...
ianingram said:
The type of and required priority of Ethernet data traffic on the wire, even on a relatively small network, is a very important consideration when deciding which switch type to use.
Just one reason why it may be important...
Distributed I/O, as is used in this case, can involve time-critical CIP I/O data. This traffic type may require a relatively high priority on the network. Because the EtherNet/IP protocol "rides atop" the standard Ethernet Stack it may be sharing bandwidth with other types of less critical Ethernet traffic. In some cases, the more critical EtherNet/IP data may not be "riding atop", but rather, "sinking below". To assist in prioritizing data on the network, Quality of Service (QoS) techniques may be implemented. However, to implement such techniques, the devices used must be QoS capable.
Unmanaged switches, while they do inherently and automatically handle the prioritizing and egress queuing of data on their ports, they do not provide a means to manage and configure their QoS features. You cannot tell them which traffic has higher priority over others. They will not reserve bandwidth for the traffic you deem to be of a higher priority.
Managed switches do provide such QoS techniques, and at various levels, depending on the type of managed switch used (Smart Switches, Layer 2 or Layer 3). Also, many newer Dual Port Embedded Switch devices are default enabled to use QoS techniques to more efficiently pass or consume the data ingressing and egressing their ports. These QoS capable switches and end devices form what is known as end-to-end QoS. Each device then has the ability to recognize ODVA approved priority tagged data packets. For instance, CIP I/O data packets may be tagged as "high CIP 1". QoS identifies and places these packets in the relevant priority queue so they are sent before less critical network traffic.
And on and on...
If this system has been running OK for 10+ years with unmanaged switches then it is likely that the bandwidth usage and CPU utilization levels are relatively low. So the likes of the CIP I/O traffic, and whatever other traffic might be present on the network, has never struggled to achieve timely throughput.
However, what using unmanaged switches did not provide here was a means to diagnose the issue at source. If an unmanaged switch is suspected then you cannot access its media counters and errors to get a better insight. You have to attack it from both sides, like trapping the unwanted data changes in the program or analyzing counters and errors from nodes that communicate with the switch appliance.
There is nothing wrong or right about using unmanaged switches, once you understand the pros and cons and can make an informed decision for your intended application. But, when used in the wrong situation, they can often create more costly problems in the long run than the perceived cost saving at the outset.
Regards,
George
Similar Topics
Hey all,
I'm having this issue with an Allen Bradley AC input card(1756-IA16I). I was looking into another issue and found that the inputs on the...
I am having a strange intermittent problem with a ControlLogix system appearing to drop discrete inputs momentarily when we first go online with...
Hello,
I have two 16 point input cards and 1 16 point output card showing module faulted on my IO tree in Logix Designer.
The fault code is...
Hello,
My associate and I are trying to sync up two ControlLogix racks (7-slot chassis) with identical modules. We are able to see the secondary...
Trying to setup a message read via Ethernet.
I have the path setup as 1, 1, 2, 192.168.66.10
I get an error code 1, ext err 315.
I am beating...