Hi all,

I am developing a software MODBUS driver for S7-300/-400 PLCs, getting rid of expensive CP341/441 and their external loadable drivers.

My personal experience on a few cases tells me that almost no real field applications require access to memory area others than registers 30001.. and 40001.. (most requests are instrumentation and DCS interfacing).

I am therefore focusing only on Modbus functions FC03, FC04, FC06 and FC16.

My question: on your real world applications do you often (or never) need to access Modbus functions other than the ones I listed above?

Thanks

Luca Gallina

 

I think it depends on the application. If you are logging production data then it's usually just registers. However, if you are dealing with a simple HMI or reporting status (is the machine in auto, are there any faults, etc.), then coils and (to a lesser extent) discrete inputs get used a lot.

If the software on the other end is flexible, then it might be able to use data in registers rather than coils. However, some software insists on having coils for some functionality. That would mean 1, 2, 5, and 15. On the other hand, having register only access is still better than having none at all.

Will you be doing a TCP version as well as RTU? I'm assuming this is RTU as you mentioned a CP341.

 

Opcodes 1, 2 and 5 are also a common offering on any generic host. IMO

 

The other relies are good - but I would avoid FC04. Some common client/hosts cannot issue FC04 requests.

The bit functions FC01 and FC02 can be complex to create in a language without shifts because literally you can read the 3rd to 6th bits, which must be shifted over 3 places to return as-if the 1st to 3rd bits of a byte.

So I'd suggest:

1) FC 3, 6, 16

2) make FC 4 look like 3 (but not sure the value of FC 04)

3) assuming all bits are READABLE via FN 03, then you don't really need FN 1 & 2. I can't think of any normal client/host which could NOT handle bits returned as packed blocks of 16 in holding registers.

4) you could still do FN 05 to write a single bit, as it is hard to do bit writes via the FN16 since you'd over-write 15 bits to write 1.

5) You could do FC15, but then you are back to needing bit-shifts. If they are easy to do fine, otherwise skip the hassle.

 

Thank you all for replies and opinions.

Reply to Michael Griffin:

1. yes, I'm doing the RTU flavour.

2. My aim is to sell the S7 blocks as communication libraries.
I haven't planned a TCP driver since I suppose it's fairly simple to send Modbus PDUs over Ethernet: opposite, most of the people seem to have difficulties in creating the S7 code for generating the CRC used in serial Modbus communication. Do you think it would be interesting (read: worth the while) to develop also a TCP version?

Regards
Luca Gallina

 

I am assuming a TCP version would be worth while based on the number of questions we see on this list concerning how to connect a Siemens PLC to another brand via Ethernet. Ethernet seems to have become popular for supervisory networks and Modbus/TCP seems to be the closest thing there is in PLCs to a common protocol that most PLCs can use one way or another.

Typical uses would be:

1) Connect a Siemens PLC to another brand via Ethernet.

2) Connect a Siemens PLC to a SCADA or HMI system when there is a mix of different PLCs in the system.

3) Connect a Siemens PLC to a PC where Profinet isn't a desirable option (e.g. due to driver compatibility or integration problems).

As for whether it is easy for people to create their own Modbus/TCP messages, it's "easy" if you have read and understand the spec in detail. It's not easy if you've never done it before. Have a look at the typical questions we get here about Modbus. I suspect that the majority of PLC users don't want to know anything about protocols and would rather just use an off the shelf driver.

If you are offering an RTU version as a cheaper alternative to Siemens's loadable drivers, then I assume you could offer a TCP version for a similar purpose. I haven't however investigated the details of how you would do this.

Siemens has a Modbus/TCP driver for their PLCs (see this: http://www.industry.siemens.com/ind...oducts/simatic_add_ons/s7_open_modbus_tcp.htm )

They have 2 versions that support functions 1, 2, 3, 4, 5, 6, 15 and 16, and another version that supports 3, 4 and 16. They do client and server. (I'm mentioning this because it relates to your original question).

I'll quote what Siemens has to say about Modbus because I find it interesting:

"MODBUS is an open protocol used around the world and supported by many different manufacturers. Along with MODBUS, MODBUS/TCP was developed for use in modern networks. This protocol now ranks as an open Internet draft standard introduced to IETF, the Internet Engineering Task Force responsible for Internet standardization. As a result, manufacturers and users everywhere are free to implement this open protocol, and many leading manufacturers have already taken advantage of this opportunity. With the increasing popularity of Ethernet communications in both industry and offices, MODBUS/TCP is enjoying an increasingly broad use in all industries. In particular heterogeneous system landscapes are typical areas of application.

Networking SIMATIC S7 to other systems via MODBUS Industrial Ethernet is a very attractive option, especially when

* SIMATIC S7 automation systems are being used to expand or modernize legacy configurations

* controllers and systems from multiple vendors are being networked (including when constructing new plants)"

 

Considering the source, I agree that the statement is most interesting. It's almost like they "get" this Open thing.

Regards
cww

 

I'll put in a good word for function code 22(decimal). When you just want to use 4x registers for everything, FC22 is helpful. Using 4x registers only, and packing the addresses you want to use together, gives the best performance.

FC22 lets you set/clear individual bits in a 4x register, e.g. a start/stop command. In the case where you have a SCADA HMI and a local OIT (or any situation where you have two or more Modbus masters) there is a potential timing problem when FC22 is not supported. FC6 and FC16 clobber the whole register every time a master writes to it. As a result, every now and then, a command the operator thinks he has sent to a controller doesn't do anything at all or not what he expected.

 

First of all I would like to thank you all for the valuable opinions.
I developed and set available for sale my S7 Modbus drivers; for a series of reasons, some of them due to the Simatic S7 specific memory model and instruction set, I ended up with the functions and options listed in the related documentation available at runmode .com web site.
Any further opinion on the final work is welcome.

Kind regards
Luca Gallina