CompactLogix to Remote IO module error

Hi everyone,

PLC: CompactLogix L35e
Network Protocol: Ethernet, Fibre Optic
Remote IO: Phoenix Contact inline ethernet coupler, with Analog input modules
RSLogix 5000: Using the Generic ethernet module IO profile for this Remote IO module

Problem:
The Remote IO module have two 4~20mA level transmitters connected to it. The PLC uses these level readings for control. The remote IO is connected to the PLC via fibre optic over 70m length. Intermittently over a period of a few days, the IO profile for this remote IO module faults out (code 16#0100, a small yellow triangle), which means the level reading at the PLC freezes at the last value.

I use the generic ethernet profile in logix5000 for the remote IO module. THe only way to get rid of this fault is to go into the IO profile, and click on the Reset. Once it's reset, the fault goes away and everything is fine and dandy.

I can't work out what is causing this to fault over and over again. The Rockwell knowledgebase has a few suggestions about the 16#0100 error code, and involves disabling setting the Comm format to 'none', which means it will prevent the level readings being transmitted - this is useless to me.
A work-around i had in mind is to write some code to force a reset to the unit everytime a fault is detected on this Remote IO module. However there are no useful status bits that i can find on this IO profile that i can use to enable me to do this.

Has anyone come across a similar issue before?
What's causing this error? How do i get rid of this problem?

Thanks in advance.

i found this: The firmware on the 1756-IF4FXOF2F needs to be upgraded from version 1.4 to 3.5. has your Remote IO: Phoenix Contact inline ethernet coupler, with Analog input modules ever worked or is this a new problem?

Hi,

I'm not using the 1756-IF4FXOF2F card. It's just remote ethernet IO.

THis is a new installation, and have had this problem since day 1.

Thanks for your reply.

My guess is that there are intermittent communication failures that eventually lead to a broken connection, but the Phoenix device fails to close the connection gracefully and rejects the ControlLogix attempt to re-establish the connection.

The first thing I'd do is use the embedded web page in the ControlLogix interface and check for media or protocol errors. Auto-negotiation mis-configurations are a common reason for accumulated errors.

If you have access to a network tap or a managed switch, and a PC that you can leave connected for a while to run Wireshark, you can further investigate protocol issues if you don't find any media issues.

You can programmatically Inhibit and un-Inhibit an I/O Connection; use the SSV instruction to change the Inhibit bit in the Module Object. This is described in RA Knowledgebase article ID # 52041 (TechConnect).

If that doesn't do the job, you can almost certainly Reset the connection with an SSV or a CIP Generic Message instruction. You might have to go to RA Tech Support for the details on that; I don't have the specifics (or a test system) handy.

Thanks for the brilliant suggestions Ken.
I've attached screenshots of the web enabled compactlogix network diagnostics.
There definitely are some errors detected. (screenshots taken while the fault was present on the remote IO).
Is there anything you see from these screenshots which point to any potential network config corrections?

Otherwise i'll try out the SSV inhibit method.

As already indicated by Ken, usually those errors you may see inside the module's diagnostic pages are related to auto-negotiation mis-configurations.

Verify that ALL the connected devices have the same configuration.

Auto negotiation is out-of-the-box easy to use and reliable. If your company policy is to force the duplex and speed, this is legitimate. However, if you force, remember to force both of the following:

• Switch port
  
• Corresponding end-device

Otherwise, there will be a mismatch and communications problems will occur.

- fuzzy logic

THanks for your response 'fuzzy logic'.

In the mean time,

Ken: I read your reference to the knowledgebase regarding the use of MODULE inhibit & uninhibit. Is there a way to use the SSV to trigger the 'reset module' instead? I've attached an offline screenshot of the command i'm referring to. (The inhibit & uninhibit doesn't actually reset the module that clears the error). Cheers.

Jeffy, take a look to Aid 55362 , there are instructions about usage of a CIP message you may send to the module to Reset it.
Be careful to the value you write inside the SINT tag, it is described at the end of the technote.
You will need that value to be 0, to reset module.

Hope this helps,
- fuzzy logic