Do-more with multiple Modbus-RTU slaves.

[mvisto]

Hi,

I have 2 separate systems, one with 7 and the other with 12 modbus serial slaves (vfd's, other controllers) with occasional writes and being continuously polled for information from a Do-More PLC.

The MRX, MWX code for each slave is contained within its own Program block.  This then overwhelmed the serial port and created too much lag in the system.  The serial speed is capped at 19200 by one of the slaves that cannot be changed.

To try to minimize the lag, I modified the MWX writes to only occur when the associated value changes by using a delta contact. The MRX reads are now on a timer/counter system.  As an example, 12 slaves with a polling interval of 1000 ms gives 1000/12 = 83 ms for each slave.  The counter is incremented every 83 ms from 1 to 12 and each slave can only read when its counter number is available.

These changes helped tremendously but I was wondering if there was still a better way to speed up the lag in the system. It is probable that 83 ms is too short for each slave to complete its polling during that time.  The 7 slave system is more responsive than the 12 slave.

Most of the perceived lag is because the writes take too long to respond.  a consideration would be to have the MWX writes take precedence over the reads. Maybe there is some way to flush the Do-More serial buffer of the reads and allow the write to go first.

As I was thinking this through and just now starting to understand Tasks vs. Programs, I am beginning to realize that having multiple programs is contributing to the lag. Each program runs continuously simultaneously instead of one at a time in sequence.  So all slave were polling continuously until I created the timer/counter. Initial lag was on the order of 10-15 seconds for the 12 slave system.  Currently there still seems to be about a 2-4 second lag in the system.

I have not used stages in the past and I am currently reading up on this wondering if this is the way to proceed.  I am also considering changing the slave programs to tasks and eliminating the Timer/Counter system and have each task run in sequence using stages. Maybe I should combine all of the modbus slave coding into one program to facilitate the stage concept?

Does anybody have any suggestions or experiences with multiple modbus serial slaves that could point me in the right direction?  I would really appreciate your thoughts.

Thank you,

Marty.

[b_carlton]

We did multiple Modbus slave interfacing easily in the DL series using sequential stages creating a round-robin chain. Write pre-emption was achieved by placing their stages before the round-robin chain.

But this became difficult in the Do-more because the instructions handle the 'port busy' in the background. Franj1 suggested a work-around for the Do-more. (I didn't get a chance to test this though.)

Place all the communications in one program with each in its own stage. The trick is handling the 'jump to' targets. Place the individual 'write' stages at the beginning. These just terminate on completing. Enable these stages individually by setting them. Next place a 'dummy' stage whose only logic is to jump to the end stage of the chain. This is because the 'read' stages each jump to the PREVIOUS stage. Thus the last (or first numerically) stage will jump to the previously mentioned 'dummy' stage.

The whole purpose of this is that as each read stage completes the scan must pass through any enabled 'write' stages so that they may pre-empt the chain of communications. Once any pending 'write' are done the 'read' daisy-chain can continue on as if nothing had happened.

Give it a try.

[BobO]

It's not really a workaround Bernie, since Do-more hasn't taken away anything. It just handles basic round-robin sequencing internally, so you aren't required to do so externally. Any method you used under DL is still available to you in Do-more.

As Bernie suggested, if you want to control execution order, just put each box in it's own stage. You can then affect the relative priority of each by controlling the execution sequence.

[mvisto]

Thank you for your suggestions. I am starting to visualize how the stage will help. Never considered the reverse stage, first at bottom, concept to control the program flow across scans.  I might have another question about logic flow after I try working through it.

Like B-Carlton, I am used to controlling the network with the port busy flag. Also, with other plc's I have used, all ladder logic was sequential, no simultaneous ladders running as can happen on the Do-More with the Program concept. As I continue to discover these things in the Do-More, I become giddy with the additional power and cannot seem to work very well without these features.

On a side note:  I have been reading about the serial port and Do-More and how we do not need to worry about the port busy flag concept anymore. I am trying to understand how this buffering works.  How does the Do-More buffer handle multiple MRX/MWX requests? At some point, I assume that the buffer must overrun. So is there some limit to how many "port requests" are buffered? Or does the Do-More just understanding that the "next" MRX/MWX command fired is the next one to be sent when it occurs in the ladder code? Then, there seems to be an issue with using simultaneous Programs that will pile up all of these read requests.

Maybe an example would help illustrate:

Program 1
MRX1
MRX2

Program 2
MRX3
MRX4

Questions:
Program 1 and 2 are running and currently MRX1 has the port. MRX2, MRX3, and MRX4 will then be buffered waiting for there turn on the same scan. Next scan then; MRX1 is not yet completed...will MRX2, MRX3, and MRX4 be buffered again?  Or will the buffer just hold 1 instance of each MRX?  As soon as MRX1 completes, MRX2 will be sent into the serial port (is this triggered by a scan or by the buffer) and MRX1 will be added to the end again on the next scan? Buffer now hold MRX3, MRX4, MRX1..??

It would help if I had a little background on what is happening behind the scenes with the MRX/MWX and the serial port. This would be beneficial to understanding how best to manage the program flow. And besides, I just find it interesting and like to learn...

Marty.

[franji1]

Check out this post from nearly 4 years ago (whoa!).  It describes how the basic token passing works, along with details on how to get a prioritized WRITE to occur pre-emptively

http://forum.hosteng.com/index.php/topic,1228.msg10416.html#msg10416

[BobO]

On a side note:  I have been reading about the serial port and Do-More and how we do not need to worry about the port busy flag concept anymore. I am trying to understand how this buffering works.  How does the Do-More buffer handle multiple MRX/MWX requests? At some point, I assume that the buffer must overrun. So is there some limit to how many "port requests" are buffered? Or does the Do-More just understanding that the "next" MRX/MWX command fired is the next one to be sent when it occurs in the ladder code? Then, there seems to be an issue with using simultaneous Programs that will pile up all of these read requests.

It's not being buffered at the serial port level. The serial port is owned by the Modbus client driver, and it is only executing a single instruction at a time. When you enable an instruction for execution, all you are doing is raising your hand to request service, the instruction doesn't do any work. The driver moves to the next instruction after completion. If you enable every instruction at once, the result is a simple round-robin in code execution order.

For simple comms, it is generally good enough to enable all boxes and use the instruction's interval value to prioritize. In cases where that isn't good enough, you externally sequence through any of several possible methods.

[mvisto]

Got it.  Thanks for all of the clarification.  I was assuming so type of serial port buffer.  I will be able to make modifications to the code now.  Hopefully there will be a significant speed increase.  Just prioritizing the write will be a substantial improvement.

Thanks everybody for your help.

Marty.

[BobO]

I was assuming so type of serial port buffer.

Most serial protocols like Modbus are half duplex with only one outstanding transaction. For multi-drop protocols (like Modbus RTU over RS485) it's impossible to do any other way. There are some point-to-point master/slave protocols that support multiple outstanding transactions, but they are pretty rare.

[Garyhlucas]

Check out this post from nearly 4 years ago (whoa!).  It describes how the basic token passing works, along with details on how to get a prioritized WRITE to occur pre-emptively

http://forum.hosteng.com/index.php/topic,1228.msg10416.html#msg10416

Four years?
I've got some DL205 plcs that have been running for at least 18 years now!
You know once you get past 60 four years is like a blink.