Different Communication Logic (A-B MSG)

[theColonel26]

I am re-writing a mess the last guy left me. And a question came up on MSG execution logic.


So this code is Reading and Writing to a MicroLogix 1400 from a 5570 series processor. (Testing locally on a 5370 though)

Normally I use UDTs with messaging and I use 1 UDT for Reading and 1 UDT for Writing for each set of logic.

Further, I normally will have a timer Trigger All of my messages at once, and then use an XIO msg.EN to make sure that it doesn't trigger if the message is still active, otherwise with certain slow networks some messages would never get a reply.

However what this guy was doing with chaining each message together so that the next message would only execute if the last was done and had completed without error.

What are the pros and cons?
First con of mine is that you could in theory overwhelm the target PLCs Network buffer but I am kind of skeptical of that happening under normal circumstances.

First cons I see with his are, messages can take a really lone time. Depending on scan time. Like he had this running in a 500mS process (timer was kinda useless).
The second con is that if one of the MSGs fail then the rest will never be called.


His Code

My Code

 

[Operaghost]

Yeah, not a fan of his way. Like you said, each message depends on the previous message succeeding. The other issue is when the timer resets and completes again, it will restart with the first message. If let's say the third message was executing at that time, the fourth message won't get a chance to execute.

I prefer your method.

OG

 

[plvlce]

His method could be improved by checking whether the previous message had finished OR errored out.

I definitely don't care for how the timer unconditionally resets the chain -- I've used something similar to his method for chaining messages, but it was in a situation where the messages were going to be manually toggled with significant intervals between.

 

[Contr_Conn]

Keep in mind that some small devices don't' have a buffer to handle multiple incoming messages at the same time, or this buffer is too small.
In this case if all messages going to the same target then sequential logic should be used.
On the Logix side, controller has limited number of outgoing buffers too, so it will be another reason to have the sequence.

 

[mylespetro]

I’ve definitely crashed a ControlLogix by exceeding 32 messages in the buffer before, something to look out for.

 

[TheWaterboy]

I do MSG's in sequence like the first example but using an OR of the ER and DN bits ( I also use a NOR of the ST and EW bits after that to see if the queue is full or its still transmitting after DN but not sure that really adds anything). I also change the default Timeout of the MSG from 30 seconds to 3.5 seconds. If it isn't done in 3 seconds it won't be, no sense waiting.

In my case its radio so I have a cooldown between sequence runs

 

[Saffa]

Since most of my messaging is over slow radio networks, I use a state machine with an incrementing counter. Each site has one read and one write block. Once a MSG completes or fails, the state machine state number is increased by 1.

Each MSG block is conditional with a EQU and the state number.

This allows me to jump the queue if the user wants to know the status of a particular site (force a data poll), then go back to where it was before the request. That requires a few extra bits of logic but is handy when there are 50 sites to message.

 

[TheWaterboy]

that's my technique too.

Anyone have have any thoughts about putting MSG's in periodic tasks instead of a continuous one? I have heard nothing concrete either way.