We have some dedicated product gateways in our range. They mainly sserve as interface between KNX bus and the device (eg a ventilation unit).

We've been asked to investigate to add MODBUS as additional communication protocol.

I've done some research and have a basic technical understanding about MODBUS (coils, registers, RTU, TCP etc). But I don't have any idea on the application side.

So, I'd like to know what functionality a normal user/engineer would expect from such gateway in order to use it in a real MODBUS environment where he wants to integrate this device (eg ventilation unit).

1) would he expect the gateway/device to act as master or slave?

2) how would he like to configure the commands and status functions the gateway wants to expose? Is there a certain 'consensus' how this is typically done?

2.a) select coil/register or datatype (1 bit 16 bit N*16 bit)?

2.b) use specific types for status and command? E.g. coil for command and discrete output for status? Or the other way around? (same for input and holding register)

3) does anybody know of an existing documented MODBUS device gateway we could use as a best practice example?

Any indication is welcome

Christof
email: [email protected]

 

1) would he expect the gateway/device to act as master or slave?

A gateway has 2 sides. The Modbus side would be a Modbus RTU slave or a Modbus/TCP server to outside world. The other side communicates to the ventilation unit.

A Modbus master/client reads or writes data to the slave/server side. Internally the gateway does whatever is needed to read status and/or performance data from or write data to ventilation unit using the 'other' gateway side.

2) Data type depends on what the data is. I haven't a clue what sort of data a ventilation unit uses or has in it.

Look at Banner Engineering's Wireless Gateway. It holds data from node radios and makes it available as Modbus RTU slave. The register table on page 7 shows the data formats used.

http://info.bannerengineering.com/cs/groups/public/documents/literature/155861.pdf

http://tinyurl.com/khrcfed

 

At a minimum, I would suggest this:

1) all data available as 4x/holding registers, read by func 3. Any bits get packed into 16-bit regs (be aware of how byte-swapping is a bit unexpected for this). If you allow writing, then add BOTH func 6 and 16. Note that some masters cannot use func 6 - they will instead use func 16 with count of 1.

2) optionally, you can offer bits up as 0x/coils, read by function 1.

3) Modbus doesn't have an effective (or I should say - commonly supported) masked bit write, so if you want bits written, add support for functions 5 and 15.

4) I'd avoid putting anything unique in 1x/3x inputs, as some common masters can't access those.

5) In summary, I'd say there is NOTHING WORSE than some piddly little device which puts:
- 7 bits in 0x/coils
- 3 bits in 1x/input status
- 15 words in 4x/holding regs
- 6 words in 3x/input regs

As now every master has to issue 4 distinct requests to read almost no data. I am not saying you cannot support memory other than 4x/holding regs, only that the BEST thing you can do for your customers is make sure ALL data can be read from a SINGLE func 3 call. In the example, above, Modbus/RTu can easily read all data in 1 read of 23 words.

Also, the read/write-vs-read-only is fuzzy these days. Of on a PLC one can write all 4x/holding registers - even if it breaks the running program, but most stand-alone devices have some 4x/regs you can write, and many you cannot.

- Lynn

 

thanks for your answers.

This is what we now intend to implement:

- gateway would be a slave

- support for tpc & rtu

- support for coils and holding registers, so no 'read-only' data

- support for single & multi, read & write (don't ask me which function numbers)

- coils will only be useable for data we internally represent as 1 bit data. All other data goes in registers. So no multi-bit/coil info. And in any case, users are able to add a register based interface on top of the coil, since they can define the datatype (bit-> coil, all the rest -> register).

- registers will mainly have 1-register uint16 data. But we'll also support uint32, string14 and 'datatime'

- for datetime, I found a forum post and it seems a 7 or 8 eight register approach with individual day, month, hour, minute, .. is the preferred solution (over 32bit posix timestamp)

- string14 will be 7registers,each representing 2 bytes/chars ... or it this 'absolutely not done' -> 14 registers?

This seems to be more or less in line with what you write here.

I have 2 more questions:

- for 'multi-register' data, are there rules with regards to how to support single/multi write calls? Can we 'forbid' (ie. not support) single register write on a register which is part of a multi-register range?
What is best practice?

- configuration: the types and number of registers/coils, their content, whether they are 'writeable' (ie. we see them as commands when something is written) depends on a lot of application settings. So we would generate a 'modbus slave profile' file that the engineer can download from the configuration GUI. I've seen that many masters work with these kind of profile files to model the slaves. But there doesn't seem to be a standard (similary as there is no standard for 'datatypes': it's coil or register).I've seen several csv style files. But without column headers.

Question: is this 'profile' file approach a good way? Is there a standard or best practice?

Christof

 

The closest think I have seen to a 'standard' doc format is the renewable energy work done by http://sunspec.org/. They have a DHCP-like browsable block design, where a Modbus device is a simple list of perhaps 4 blocks, each with a register-count and 'product id', so in theory a master can walk through the slave, and at least know it is a collection of X blocks - obviously, they might NOT understand what block type 0xFF23 from vendor 'corp-xyz' is.

SunSpec also has an XML-based machine readable spec, so if you could contact 'corp-xyz', you could obtain such a file & auto-teach your master the data types, sizes, units of measure and so on. I doubt you'll find many true auto-smart SunSpec masters out there - but it is available asa free standard if you wish to try.

As for PDF docs, I usually do it with 2 columns, so one will show the register number 4x00001 and the second 0, This helps people who need first reg to be 1, and those who need it to 0. It seems silly, but it saves a LOT of off-by-one mistakes.

For bad multi-register writes, I'd say it is logical to force a fail - although true Modbus doesn't define that as an error since in true Modbus, data is only 16-bits. I have also seen people who reject misaligned reads.

It is also best to try and group data types (not logical functions), so put your packed bits in one range, your words in another, and the double-words in a third. Grouping the read-only and read-write also helps.

One final suggestion - have any 32-bit data aligned on even boundary.

So this is good:
1) 16-bit
2) 16-bit
3) 32-bit
4) 32-bit

While this is bad:
1) 16-bit
2) 32-bit
3) 16-bit
4) 32-bit

The problem is that some (not all) OPC servers demand to pull a block of data as 'an array'. So in the first case, one could treat this as an array of 3 x 32-bits and IGNORE the first 32-bit which is mixed garbage. However, in the second design, there is no way to read BOTH 32-bit in a single read ... two reads would be required.

- Lynn

 

I've had a look at the sun spec. But as it's not fully standardised and well established yet, we won't put in effort at this time (to release the first devices). But it's in our wish list.

I did consider all your other comments for which I'm very grateful:

- user can specify if they want to use registers only or also coils

- data types and R/W are grouped, not functions (unless configured differently by engineer)

This is an example profile html file, which also includes a link to a csv file which the engineer can download for easy manipulation (even turn it in XML in Excel if he wishes):

http://www.knxlogic.eu/wp-content/uploads/2015/02/modbus.html

When a change is made to the config impacting the profile, the profile gets updated automatically.

I don't expect you to fully understand the 'name' since it's specific for this application on a Siemens Intrusion and access control panel (and explained in the manual), but to give an idea CMD are commands, STS are status, EVT are events, CFB = command feedback. The 2 last columns are not very important, they serve as 'link' to other information.

We've chosen to start a new type at a multitude of 32 addresses. As such, when a user makes a small change (add/delete one) there is most likely not a big impact on the entire profile. We also have an option the engineer can set to structure the profile differently and is such a way that when making config changes, the existing objects never change address. But in that case, we don't group R/W or data types.
(FYI: in this device example there can be easily hundreds of objects, all depending on the actual needs, and depending on the specific building you're protecting)

We've tried to make this solution generic because we'll create a series of modbus slave gateways, both dedicated ones and generic KNX-modbus ones.

Please share your thoughts.
Thanks for helping!

Christof