SLC5/05 MSG Instructions

[Ajwy]

Hi All, I have programmed some MSG instruction in SLC5/05 64k CPU series D FW 13 brand new cpu.
2 of the MSG instructions are direct IP to other 5/05s and 2 are MultiHop to 5/04s via a Control logix DH+/ RIO bridge. The Message instructions all are triggered by 10 second self resetting timers.
All the message instruction work fine, the problem is when I unplug the remote CPU's to test the Error messages.
First I removed the target 5/04 and the MSG timed out with no replay and i get the MSG Error bit on. Which is what I expected. ( everytime the MSG ins is enabled vai the free running timer the Enable bit blips on then straight back to error.) So no issues with this - normal behaviour.

When I remove the target 5/05 I get the error bit on for 3 seconds and the Enable bit on for 15 seconds. Even though it's a 10 second trigger timer. Which I know is the default timeouts for Channel 1 ethernet port. But my question is why the different behaviours for the MSGs. ? is it to do with one being MultiHop and the other direct IP. But if so why.

Any help greatly appreciated.

 

[OkiePC]

I don't have a specific answer to your exact question, but I do have a practice of manipulating the Message Timeout element of specific message instructions to cause them to return an ER bit sooner when the target device is offline.

With a Micrologix, the MSG instruction uses the MG file type which has all the elements labeled so I just force a value (in seconds) into the .MTO field of the relevant MG elements.

With the SLC, it is word 8 (starting with zero) of the Control Block.

With either PLC, the default Message Timeout value gets populated by the software when you enter the rung with the MSG instruction and I think it is based on the Channel configuration Msg Connection Timeout field.

In most of my MSG intensive applications, I am using a serial port, so I use the DN and ER bits to control the sequencing of messages. With Ethernet, it is so important to do that, but it is often important to know quickly when a remote device is not going to respond, and the default value of 23 or 30 something seconds is too long.

 

[TheWaterboy]

Ken would know precisely but I would surmise that the 5/05 fails immediately because the initial communication handshake fails. Whereas the one to the 5/04 reach the bridge for handoff so from the perspective of the MSG the initial part of the communication succeeded and its waiting for a reply place resulting in a different failure mode.

 

[OkiePC]

I don't have a specific answer to your exact question, but I do have a practice of manipulating the Message Timeout element of specific message instructions to cause them to return an ER bit sooner when the target device is offline.

With a Micrologix, the MSG instruction uses the MG file type which has all the elements labeled so I just force a value (in seconds) into the .MTO field of the relevant MG elements.

With the SLC, it is word 8 (starting with zero) of the Control Block.

With either PLC, the default Message Timeout value gets populated by the software when you enter the rung with the MSG instruction and I think it is based on the Channel configuration Msg Connection Timeout field.

In most of my MSG intensive applications, I am using a serial port, so I use the DN and ER bits to control the sequencing of messages. With Ethernet, it is not so important to do that, but it is often important to know quickly when a remote device is not going to respond, and the default value of 23 or 30 something seconds is too long.

I wish I had a nickel for every time I review my own words and found a major error.