Modbus I/O Scanner vs. Ladder Boxes

[Controls Guy]

I have an application where one BRX is MWXing and MRXing to another BRX.    Now I'm using some Modbus/TCP remote I/O (for the MxX target BRX).   Is there any benefit/drawback for converting the inter-BRX comms to Modbus scanner on the client?    The only potential thing that I could think of is that the ladder boxes can be activated via conditional logic (I'm doing them cyclically anyway), but I could hit the .Enable bits on the Modbus scanner too.    So as a slightly broader question, is there anything that differentiates between the scanner and MxX in general?

Second question: is there a way to hit private (non-Modbus, non-DLx) registers in one BRX from another?    I realize Peerlink, but in my case I'd end up needing to move the data anyway, so no particular advantage there.    My application (again due to I/O availability) would be to try to control one of the server's I/O from logic in the client with minimal code.

[franji1]

RX/WX is native to native - able to access any built-in or even user block (need to add support for heap items, but that is not as obvious in the existing Designer implementation).  No need for hacking MHR/MC/Mwhatever by the Do-more slave device.

In Rel 1, native RX/WX was not available, but RX/WX was added later at some point.

The Modbus Scanner is great for publishing/polling smart Modbus devices.  CAN it be used w/Do-more Slaves?  Yes.  But I would think that the preferred mechanism is native RX/WX?

So when doing typical "scanning" point to point (non-global PEERLINK) peer comm (between Do-more PLCs), I believe the preferred prioritized list is:
1. RX/WX
2. Modbus Scanner
3. MRX/MWX
(Note that PEERLINK can be utilized over #2 or #3 for a data share between multiple Do-more PLCs)

If it's event driven (i.e. only need to write or read based on an event, not polling) then
1. RX/WX
2. MRX/MWX
where the event edge triggers the above instructions

I don't know if I answered your question or just raised a bunch more. 

[Controls Guy]

RX/WX is native to native - able to access any built-in or even user block

OK that's the answer for this particular application.   I can borrow the server BRXs
Y15 and WY0 and control them from the client/master.   Perfect application.

The Modbus Scanner is great for publishing/polling smart Modbus devices.  CAN it be used w/Do-more Slaves?  Yes.  But I would think that the preferred mechanism is native RX/WX?

Not necessarily for me.   I have this weird belief that it's good practice to modularize an application, so the links between items are well defined, minimized and vendor-independent.   Thus, I use Modbus  even between an HMI and a PLC of the same brand where Modbus is not the native default.   That way if I have to change out my selection of  A it doesn't break B and vice versa.   Also, in this particular case, the relevant registers are Modbus anyway so RX/WX doesn't have an edge there.

If it's event driven (i.e. only need to write or read based on an event, not polling) then
1. RX/WX
2. MRX/MWX
where the event edge triggers the above instructions

Ah, you've refreshed my memory.   That was what I was thinking was the advantage of ladder boxes over scanner, event triggering, since the scanner is inherently cyclic.    Although....it did occur to me that you could probably make the scanner event driven if for some reason you wanted to by entering a long cycle time and hitting the .Enable with a pulse in ladder.

Thanks, this sorts it out, and good to know there's a way to get to 'private' memory areas!

[Controls Guy]

The WX target register (for a bit) has to fall on a byte boundary.   Can this be changed or does it come from the way DM protocol works?

[BobO]

The WX target register (for a bit) has to fall on a byte boundary.   Can this be changed or does it come from the way DM protocol works?

Protocol optimization. Unaligned bits are a performance nightmare.

[Controls Guy]

Got it, that's what I assumed.  Thanks!

[Kristjan]

Thank you guys for an informative dialog 

I would like to add my two cents to the subject: I was quite excited when I discovered the Modbus I/O Scanner a few months back. Got this implemented in a system (with a new device from scratch) but soon found out that I wanted to add some more registers to the polling (read/write more registers from the actual device). And when you change a Modbus I/O Scanner device configuration you can't to a RUN-mode download to your PLC, i.e. a little "more serious" process than only a program change. And I dislike stopping/starting once a system should be up and running. And I felt kind of claustrophobic not being able to freely explore the registers 

So for this particular application I went back to MRX/MWX and feel more free to change the device registers that I am working with. Of course this comes with the cost of more ladder rungs but it's a relatively small system so it doesn't hurt.

My current view is that the Modbus I/O Scanner fits very well where you have a solid Modbus solution and you are confident about which registers you will be using. If - on the other hand - you are developing a solution and still trying out which registers are neccessary and/or nice to have, I would go for MRX/MWX and rather consider migrating to Modbus I/O Scanner once you have gained confidence in your solution.

[BobO]

Did you see the MSREGRD and MSREGWR instructions?

[Kristjan]

Did you see the MSREGRD and MSREGWR instructions?

Yes, I saw those already but in my case they would only be a patch to the MBScanner and I would also need to trigger these instructions separately. So it feels more transparent to just use MRX/MWX while still developing the solution and then migrate to MBScanner.

I expect to utilize the Modbus I/O Scanner in a project before too long.

[Controls Guy]

The other trick I've found is to read the entire server accessible range if of reasonable size (like you can read the entire thing in a single poll), then map to a custom UDT laid out to match the internal device data layout.    Then you have meaningful register names and you always have access to all device data with no run mode transition.