Modbus Reads and Writes

[RBPLC]

I have an application where I need to read and write to approximately 100 Modbus TCP registers on another device using a BRX. The registers on the remote device are not contiguous and span a total of approximately 16000 registers. I know there are many ways to do this but what is the most efficient way to do this? I would prefer not to have 100 MRX commands and 100 MWX commands reading and writing to the individual registers. I've considered filling a custom memory block with the register locations of interest and looping over the custom memory block and feeding those into the MRX command, but I don't want slow down processing by looping in this manner. I've also considered reading in the entire span of 16000 registers and then pulling out the values of interest with indexing, but I assume this is not efficient and will waste memory resources and slow processing down. Any ideas on how to do this efficiently/easily are appreciated.   

[BobO]

Pretty much all Do-more comm instructions are multi-scan and cannot be used with loop instructions, but it is very easy to construct loops out of stages. As you were thinking, I would create a table of source and destination addresses and loop through the table with a stage sequence.

[RBPLC]

In looping like this in a stage, what is the proper way to set up the MRX command/stage to handle the communication? Should I try to:

1) Loop through all of the addresses while remaining in one stage and then exit out of that stage once all are completely read?  In this approach I'm not sure how to set the enable bit. It seems as if you set it up as a leading edge and have it fire every scan this will be too fast for the instruction and will cause communication errors and if you set it up as a constant time this will slow all the reads down to the point that it will take many seconds to read all registers.

2) Set the MRX command to be a single shot in the stage, perform one read in the stage, upon successful completion of the read exit out of the stage, increment the index in the next stage and then loop back to the MRX stage to read the next value in the index?

Or, some other alternate/better way to avoid communication issues and an unnecessarily long time to read all of the addresses?   

[BobO]

In looping like this in a stage, what is the proper way to set up the MRX command/stage to handle the communication? Should I try to:

1) Loop through all of the addresses while remaining in one stage and then exit out of that stage once all are completely read?  In this approach I'm not sure how to set the enable bit. It seems as if you set it up as a leading edge and have it fire every scan this will be too fast for the instruction and will cause communication errors and if you set it up as a constant time this will slow all the reads down to the point that it will take many seconds to read all registers.

2) Set the MRX command to be a single shot in the stage, perform one read in the stage, upon successful completion of the read exit out of the stage, increment the index in the next stage and then loop back to the MRX stage to read the next value in the index?

Or, some other alternate/better way to avoid communication issues and an unnecessarily long time to read all of the addresses?

#2

[BobO]

And put all of the comm in a dedicated program block.

[RBPLC]

Thanks BobO for the guidance. I've attached what I've got so far (only looping through the first 13 indices). I've included a TMRA to "slow down" the requests. I've tried this timer at both 100 ms and 10 ms and both seem to work. Can you provide any guidance on how fast the MRX instruction can be triggered without causing communication issues (I know there are a lot of factors in determining this).

[BobO]

No limit. Run it flat out. Drop the timer and the $On, and just put the MRX on the first rung of the stage with no driving logic.

[BobO]

And look at the MATH IF() statement. MATH V0 = IF(V0 < ??, V0+1, 0)

[Bolt]

Here's a MRX/MWX program I use to poll multiple devices with pointers.  Have a look through it and see if there's anything that helps you out.  You should be able to paste it into a code block to see it all.

[RBPLC]

Thanks BobO and Bolt for the help.

[RBPLC]

Two additional questions related to the prior postings:

1) With stage programming, is it best practice to only run stages within its on program code block? What I mean by this is that inside of a program that has stage programming is it bad practice to have programming rungs before and after the stages that are not associated with the stages? If this is not bad practice, how would you include rungs that are below the stages that are not part of the stages (I don't see a command to bound the end of the stages) or would all no-stage rungs have to go before the first stage?

2) In reading in the modbus values previously discussed, some of my values come in for a specific register as a number (say 62 or 63) that actually represent a boolean state (say 62 is off or 0 and 63 is on or 1). Is there any kind of built-in mapping function in DmD that would allow me to map the incoming (62 or 63) values to their boolean meaning? One solution would be using the math function with the if statement described previously but I didn't know if their was an easier better suited built-in DmD command to handle this type of task.

[ATU]

1)There is nothing wrong with having logic before the 1st stage. If it needs to be on when that program is active, it is the best place for it. Any logic at the bottom of the program with be part of the last stage in the program. if you want logic at the end of the program, jump to the start of your sequence in your initialization stage (1st stage) and the last stage but never jump out.

2) Define symbolic constants in the Documentation Editor as your states for "ON" and "OFF". Then use the in-line compare with your register and the symbolic constant. If you had a slew of these, you could index through them and assign Boolean variables.
 

[RBPLC]

I've got the MRX working but now I need to expand this to MWX as well. Ultimately what I would like to do is first read from the remote device and then write to the remote device (same registers). This would allow for changes to be made at either the device in question and have them reflected on the BRX or make changes on the BRX and have them reflected on the remote device. What is the best approach for both reading and writing to the same addresses so that changes can be made on either end and will be reflected on the opposite? I'm currently trying this with additional stages (similar to the MRX stage) so that all registers to be read from are read first and then those same registers are written back to. Is there a common/best practice for getting bilateral communication between two modbus devices? 

The problem I'm currently having is that depending on when I make changes on either end, the changes might or might not be accepted depending on the timing of the read/write commands. The command change might be accepted or I might have to enter it several times because of read/write timing issues.

[ATU]

 If you are reading and writing, you may need some sort of handshake, if the other device needs it and is capable. I like to use the Read and Write coils function to set up a "Status" and a "Command" Structure.  There are multiple ways to set that up. If you are just writing to Remote outputs, it doesn't matter, you just write the data and the device does what it is supposed to do. The protocol takes care of making sure it got the data. If it didn't you will get a fault.  However, if the device is going to do something with the data, it may need to know when the data is valid to use. This is the case where you write the data and then set a GO or DataValid bit. Otherwise it may be operating on data that is halfway there.  It really does depend on how smart your device is and the application.

[Controls Guy]

If either device can write to the register and both keep a copy, then if there's a difference, you need to figure out which one to use, which may be difficult.   One way around it is to store the controlling copy of the register in only one location, preferably the one that needs that data most.   For example, if I have a register that can be written by the operator via the HMI, but can also be overwritten by the PLC, I have the HMI always displaying the PLC register, and also writing to it. If the PLC overwrites, you still see the up-to-date value on the HMI.

Both devices can read the register, both can write to it, but you never have to arbitrate which is the "right" value.