Modbus problems / bugs

[bartvandiepen]

Good morning DAQFactory,

I'm using DAQFactory for 2 years now and delivered several project to customers. Our DAQ application communication to a PLC device, this device communicates modbus. Up to now we communicate to a Eurotherm OPC server which was responsible for the modbus communication to this PLC. We experienced some communication problems to the Eurotherm OPC server, and therefore we've decided to communicate directly from DAQ to the PLC using modbus.

So this was a project itself, adapting the communication structure for all the channels. This goes very well up to a few modbus adresses. After hours of debugging why it was not possible to retrieve the value of these adresses I've found several bugs or unexepted behaviour of DAQFactory.

I report these items and hope that it can be solved in the next release.

Item 1:

There are a lot of modbus functions implemented in DAQFactory, but there is not a good explanation about the differences between them. It was try and error for me to found out which one works.

Item 2:

If there is one channel with modbus adress > 30000, all the modbus adress needs to count up with 1 digit (+1). When you delete the channel with modbus > 30000, then all the channels are looking to the wrong modbus address!!! When you don't know this it can take you hours, and you may have changed parameters in you're PLC which should not be changed!

Item 3:

I had a mix of the following modbus adresses, 0-10000, >10000 and >30000. I had the modbus adresses 0-10000 working prefectly, but the 10274 and 10242 did not work. I found out after hours of debugging that DAQFactory deletes the first 2 digits (probably because of the adress > 30000, there is something written in the HELP about this). This means DAQ communicates with modbus address 272 and 242 to my PLC. This could be dangerous because I was changing parameters which I didn't know! I had to download my backup to the PLC because parameters where changed, but I could not find out which ones.

It was also strange that the adress 0-10000 works without any problems, I expected that DAQ also delete the first 2 numbers for these adresses.

Item 4:

Probably DAQ autodetects how to deal with the modbus adresses (the HELP describes there are 2 different modbus documents which are common used). It detects if there is a modbus adress >30000, but this detection is only performed during start up. Not after applying a changed channel configuration. That means you can have a DAQ application running perfectly, but after a restart NOT! This behaviour cost me also a lot of time!

Item 5:

I found a bug in DAQ with my runtime (see attachment) and the use of modbus. When I changed any to an illegal value the whole modbus table is moved 1 digit!!! You can simulate this with the runtime I've attached.

Hopefully you understand the problems I had,

Kind regards,

Bart van Diepen

Pro Control B.V.

run1_v8_0_failure.ctl

[AzeoTech]

Not a bug. This is all explained in the help file in the grey box:

Detail: Unfortunately some manufacturers 0 index their addresses and others use 40,001

type notation. Internally, the Modbus packet itself uses 0 indexing. The Modbus

protocol driver will assume you are using 0 indexed addresses until you try and read

from an address greater than 30,000, but less than 50,000. Once you do this, it will

assume you are using 40,001 type notation and subtract the appropriate value to

send the correct request. This will apply to all the devices using the protocol.

In general you don't have to worry about this, unless you are only setting coils and

output registers and still want to use the 1 indexed, 40,001 type notation. In this

case you will either need to read a single holding or input register with an address

greater then 30,000 or manually adjust your tag numbers to 0 indexed.

Alas, some devices use 0 index notation, but number their registers up into the

30,000 and 40,000. To force the driver into 0 index mode, read an address greater

than 50,000. Then the driver will remain in 0 indexed mode even if you read a

30,000 or 40,000 address.

You fall into the last category since you are 0 indexed but have addresses up into the 30,000 range. As instructed, you should therefore read from an address greater than 50,000 in an Auto-start sequence (just once) to lock DAQFactory into 0 indexed mode. From then on, it will remain 0 indexed.

DAQFactory tries to figure out which addressing mode you are using based on your channels, but it can only really do this as the system is starting up. Because modbus can be read from script, and addresses can be calculated in script and variables, there is no way for DF to simply scan your document trying to figure it out. So, it assumes you are 0 indexed until you try and read a 30,000 range, at which point it switches you to what I call 40,000 notation, which is 1 indexed (and the 3 or 4 is stripped) and will stay in that mode until you restart. As it explains in part of the manual I quoted, if you need it remain in 0 indexed mode, you have to read from a 50,000+ register (even if it fails).

As for all the different Modbus I/O types. These are also explained in the manual:

I/O Types:

All of the types will read or output to a single memory location. The number in

parenthesis is the Modbus command used. Many of the commands are identical

and the difference is how the data is treated. Here is a description of the codes

used:

U16 : unsigned 16 bit word

S16 : signed 16 bit word

U32 : unsigned 32 bit double-word (long unsigned integer)

S32 : signed 32 bit double-word (long integer)

U32 R Words : unsigned 32 bit double-word with words reversed

S32 R Words : signed 32 bit double-word with words reversed

Float : 32 bit floating point value

Float R Bytes : 32 bit floating point value with bytes reversed

Float R Words : 32 bit floating point value with words reversed

Skip 2 : skip 2 bytes before reading the value

There are really only 4 Modbus functions, but different manufacturers will deviate from the modbus standard to achieve things the original modbus protocol doesn't specify.