Modbus data type

[Henryp]

My SCADA software has the ability to read and write to a variety of data types using Modbus register addressing. The choices are integer, unsigned integer, float and BCD.  The data can be wrote in 16, 32 and 64 bit lengths.  The Do-More Modbus memory seems to be only for signed word and it doesn't appear to be user selectable.  So the question is how do I write a float to a Modbus register?

[BobO]

Do-more can easily do it, but the commonly supported function codes only access bits and words directly. Which side of the conversation is Do-more, the master or slave?

[BobO]

To elaborate further, the Modbus specification does not provide a direct mechanism for reading and writing anything but bits and 16 bit registers. For products like SCADA systems that support data types other than those supported by the specification, they must either extend the protocol outside the specification, or handle larger tags as multiple Modbus registers. My guess is that they do the latter.

I would guess that the SCADA system is the master and is reading and writing to Do-more's Modbus/TCP server. In that context, when they access Modbus Holding Registers (Do-more MHR memory) and Modbus Input Registers (Do-more MIR memory) for tags larger than 16 bits, they will be accessing 2 registers for 32 bit integer and float tags. Since Do-more is strongly typed, it is possible to use casting to reinterpret the data in MIR and MHR directly, but the preferred method is to use PUBLISH and SUBSCRIB. PUBLISH is used to copy data from Do-more native memories (like R and D) into memories like MIR and MHR, while providing required data manipulations like BCD conversion, BYTE/WORD realignment, and BYTE/WORD ordering. SUBSCRIB does the opposite, copying/manipulating data stored in MIR and MHR, and converting back to Do-more native.

[Henryp]

Thanks for the help, I got it working on the Do-More internal Ethernet port using Modbus.

The Modbus OPC-UA driver supports a variety of data types and can even do a Koyo to Modbus address conversion. I define the data type, starting Koyo address, starting Modbus address and a user defined prefix.  The tags then appear as standard Koyo V memory and the system automatically takes care of the octal to decimal conversion.  When talking to a Do-More using a Ecom nothing changes except the data goes to DL memory but if I use the native port them it goes to the Modbus registers.  So I had to figure out how to set it up.  Moving from a DL PLC to a Do-More takes some work. The biggest issues seem to be unlearning the DL way of doing things and trying to figure out how to address the data in my existing system.

[BobO]

Moving from a DL PLC to a Do-More takes some work. The biggest issues seem to be unlearning the DL way of doing things and trying to figure out how to address the data in my existing system.

By far the most common thing we hear is the need to unlearn old ways. We definitely do a few things differently, but I haven't heard a single person yet that regretted making the change. We do make you do a few things that DL didn't...the strong typing that makes Do-more math so nice, requires a little more structure than DL...but most feel that the limitations are small compared to the improvements.

Limiting Modbus servers to Modbus memory completely eliminates the octal to decimal conversion and mapping issues, but at the price of needing to map the data in the program. That may seem like a pain, but hopefully PUBLISH and SUBSCRIB reduce the pain a bit. And trust me, the Department of Homeland Security likes you much better when un-secured servers like Modbus/TCP cannot run rip-shod through your program. Stuff like that is becoming a far bigger issue and was one of the major driving forces behind our design choices. They are definitely studying the issue and the potential impact on security and we're trying to do our part as well.

[Controls Guy]

When the old ways were in fact workarounds, unlearning them is a good thing.

Strong typing is a perfect example.  Old DL required explicit conversion or the use of boxes specifically for a given type because the controller had no idea which format the data was in "V2000".  In DM you can freely mix types in a MATH instruction because the controller knows what type the number is based on the register address.  SO much easier!  AND, with casting you can still do it the old way (store floats in integer memory, etc.) if you want to or absolutely must for some reason without losing the option to mix them in math expressions.

[BobO]

Stuff like DL and Modbus servers in Do-more are definitely a tad less convenient in some ways than in DL, since in DL you could use Modbus to hit pretty much the entire controller, while Do-more limits your access. It's real, but that is roughly analogous to the frustration that Assembly programmers express when C takes away some of their toys. I didn't miss them for long, and when C++ made me do even more work than C, it bugged me at first, but I got over it. Today C++ is my language of choice, and I gripe when I have to go back to C...and let's not even discuss Assembly.

Pretty much everyone goes through the process of unlearning and bumping into the few things that Do-more makes 'harder'. It can be a little frustrating at first and may not be apparent how much is improved until you finish the project and realize your code shrunk by 70%, and again when you go back to DL for the first time.

But they come, they breath the Do-more air, and the change begins...

[Controls Guy]

Well, yes and no about the more difficult part.  If someone is willing to forego the sand-boxing and the advantages of memory typing, and the app will fit in 64K words, they can expand Modbus memory to that size and do the whole program in MHR.

Not that I recommend it, but my point is they really haven't given up any options they had with DL Classic.  They can still do it that way if they're really sold on it and still get the rest of Do-More's many advantages.

[BobO]

Hadn't thought about it that way, but MHR and MIR are no better or worse than V in DL. You could write your app using them and be no worse off than DL. But why...so much good stuff you give up...