EtherNet/IP gurus

Not necessarily. Usually they're conditioned with what ever logic should cause the message, in series with "XIO MSGx.EN".

In this manner the XIO MSGx.EN (read as "message x not enabled") bit basically acts as a oneshot. Once the MSG has been scanned as true, it will be que'd and the EN bit will stay set until it gets DoNe or ERrors.

If your logic stays true for a duration, but you only want one message per false to true transition, then use a oneshot.
If you leave the message rung true, with out the conditions, the controller will know it already enabled that message and won't keep doing it, however it may use a little more scan time figuring that out. Now, if the rung goes false and true multiple times, you will get multiple messages.
At least that's been my somewhat limited experience with them. Hopefully, an expert can confirm or correct me on this.

Well I'm not an Ethernet/IP guru but I concur with OkiePC.

But one other question, what are your trying to communicate with?

I’m communicating with a PC.

I guess what I really want to know is, if the MSG is enabled does it try to complete the message until it is done or the timeout is meet even if the rung has transitioned to false.

If the MSG was enabled using a one shot will I see the .ER bit if the message fails?

If you fire the message off of a bit that you toggle it will execute once and set the DN bit when completed or the error bit if something goes wrong. No ONS is needed

If you want to continuously execute the message then you use the XIO the enable as mentioned before. The only problem with doing this is the error bit, ERR code, and ExERR code are hard to catch. I do this to get the error bits if continuously executing


BTW, what do you have on the PC end to communicate with the Controllogix?

Very good points made by both posters.

The MSG instruction executes once on a false-to-true transition of the rung. Using the XIO MessageControl.EN bit is a good practice, as is the error trap.

I don't like to continuously execute messages, both to save bandwidth and to avoid any possible problems in the Logix execution queue. There was a bug back in v6 or so in which an operating MSG instruction that had not completed would prevent the controller from entering Program mode, and I never abandoned that practice.

If I have an I/O connection also to the device I'm sending the MSG instruction to, I execute a GSV to determine the status of the connection before I execute the MSG, so I avoid trying to make a connection to a device that might be disconnected from the network.

Another very common practice in ControlLogix is to manually set the .TO timeout bit in the control word after a MSG instruction has been enabled but not completed or errored for a period of time. Unlike the SLC/PLC5 MSG instruction, there's no native timeout in the message instruction itself, so it depends on the link layer to provide a connection error if the message can't get through.

Do you guys see any problems using a MSG like this?

Nothing wrong with it but you don't need the ONS. This will do the same thing as far as I can tell

Thanks for the help!

Just curious.

Does anyone here use the error bit to display a fault message (timeout) or do you just reset the error bit and keep trying.

I don't even address the error bit in my program. I used the ERR code and ExERR code to display a fault message associated with the particular code on a display. Much better then just saying the message is broke

I do use the .ER bit to display a comm fault for the specific device I’m trying to communicate with, it is just used as a generic comm fault. The .ERR would be a more specific fault indication.



Thanks again for the replies.