ArmorBlock 2-Port EtherNet/IP Module Diagnostic

[conradstone]

ArmorBlock 2-Port EtherNet/IP Module
I am working on starting a plant up and we have a tremendous amount of these modules as the plant was designed to be as ¨cost effective¨ as possible. I have had several opportunities working on these gems and we have lost days of production due to problems associated with installation and a few problems with device failures. I am thinking of adding an AOI instruction to help detect their failures. Does anyone have any ideas and does AB have a module already defined and I just have seen it. I am listing the failure modes we have seen below.


1. Unit stops working with a red light on the comms, but no fault on diagnostic and if looking at the IO tree the module did not indicate a fault. Under Major/Minor faults none were listed and Comms showed connected, but no outputs and no change of states on Inputs



2. EtherNet/IP D-Code M12 connector the cables were field assembled using a spring mechanism and the Green Network cable. During a modification some of the cabling was pulled loose inside the strain relief. This caused part of our IO to show the small yellow triangles, but our diagnostics routines did not show a fault with the modules on Panelview.


3. 3. Loss of 24Vdc on DLR setup due to cabling/connector issues


4. Name 1732E-16CFGM12R 16 DC In/Out M12 Product Code 1732E-16CFGM12R this is out standard IO module and we use the Red Armor Safety module similar to this.


I was thinking of adding a simple cable loop where I set an Output On one port and read it on another once a second and if this fails setting my fault. This seems really brute force to me and surely something else is already programmed or setup in AB library, but all of the diagnostics that are supposed to show these errors didn´t work. If I did this it only cost one cable and a few lines of code. We only have 300 to 400 of these modules so my idea is a big undertaking. However we cannot keep losing days of production and bad products.


We use Ethernet IP and 1756-L83 to L85 processors with dedicated IO networks that are completely isolated from any outside network. V28 and couple V30 firmwares.


Thank you for any help. I am only here for a short time and I don´t want to leave my guys in a pickle.

 

[Ken Roach]

If you have a very large number of modules in your I/O tree, the icons and Connection Status windows can be pretty slow to update.

But I've never had the GSV or explicit messages to read DLR status fail to correctly indicate the current status for the modules.

A solid Red light on the Network Status LED for a 1732E module indicates a duplicate IP address. That would explain a situation where one module continued to work and showed no connection fault, but a module connected thereafter with the same IP address showed a read NS LED.

If you have Cisco switches (or Rockwell Stratix, since they're Cisco inside) be sure that IP Device Tracking is disabled, since that can cause false duplicate IP detection on some devices. RA Knowledgebase Aricle 568750 has some details.

How are you doing your programmatic diagnostics now ?

When I have more than a few Ethernet I/O modules, I build a little sequencer and run one GSV every scan; I'm OK with it taking a second or two to read a hundred of them.

 

[iraiam]

As Ken mentioned, Use a GSV instruction on entry status to get the module status, then in logic, anything other than normal connection executes another GSV instruction to get the fault code. There is a programming example from RA that shows how to do it.

If you are using a Device Level Ring, I advise you use a RA Stratix Switch. A DLR with RA Armor Blocks and Hirschmann switches was very problematic for me.

Also RA released a DLR faceplate for Panelview applications that is pretty good, It needs a Stratix switch and the AOP. Once integrated, it shows the status of the ring and each module, and will tolerate and switch seamlessly in the event of a single connection failure.

Also check your port diagnostics on each Armor Block, you for sure don't want to see any Alignment Errors, or FCS errors. Adherence to network cabling best practices is a must.

Like you, I support hundreds of these modules on several different I/O networks, a poor initial installation caused me a lot of problems, and took a long time to overcome, mostly cabling issues.

 

[conradstone]

Thanks

I have been requested to work Third shift for the rest of this month and March since we are having so many opportunities. I am definitely going to research your advice gentleman. I will give a more thorough answer when our machines are a tad bit happier. Many thanks. The installation and the Software are all from a completely different teams. We have 6 different prototype machines for 6 processes and 5 standard machines for 5 processes and over 30 PLCs. 3 Buildings and one with 3 levels, sometimes they don´t understand why it takes this old man a while to find things. If I had a little of the super Ken powder, maybe but EBay doesn´t have it in stock anymore. Ohh yeah, it is 3 am here.
Thanks

 

[conradstone]

Thanks for the help

Following your advise I used the GSV command and set up a little diagnostic rung. I am not the programmer for all these devices, but I have showed your ideas do work very well.
I also have found that just because you think "Surely they monitor the IO blocks and EtherNetIP devises does not mean they do. Best regards and many thanks.