Establishing Modbus TCP communication

Hello everyone

I am trying to implement Modbus TCP communication with Venus GX( Victron Energy Product )and TMS570LC43x( Texas Instruments Launch Pad ).

I am stuck with the coding part. I am having very limited knowledge in coding.

Can anyone kindly guide me in right direction in order to achieve it.

Regards: Advaith
 
A while ago there was a topic on this. Don't make the same mistake by using the wrong ethernet cable type. If you're making a point to point connection (without a switch) you should use a crossed ethernet cable, otherwise use a switch when you connect both units. Modbus TCP uses ports (502 and 1024) that must be open.
 
mrechtorik:

Quite a list of issues. The first one, zero-based addressing vs one-based addressing is definitely a common issue.

Your statement (2nd Complication):
"Since Modbus only defines binary and 16-bit unsigned variables (sent as big-endian, i.e. higher byte first, then lower byte), various implementations have defined the remainder as needed by reinterpreting the data."
is not quite correct.

Modbus defines the order for serial transmission of bits from a Modbus register; it does not define the bit or byte order of the data itself in the register.

The definition that you refer to is the serial transmission format (from the Modbus register) - the high order byte is transmitted first, then the low order byte as defined in Section 4.2 in the "MODBUS Application Protocol Specification V1.1b" .

It can be confusing. The topic occurred here, recently:
https://control.com/forums/threads/endianness-for-32-bit-data.48584/
 
Thank you for your comment!

If we talk about a 32-bit integer number with a hexadecimal representation 0x11223344, then individual bytes will be sent in order 11, 22, 33, 44 (highest byte first, lowest last). Actually, the standard talks only about a big-endian sending of the register; however, so far I've not met an implementation that would claim a "big-endian" format and send data differently from 11, 22, 33, 44 in my example. However, for little-endian, there are 3 options that are described in my blog.
Altogether, the big-endian together with 3 little-endians result in 4 options that are displayed in a picture in your topic (https://control.com/forums/attachments/honeywell-floating-point-formats-jpg.175).

Quite a different question is how to interpret the received data 0x11223344 (signed/unsigned int, 32-byte float).
 
Modbus defines the order for serial transmission of bits from a Modbus register; it does not define the bit or byte order of the data itself in the register.

The definition that you refer to is the serial transmission format (from the Modbus register) - the high order byte is transmitted first, then the low order byte as defined in Section 4.2 in the "MODBUS Application Protocol Specification V1.1b" .
Very interesting, I've never actually thought of it this way. I've always just equated "data" to "register".

So to take this a step further, does this mean that for a standard 16-bit Modbus register, it's possible that a client/master would need to byte-reverse the "register" value read from a server/slave in order to obtain the proper "data" value? For example, if the server/slave's "data" value is 0x1234, the vendor of the server/slave device may implement encoding that value into a register as either 0x1234 or 0x3412? So even if the "data" value is 0x1234, the "register" value may be 0x1234 or 0x3412?
 
The specification states: "MODBUS uses a 'big-Endian' representation for addresses and data items."
Each data item is bit-addressable or word-addressable.

So, the byte order is defined clearly by the latest specification.

Unfortunately it wasn't that clear in the previous specifications and that's the reason why there are so many different implementations around.

Even more "de-facto standards" developed over the years if you think of the different ways to provide access to 32-bit data or more (e.g., floats) and how all of the typical data types were mapped onto the 16-bit register structure.

In the end you'll find some Modbus tools that support all of the different byte orders and there are server devices available that let the user select the desired endianness.
 
I understand how industry conventions can evolve and deviate from specifications, so I can't argue that there are some implementations that exist that require other devices to be flexible in selecting different word ordering and byte ordering to be compatible. However, although they exist, I would argue that some of these implementations violate the Modbus specification.

Even the old Modbus spec, PI–MBUS–300, from 1996 specifically states on page 29 in the description of the response format for function code 03 Read Holding Registers:
The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits.
https://modbus.org/docs/PI_MBUS_300.pdf

So of the 4 formats shown here, https://control.com/forums/attachments/honeywell-floating-point-formats-jpg.175, I would argue that only the "FP B" and "FP LB" formats adhere to the Modbus specification (of course these formats specify 32-bit floating point, but they apply equally for 32-bit integers).
 
I always considered Schneider's PI MBUS 300 doc to be their specific implementation of Modbus, so I checked FC01, FC02, FC03, and FC04 in the 'official' MODBUS Application Protocol Specification V1.1b3, dated 2012, to see if it states the data byte format within a register, like the quote from the Schneider document.

Lo and behold, the official Modbus spec confirms the Schneider document for byte order in a register (given that Schneider is inheritor of the Modicon spec, one expect concurrence, but you never know . . .). I've probably read that FC03 section 5 or 6 times a year for the past ten years and I always skipped over that line because it wasn't what I was looking for.

So, I stand corrected, the Modbus spec does indeed state a byte order for the data.

And I would concur with JSchulze's observation and argument that only the FP B and FP LB floating point formats adhere to the Modbus spec.

I learn something every day.

Here are the statements for FC01, FC02, FC03 and FC05 from the Modbus spec:

FC01 defines bit byte order.PNG

FC02 defines bit-byte order.PNG

FC03 defines the byte order.PNG

FC04 defines the byte order.PNG
 
I understand how industry conventions can evolve and deviate from specifications, so I can't argue that there are some implementations that exist that require other devices to be flexible in selecting different word ordering and byte ordering to be compatible. However, although they exist, I would argue that some of these implementations violate the Modbus specification.
I can't, won't, and don't want to argue with this. However, when we deploy our D2000 SCADA system, we are not in a position to persuade a PLC manufacturer that their Modbus implementation is not according to the standard. All we can do is to adjust our communication driver and add another parameter (be it for endianness, register size, or something else that does not conform to the Modbus specification. And if you read my blog about common Modbus complications, you already know there's a lot of non-conforming devices in the wild :)
 
I can't, won't, and don't want to argue with this. However, when we deploy our D2000 SCADA system, we are not in a position to persuade a PLC manufacturer that their Modbus implementation is not according to the standard. All we can do is to adjust our communication driver and add another parameter (be it for endianness, register size, or something else that does not conform to the Modbus specification. And if you read my blog about common Modbus complications, you already know there's a lot of non-conforming devices in the wild :)
This is absolutely true and is an unfortunate part of the current state of Modbus devices. We've also had to make accommodations like these with our communication gateway and interface card products. The customer doesn't care that a device doesn't follow specifications, it just needs to work with the other device(s).

With many communication protocols there are certifying bodies that test the conformance of products and award conformance certificates, or at the very least, provide a conformance test tool that the vendor can use to self-test their products for conformance. Many of these organizations, such as BACnet's BTL, have pushed end customers to seek BTL Listed products, so customer awareness and demand of certified products is growing.

It does seem that Modbus has conformance testing (https://modbus.org/certification.php), but the test specification is in no way exhaustive (it's only 11 pages) and I don't believe I've ever actually encountered a device that had a Modbus conformance certification.

Great article on your blog, I'm sure many Modbus users here, both new and experienced, would benefit from reading it.
 
Top