Ethernet between L35E and ML1400

We have two machines whose interface is Ethernet.

On one end is a ML1400 with built in Enet port
On the other end is an L35E with built in Enet port.

As a result of some bizarrely innapropriate saftey precautions being forced on manufacturing by HR, the machine controlled by the ML1400 must be turned off and locked out on a regular basis.

Every time this is done, it takes about 9 minutes (almost exactly and always consistent) for the L35E to re-stablish communication. Very occasionally you will get lucky and it will only take 30 seconds (much more tollerable).

The L35E is using message instructions CIP with SLC typed read and writes to N files on the ML1400. There is no logic on the ML1400 side for the communication, it is all on the L35E.

The error specifically is Code 1 "Connection Failure"
and Extended Code 204h "Unconnected message timeout"

The communication polling is being done by way of the MSG block handshaking signals (Not time based). When communication is lost or if a communication error exists, we re-start the MSG instruction at regular intervals (ie 10 seconds) until communication is re-stablished.

Generally, this all works fine. The communication, once up, does not miss a beat. If the L35E PLC is cycled, it also re-stablishes connection almost immediately.

It is only when the ML1400 goes down and comes back.

There seems to be some sort of timeout value in the L35E that refuses to re-initialize the connection. I have searched all the comm parameters on both the L35E, the MSG instructions, and the ML1400, and I can't find any timeouts that correlate to the 9 minutes (540 seconds) that I am experiencing.

Does anyone know of a way to force the L35E to close a connection so that it can be re-opened? This seems to be the source of my issues.

side note:
I have tried settting the {MSG_xxx}.EC "cached" bit both high and low. It has no effect. Having it set to low should cause to close the connection immediately after completion of the MSG instruction. It does not seem to do this.

A very similar topic came up on the Forum a couple of weeks ago and I wanted to look into it in detail but don't have the hardware.

It might be the TCP Keepalive, or it might be the way you're conditioning the MSG instructions.

Can you post the Messaging routine, or a screenshot of it ?

The one way you never want to condition messages is with a repeating timer; you'll end up filling up buffers and waiting for them to empty out. I prefer to re-try my messages by manually setting the .TO bit (this forces a timeout) then allowing whatever .DN/.ER detection logic I was using to continue sequencing my MSG instructions.

Is there any way you could hook up a hub or managed switch and grab an example of this traffic using Wireshark ?

Hi Ken,
That "similar" topic is actually the same topic. It was posted by my partner in crime. Part of my problem is I don't have an ML1400 I can use to bench test the issue, so I have to do it on the machine.

I suspect, as you mentioned, that it is a TCP keep alive issue. I will attempt to post the messaging routine as soon as I figure out how to. As of yet I have never posted attachments.

To be clear, my MSG instructions are entirely handshake driven (using DN, and ER bits) with a slight added dwell between. The only time it becomes completely time based is if It keeps going into error. In this case, my retry code has a longer period than the timeout setting.
What is the advantage of taking manual control of the Timeout signal as opposed to allowing it to timeout itself and simply adjust the timeout value?
I am going to see if I can't find an ML1400 to help bench test. At this time manufacturing demand is trumping my access to the machine.

Thanks for your comments!
Damian

Soemthing is strange. It's seems like the only way for me to attach a file is to start a new post. I'm sure that can't be right.

Sorry ..... only ever did quick reply with the text window at the bottom. Never hit the big post reply button until now.

DamianInRochester said:

Sorry ..... only ever did quick reply with the text window at the bottom. Never hit the big post reply button until now.

Click to expand...

If you want to attach something with the quick reply just click on "Go Advanced".

Here is an L5k of the routine.

I am having a similar problem, but it is with a L40E processor and a Powerflex700 drive with 20-comm-e card. I have no problems at all unless the comms are broken (ENET cable unplugged, power failure, etc...), and it takes up to 10 min to re-establish messaging. I am able to get online with it via Drive Executive, so the ENET is working.

A control engineer I know thinks it may be a difference in the protocols the PLC-5 uses versus the newer Contrologix protocols the drive is probably using.

I am attaching my logic, which is exactly how the 20-comm-e manual says to do it. I only show one message of three as they are the same except for addressing.

Ok, so I now have an M1400 and an L35E to play with on my desktop. I have set them both up and have the programs running. It is still generating the same issue.

I wish there was a way to force the L35E to open a new socket.

I have been unable to find what is causing the 9 minute re-connection delay when performing the messaging code on the L35E side.

As a plan B, I have re-written all the code and placed it on the ML1400 side.

On the L35E side, I created to integer arrays. One for Incoming Data and One for Outgoing Data. Each array was defined with 10 integers each.

Using "Map PLC/SLC Messages" I assigned
I mapped these to file #s 100 and 101 respectively.

One the ML1400 side.
In the Message blocks I have done the following.

On the Multi-Hop tab I set the correct IP (that of the L35E) for both the Read and Write Message.

On the General Tab, I have chosen

Channel 1 (Integral)
500CPU Reads and Writes
Used file numbers N100:0 and N101:0 as both my data table address and my target address. Each "Size in Elements" set to 4.

Each set for Local
Each with a valid Routing Information File.

When I run the code on the ML1400, for both the READ and WRITE messages I am getting error # E0.

From the help file:
"E0H
An error has been returned by an Expansion I/O comms module. Refer to module documentation.
"

This error doesn't even seem to be in context to what I am doing.

Anyone have any suspicions on what I might be doing wrong?

Thanks

In the Multi-Hop window, press INS to insert another 'Hop'. Use the default "1" for ControlLogix backplane, then put a "0" in for the ControlLogix Slot Number.

For CIP Path purposes, CompactLogix and FlexLogix controllers are always treated as though they were ControlLogix in Slot 0.

Ken Roach said:

In the Multi-Hop window, press INS to insert another 'Hop'. Use the default "1" for ControlLogix backplane, then put a "0" in for the ControlLogix Slot Number.

For CIP Path purposes, CompactLogix and FlexLogix controllers are always treated as though they were ControlLogix in Slot 0.

Click to expand...

Ken,
I can't even begin to express my gratitude for your help! You hit the nail right on the head. As soon as I did that everything came up and running like a buzz saw.
And most importantly, when I cycle power to the ML1400, the comms comes back up within about 10 seconds. Wasn't the way I would have liked to fix the problem, but I guess I shouldn't complain about a working solution.

Thanks again!

Damian