Open Modbus/TCP

[PLCGuy]

What is this I am reading about Open Modbus/TCP? Is this different from the modbus I use with the ECOM100? If so, how will it effect using a ECOM100 with non AD equipment? I am not an expert on communications, so put it in plain english. From what I can gather, it has to do with using headers and removing the CRC stuff.

[Controls Guy]

Can you give us some links to see what you're referring to?  I suspect the authors are just making the point that Modbus and Modbus/TCP ARE open compared to other industrial networks.

The specs are public and you can get a copy without joining a group or paying a fee.  You can implement it easily without purchasing any proprietary protocol-specific hardware like a Profibus chip.

The protocol is SIMPLE.  There are a lot of other protocols that are published but which are so complicated to understand that it effectively closes them.  Take a look at any of the CIP protocols for example.

Finally, it's VERY widely used and common to many manufacturers, which makes it seem more open by better amortizing the work expended on drivers and so on.  If you can write one driver and then talk to devices from a hundred different manufacturers, that feels a lot more open than writing one and then all that work enables you only to talk to one or two manufacturers products.

[Controls Guy]

Oh, and as far as headers and the deletion of the CRC, that has to do with the difference between Modbus/TCP (Ethernet) and Modbus over serial such as RS232 or RS485.  I've also heard that some manufacturers embed a complete Modbus transmission, including CRC, in an Ethernet packet, but that's not the norm and not per the specification, AFAIK.

[franji1]

Supposedly there is a Modbus/RTU over TCP protocol that basically wraps the RTU packet.

Here's an excerpt from the Wikipedia article on Modbus http://en.wikipedia.org/wiki/Modbus.  Protocol Version #4 is what I'm referring to above:

Protocol versions
Versions of the Modbus protocol exist for serial port and for Ethernet and other networks that support the Internet protocol suite. Most Modbus devices communicate over a serial EIA-485 physical layer(1). There are many variants of Modbus protocols

1. Modbus RTU -- This is used in serial communication & makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.

2. Modbus ASCII -- This is used in serial communication & makes use of ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by leading colon (':') and trailing newline (CR/LF).

3. Modbus TCP/IP or Modbus TCP -- This is a modbus variant used for communications over TCP/IP networks. It does not require a checksum calculation as lower layer takes care of the same.

4. Modbus over TCP/IP or Modbus over TCP -- This is a modbus variant that differs from Modbus TCP in that a checksum is included in the payload as with Modbus RTU.

5. Modbus Plus (Modbus+ or MB+) -- An extended version, Modbus Plus (Modbus+ or MB+), also exists, but remains proprietary to SCHNEIDER ELECTRIC.

[franji1]

Oh, so it appears Controls Guy is correct - it's just Modbus/TCP, which is what ECOMs support.

[PLCGuy]

Thanks for the info.

[harncw]

I wrote a little test program that talks modbus tcp to a DL06 ECOM100 here:
http://globalsoftware-inc.com/harncw/ModBusTest.exe
it can read inputs and set outputs, counters etc.

It's still kinda rough, I should really add a logging functionality, and make it more generic.
That and wireshark should help demonstrate the packets being sent.

About the best set of specs I have found are here:
http://www.modbus.org/
the addressing of course is confusing

HTH

[Controls Guy]

Thanks, Harncw!  A little Win-based Modbus manual read-write utility is a VERY handy thing to have for troubleshooting Modbus comms.  If it's not working, you can sit on the other end of the wire from the master and act as a slave and vice versa, and find out who's not doing what to whom.  There's also a slick pair (one for master and one for slave from Modsoft.co.uk) that aren't free, but cheap.

[PLCGuy]

Nice harncw, I will have to try it. The only real problem I have sometimes is what to put for TX or RX in the ladder loggic. Sometimes it straight forward sometimes not. I have to sometimes change to octal to get the numbers right. This is the usual logic, LD K701 LD K4 LDA O40600 WX TA0. It is the WX or RX address that gets me gets me.

[franji1]

It is the WX or RX address that gets me

That's why the 260 and 06 implemented the MRX and MWX instructions - there is no DirectLogic->Modbus element address mapping needed to specify the "Modbus" Address.  You enter the Modbus Address offset, although it is RTU (serial) only.  We're currently working on a different version of MRX/MWX that will work with serial ports OR Ethernet, i.e. Modbus/RTU OR Modbus/TCP.

[Controls Guy]

Aw, c'mon.  Just make an Excel spreadsheet and use the DEC2OCT() function (may need to load the Analysis Toolpak).  Use drag-and-fill to create a range of Modbus addresses (because drag-and-fill won't increment in octal) and an adjacent column for the VMem equivalent address.  Some types need an offset, IIRC, but V's are just DEC2OCT(Modbus address).

[PLCGuy]

franji, how would that work? I usually have to find the address I want to start at. I don't always want to grab it all. I usually just want a few words worth or block from the other equipment.

[Controls Guy]

Not sure if you were directing that query at me, but I've attached ZIP containing a sample XLS.

The single value at the top allows you to type in a V-Memory address and get the corresponding Modbus address.

The column below demonstrates the practice of drag-and-filling the Modbus column and getting a translation table to V-Memory.