Priority Interrupting Communication

[b_carlton]

Recently a thread at the AutomationDirect forum, http://forum.automationdirect.com/showthread.php?t=12266, led to my discussing a 'priority interrupt' method of arranging Messaging instructions, in the DL line using Stage, as to allow priority communications over a serial link to interrupt a routine cyclical series of Modbus messages. Mark seemed to appreciate it.

I want to utilize the Do-more in our systems but I need to be able to implement this 'interrupting' procedure using the messaging instructions. I understand the 'handshaking' is automatic and I don't see an easy was to interrupt a series of interlinked (round-robin) stages which are carrying out routine status interrogations. Maybe if I understood the 'automatic handshaking' a little better the method of implementing the 'interrupt' would be apparent.

Can a system be 'too helpful'?
 

[rlp122]

For me, I just let the reads be automatic and then enable the writes when they are needed.

[plcnut]

Bernie,
I would think that you could use a supervisory program to step through the communications that would be able to prioritize.
Would this do what you need?
(Just have all the Comms "Success" bits JMP back to S0.)

[franji1]

I think your design pattern of using stage for the "round robin" stuff, and then stick the "high priority" stuff at the top of the code-block will work in Do-more.  However, I think you always need to allow a full ladder scan to occur between the "round robin" stages so that the high priority comm gets a chance to "capture the device token".

To answer your question of how all the device-token-sharking instructions work...

The non-priority round robin could just work with an ST1 $On contact driving all your MRX/MWX boxes WITHOUT using any JMP, just SET OnSuccess/OnError.  The first one would see the device was available and grab it.  On that first scan, all the other ones would also be "armed" but would see that the device was NOT available (cuz the first one grabbed it).  Once the first one is done with the device, it would give up the device (even if it has power flow on that scan).  Always giving up the device is what makes the non-priority round robin "just work".  Hence, on the scan the first MRX gives up the device, the 2nd MRX (just like the other Modbus instructions below it) is still waiting for the device to be available - and now it is!  So it grabs the device immediately after the first one gave it up (i.e. one instruction later, not one scan later).  It holds on to the device for multiple ladder scans until IT is done (think 2400 baud RTU), and the next MRX in the same ST1 rung will grab it immediately.  This continues until the last MRX gives up the token and then on the NEXT scan, that first MRX (armed and waiting for the token), grabs the token.

However, when you want to do PRIORITIZED comm with round-robin, you can't do it this way.  As you see, the device becomes available for ONE INSTRUCTION in this example where the MRX instructions are next to each other in ladder logic.  This requires some complex interlocking, or as you posted on ADC's forum, you see the power of Stage and can also leverage the built-in Stage capabilities of Do-more device instructions (like MRX, MWX).

Rather than do some complex interlocking, I think if all you did was make sure there was always 1 full ladder scan between the "round robin" Modbus requests, the logic is very simple (yeah, you burn 1 scan time between comms, eh).  Stick the high priority stuff at the top so that whenever a "round robin" request from the SG portion below finished, ONE of these (if armed) would be able to grab the device.  I guess the only complex part is the interlocking between the multiple High Priority comms, along with the possibility of allowing the "round robin" stuff to "breathe" if your High Priority became "CPU hogs" (usually due to a logic error, but sometimes due to external events "lining up").  That's a different discussion.  Another way to implement the High Priority stuff is to stick THOSE MRX/MWX in their own PROGRAM code-block whose execution order is BEFORE the round-robin code-block (it just needs to be able to grab the device BEFORE the round-robin instructions execute).  By sticking that code into its own code-block, THAT program could be as complex as you need, keeping the "round-robin" code-block simple and elegant.

So, the round-robin Modbus requests where 1 ladder scan occurs between every request is actually quite simple if you JMP to SGs BEFORE the current stage in execution order, not the typical JMP SG is immediately AFTER.

STR HighPriority1
other-high-priority-interlocking-contacts
MRX1

STR HighPriority2
other-high-priority-interlocking-contacts
MWX2
...
STR HighPriorityN
other-high-priority-interlocking-contacts
MRXN

SG S10  // I'm numbering backwards on purpose to show the JMPs going "UP" the ladder, not "DOWN"
JMP S0

SG 9
MRX OnSuccess JMP S10

SG 8
MRX OnSuccess JMP S9

SG 7
MRX OnSuccess JMP S8
...

SG 1
MRX OnSuccess JMP S2

SG 0
MRX OnSuccess JMP S1

I hope this makes sense.

[franji1]

A typical application of prioritized comm is when you are polling a remote slave for data, gathering it up as fast as possible, using a bunch of MRX (Read) of various Addresses and/or Unit IDs.  However, when some event occurs, and you need to WRITE to a Modbus Coil or to a Holding Register, you usually want that to occur AT THAT POINT IN TIME.

[b_carlton]

Thanks for all the replies. I'll try this on our first major use of the Do-more. It looks like the backward JMP will be the key.

[BobO]

Can a system be 'too helpful'?

The implication of your question is that by helping you, we potentially get in the way. It really doesn't work that way though, or at least doesn't have to.

The low level comm driver is a finite shared resource. Since it can only serve one master at a time, we employ a token passing scheme that simply forces different requests to be processed in program order. The key here is that these instructions can operate either on a recurrent interval basis, or on an event basis. Building a prioritized system is simply a matter of creating the priority structure however you find convenient (stage, ladder based state machine, etc), and invoking the comms as events, rather than using the internal interval. Our internal token passing mechanism doesn't even com into play if you don't create multiple simultaneous requests. If you do choose to do simultaneous requests, we take care of allocating the resource so you don't have to be aware of it.

[b_carlton]

Thanks, Bob, for the clarification. I was under the impression that the built in sequencing would be in play even with the messages in seperate stages. Mark has helped a lot. His direction of 'backward jumping' to give the out-of-sequence messages a chance sounds like it will do what I want.

I'm sorry for the choice of "too helpful". The feature is great for automatic sequencing. It's my misunderstanding of the extent of the 'behind the scenes' interlocking. Thanks for a great product. 

[BobO]

Asynchronous device instructions run until complete, however complete is defined, and then signal completion. Completion can be signaled by setting a bit or performing a stage transition. The stage transition logic can be used to automatically sequence, but is in no way required to do so. We tried to give you all the tools we could think of, without actually forcing you to use any of them.