MRX MWX Modbus RTU Strategy

[BobO]

Messes with your head a bit, but it's correct.

When either of C1 or C2 is selected, the EXIT will execute after two scans. Then a couple of scans of overhead to terminate and then rearm. So each execution takes 4 scans, and will have run 2...4/2=2.

When C3 is selected, the EXIT will execute after 1 scan, with the same 2 overhead scans...3/1=3.

[Mike Nash]

Messes with your head a bit, but it's correct.

When either of C1 or C2 is selected, the EXIT will execute after two scans. Then a couple of scans of overhead to terminate and then rearm. So each execution takes 4 scans, and will have run 2...4/2=2.

When C3 is selected, the EXIT will execute after 1 scan, with the same 2 overhead scans...3/1=3.

Thank you Bob. I did not suspect overhead scans. Even knowing this, it is still messing with my head trying to step through it on paper. I would want to single scan or fill a table or something just to "see" this. The location of the R0 calculation doesn't help. As enough counts accumulate it all averages out, but I had noticed R0 seemed erratic when first started.

I'm getting little warnings in my head now about how I need to get a better handle on programs, tasks and subroutines. Tasks and subroutines actually feel a lot "safer" at the moment. I expect a subroutine to come right back with its results and tasks to get done whenever they are good and ready, especially if yielding comes into play. I will need to be more careful in my considerations of programs running other programs.

[BobO]

Programs and tasks are essentially the same thing. Only difference is how they start and end, and programs can have stages.

The overhead scans are related to termination of the stage and of the program block. Termination is the magic that makes those pesky interlocks work right. And tasks terminate too, btw.

[Mike Nash]

The overheads are fine, they just caught me out while trying to understand why the .Done was retriggering the RUN. And that came about due to:

If you did all this in its own program code block and set all the V array indexes before the RUN, and EXIT when done, and monitor the program's .Done bit, you could use PD contacts in that program.  Then set the V array values for the next RUN from $Main, looking for .Done, ...

And lo and behold I stumbled across this thing called Stage Programming and it all came together and just worked!

[plcnut]

I am a big fan of Stages as well as Programs/Tasks.

A helpful little tidbit is if you right-click in the project browser and then select sort>>Code-blocks>>Sort by execution order. This allows you to see the blocks in the order that they will actually execute. When Main executes a RUN to another program block, it will execute that block when it gets to that blocks 'slice' of the scan time. There may be other blocks before it, and there may be other blocks after it. If the result of the program/task block is needed for another instruction, then I always use stage programming. It works great for monitoring exactly when I call the block, and knowing when it gets done.
BTW the .doneThisScan (sometimes with a NC) is another very useful tool for edge triggering.

Another thought on stages that can make them *seem* unpredictable. If you JMP forward, then that stage will execute in the same scan, but if you JMP to a previous Stage, then it will not execute until the next scan.

Also, in you screenshot you have a JMP to stage 0 inside of Stage 0. 

EDIT: I corrected my comment about JMP to a previous stage as noted by franji1 in the next post. Thanks franji1!

[franji1]

but if you JMP to a numerically lower Stage, then it will not execute until the next scan.

Just a quick mention that stage numbers do NOT have to be increasing, or even sequential, so the condition for it executing on the NEXT scan is based on the location of the Jumped-to SG PREDECING the JMP instruction.  You could have

Code: [Select]

SG S100  // initial stage
JMP S0  // enables S0, disables S100, but remainder of S100 logic will still finish executing THIS scan
...  // WILL execute THIS scan (because JMP does not physically JMP, so the logic BELOW the JMP S0 still executes THIS scan)

SG S99  // not enabled on THIS scan, so does not execute this scan
JMP S100  // ditto
...  // ditto

SG S0  // executes THIS scan due to JMP S0 above inside S100 enabling S0
JMP S99  // enables S99, disables S0, so S99 will execute on the NEXT scan, regardless that its number is higher than the current S0

[Mike Nash]

Also, in you screenshot you have a JMP to stage 0 inside of Stage 0.  

... or the JMP can jump right back into the stage you are already in (which will re-run the program).

I was pretty sure someone else had suggested this one.  

Does anyone remember playing "Mother May I?" It comes to mind with this stuff.

[plcnut]

Also, in you screenshot you have a JMP to stage 0 inside of Stage 0.  

... or the JMP can jump right back into the stage you are already in (which will re-run the program).

I was pretty sure someone else had suggested this one.  

Does anyone remember playing "Mother May I?" It comes to mind with this stuff.

I missed that somehow. I have never used that trick before... Thanks!

[BobO]

And lo and behold I stumbled across this thing called Stage Programming and it all came together and just worked!

You said stumbled, but the picture in my head was you having your shoelaces tied together, and being placed in dark room surrounded by boxes of Stage programming. Sorry.

Maybe someday you'll use it because you like it, but as long as you get good results with whatever you choose, I'm happy.

[Mike Nash]

Closure. The system is packed to ship and works great. Managing to read and write each device 1-2 times per second for 24 Modbus RTU devices. I was just using the slope instruction on successes with 1 second sample time and only using integers, so no exact number here. That's just one serial network, there is another running too, though with fewer devices. That's ALL devices serviced every second for 24 + 16 devices.

I was sad when the scan time hit 1.0 mS after adding all the discrete logic ladder to the indexed Modbus routines which were around 500uS scan. It bumped to 1.1mS with two Ethernet HMIs and a laptop running DmD.

And yes it does have Stages.

[BobO]

Awesome. Glad it's working well.

1.1ms is hardly the end of the world, but if you have any lengthy sections of logic, you could put them into a task and insert YIELD instructions to break up the execution.

[Mike Nash]

I was actually surprised how much the coms update rate dropped just doubling the tiny scan time. When I only had one "device" active and all the rest disabled in logic I could hit 12 times per second (tps) read/write. Adding the "digital" logic always active dropped that to 8 tps. Considering it is now 24+ tps per network with multiple "devices" all active, I'm really pleased.

I tried yielding, but there weren't any For-Nexts or goto's, etc., so it made no difference I could tell. I did find the ability to suspend the various programs execution informative.

I am quite happy with the results. There were over 240 multi-branched rungs for the logic section with 40 timers, etc. I considered indexing (not looping) these also, but felt troubleshooting would be more difficult and 40 mS to update logic status per device didn't appeal to me either.

And the 1.1 mS sadness was tongue-in-cheek. It was just pretty amazing to see 511 uS scan time for the serial coms only.

[BobO]

And the 1.1 mS sadness was tongue-in-cheek. It was just pretty amazing to see 511 uS scan time for the serial coms only.

I thought so. As a designer, I'm always thinking faster, but the ADC techs love to remind me that I'm way out there compared to what customers need and expect.