Parameterized network master instructions

[BobO]

Maybe I'm missing something, but in the DL series, if you wanted to read a Vmem location, you found the address, calculated the offset from the beginning of the address block, converted number formats, and send a modbus read. There is no mapping required.

What I understood from the previous comment (and what makes sense, give the editable memory blocks and references), is that you have to explicitly map address locations to exposed modbus addresses. Is this correct?

In DL, Modbus was mapped through the entire internal memory, and yes, you had to do some math to get what you wanted, but you could directly access everything in the controller.

In Do-more, any Modbus server/slave references the Modbus Mxx memory types, and only them. You can directly reference Mxx blocks from your program, so copying is only required if you don't want to use the Mxx locations directly in your program. If you do choose to copy, look at the PUBLISH and SUBSCRIBE instructions. They are designed to do exactly that, while performing any data conversions that might be required.

So why did we do it that way? Several reasons:
1) Modbus can't realistically map to everything in a Do-more controller, and since Do-more is dynamic, the mapping DL style would be a mess.
2) Modbus is not secure, so giving it direct access to everything in your controller is unwise (trust me, we've dealt with the Department of Homeland Security on this issue).
3) If I want to access Modbus Holding Register 187, it doesn't get any easier than MHR187. Whereas in DL, MHR187 is likely at V3721 or some other random octal numbered location.

[BobO]

If I create a data block called "MyBlock", I cannot use a MODBUS read from another PLC(or PC) to reference that block. I would have to use MOVE(R)/MEMCOPY to move MyBlock to another memory area accessible by MODBUS.

Correct? (I have never gotten deep at all into MODBUS)

Correct. For the reasons stated in the previous post.

[BobO]

Also, everything I said only applies to Modbus *servers*. The Modbus *client* instructions MRX/MWX have no such limitations locally...since they are part of the Do-more controller, they can directly access everything in the controller.

[plcnut]

Ok. That is what I thought.

[CReese]

Thanks. I just read all of the above in the *gasp* manual.

[BobO]

Thanks. I just read all of the above in the *gasp* manual.

Really?!? Wow...sounds serious.

[CReese]

Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.

Also, limiting the modbus registers has the downsides of both limiting the amount of data available over the interface (without constantly recopying data), and also taking memory away from the remainder of memory blocks.

I understand that this is not an issue for most use-cases, but 2048 << 65535.

[CReese]

 .... and then I discovered you can change the size of the modbus block.

[CReese]

So really, now that I think about it, you can occupy all or nearly all of the memory space of the PLC with Modbus-readable memory locations. The only effective limitation is then what you call the things. If I want everything to be readable over modbus, I can do that, but they all have to have that funny prefix.

[franji1]

One feature that may be helpful is that you can have multiple Modbus/TCP Client (Master) devices defined in Do-more.  Hence, you can have multiple Modbus/TCP transactions occurring at the same time (e.g. have 4 Modbus/TCP clients, and then spread your work across these 4 Clients to a set of slaves).

If you want to look at the next step, you could even "indirectly" address these Modbus Devices using the OPENDEV instruction of a "hard device" to a "Device Reference", taking indirection to yet another level.  We did think of that - see the basic idea of "indirect devices" in the Simulator example "BatchData1.dmd" in the C:\Do-more Designer\Projects\Examples\Do-more Simulator folder.  It just abstracts a batch report logger, one code-block logs to the "hard coded" PLC's @UserLog, another code-block logs to the "hard coded" @DmLogger application out the Ethernet port, the third code-block shows how to select dynamically at runtime where you want the logging to go via an X input - either to the PLC's log or DmLogger, using a common STREAMOUT instruction using a Device Reference, not a hard coded @userLog or @DmLogger like the first two code-blocks.

[BobO]

Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.

It's really an apples to oranges comparison, although I can certainly see the utility. As a tag-based system, that's the only way P3K can make Modbus work, so it is really a necessity. In Do-more, you can essentially do the same thing using PUBLISH and SUBSCRIB, but unlike P3K, you don't have to if you don't want or need to. I don't know for certain, but it wouldn't surprise me that they take a pretty big performance hit with the random access maps, probably in the Modbus server itself. We also incur a performance penalty with PUBLISH and SUBSCRIB, but that really is optional, and can also be minimized to a great deal if you don't need the values updated every scan. Another benefit of PUB/SUB is the ability to do data manipulation while transferring values. It's not unusual with Modbus to need byte swaps or other conversions between internal memories and Modbus. We make that pretty painless.

Of course like all things in the engineering world, it's all about trade-offs. You choose your view of the problem and design to mitigate the limitations of your choices. Do-more's angle is high-performance low-cost machine control and that drove many of our choices...good or bad.

[Controls Guy]

Maybe I'm missing something, but in the DL series, if you wanted to read a Vmem location, you found the address, calculated the offset from the beginning of the address block, converted number formats, and send a modbus read. There is no mapping required.

What I understood from the previous comment (and what makes sense, give the editable memory blocks and references), is that you have to explicitly map address locations to exposed modbus addresses. Is this correct?

No, it isn't a mapping issue where you map Modbus addresses to literal DM addresses.  Protocols like Modbus and DL Classic protocols that lack built-in security are limited to accessing dedicated areas within a DM processor.  The Modbus ones all start with "M", followed by abbreviations that refer to Modbus memory types.   MHR is Holding Registers, MC is coils, etc.  The DL stuff all starts with "DL" plus the DL memory type; DLX, DLY, etc.  So if you set up a DL client and write to C1000, your DM program would have to be written to look at DLC1000, not the native C1000 in DM.  Only native protocols that support the Do-More security model will be able to write directly to any address in the controller.

[CReese]

Just as a point of reference, the P3000 software looks like what I've attached here. Personally, I like the ability to map what you want, where you want.

It's really an apples to oranges comparison, although I can certainly see the utility. As a tag-based system, that's the only way P3K can make Modbus work, so it is really a necessity. In Do-more, you can essentially do the same thing using PUBLISH and SUBSCRIB, but unlike P3K, you don't have to if you don't want or need to. I don't know for certain, but it wouldn't surprise me that they take a pretty big performance hit with the random access maps, probably in the Modbus server itself. We also incur a performance penalty with PUBLISH and SUBSCRIB, but that really is optional, and can also be minimized to a great deal if you don't need the values updated every scan. Another benefit of PUB/SUB is the ability to do data manipulation while transferring values. It's not unusual with Modbus to need byte swaps or other conversions between internal memories and Modbus. We make that pretty painless.

Of course like all things in the engineering world, it's all about trade-offs. You choose your view of the problem and design to mitigate the limitations of your choices. Do-more's angle is high-performance low-cost machine control and that drove many of our choices...good or bad.

I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.

[plcnut]

I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.

I used up all the memory on my last project (within 2k bytes), and so to get all of my user data blocks to display on C-mores, I copied data into reserved (C, V, and D) memory space for my 2 HMI's. I just monitored the pages the C-mores were displaying, as well as using scroll buttons and was able to display large databases on the screen using only about 60 tags (a person can only look at one page at a time right?).
What I'm saying is with the speed and instruction set of the Do-more, indexing/copying data is fast, easy, and reliable.

[BobO]

I understand, and I'm sure I can get what I want using a combination of extended MHR blocks and subscribe/publish features. I don't think I'll hit the ceiling, but if I do I'll be forced to do everything using MHR save duplicated data space.

It works just like any other memory block, other than security considerations, which may well not be an issue. I name pretty much every variable anyway, so whether the block is called 'V' or 'MHR' or 'Beauregard' I don't much care. I know some here are pretty adamant about using block names rather than symbols, but other than awareness of where they are located for comm purposes, I prefer to treat Do-more as a tag-based system. Of course YMMV...