I am realizing Modbus Protocol with Vc++ for a SCADA software now.

My question is,there are several versions of Modbus protocol ,such as Modbus, Modbus plus and Modbus TCP/IP. Then, can i make just one DLL for these protocols and distingish them by some statements in program,or,for them great difference ,i should program separately.

I am waiting for your advice. Thanks a lot.

 

If your tool will compete in the software market place then you should combine all three permutations of ModBus into one driver. Most of the big boys (In-Touch, iFix...) and OPC/ActiveX tools (In-Gear, Modicon's OFS...) already do. No doubt your customers will compare you to their producs. Good Luck.

 

I'd plan on 4 "modules" - I don't speaK DLL, so don't know how those relate. The basic Modbus "protocol data unit" or command is common to all 3 you mention. So 1 module to manage the PDU and 1 module for each of the 3 transport methods you mentions. (I'm not specifically using the terms PDU or transport in an ISO/OSI sense).

So Four Modules:
1) the modbus message (without address or CRC). This is how the latest www.modbus.org standard forms it - CMD byte, plus parameters for this command. Once you have this byte string created, it is submitted to one of the other 3 modules:

2) Modbus/RTU would add the slave address (header) and CRC (trailer) and send it over a serial port with various timeouts. I'd also include a flag to send/receive by Modbus/ASCII which is NOT a separate form than Modbus/RTU. My code has always just treated both RTU and ASCII internally as identical binary messages, then at the point of transmission RTU is sent in binary and ASCII is sent as 2 ASCII-HEX chars for each byte - plus a few header/trailer differences you can see in the modbus spec. Contrary to occasionally mis-information on this list, there is no real "difference" in the commands or how regiaters are addressed. Also, timeouts for ASCII should NOT fixed to 1 second - perhaps that's a good minimum setting but a LOT of WAN systems will never be able to reliable return responses in that short of a time so users must be free to set longer timeouts for Modbus/ASCII.

3) ModbusPlus would best use an existing driver. It has a 5-byte path (header) and CRC is taken care of by hardware. I believe the SA85 class of card (and most 3rd party versions) uses a fifo design in memory. You could do this fron scratch, but likely it's a lot of work. So this module should just map your API to the SA85's API.

4) Modbus/TCP is just a 7-byte header before the PDU - 3 x 16-bit big-endian ints and an 8-bit Unit Id. This is sent by TCP sockets on port 502. You should use a unique sequence number, plus allow the user to define the Unit Id. Most IP-based slaves ignore the Unit Id, but there are tens of thousands of TCP-to-RTU bridges out there that must use the Unit Id as the slave address in the Modbus/RTU output.

Best Regards - LynnL, www.digi.com

 

You can in principle, except for MODBUS Plus which is proprietary and not documented (and requires special hardware). Provided your code can handle the COM port(s) in the plain MODBUS case versus the Ethernet (sockets) in the MODBUS TCP case.

Meir Saggie