Mudbus Tcp, Channels Creation

[dle]

When trying to communicate with the Modbus device, if I create a channel and set it to channel #2, I do not receive data correctly on this channel 2. However, if I create channel# 0, channel# 1 and channel# 2, then I received data correctly on channel# 2.

 

Is this a normal procedure of creating Modbus channels?  

[AzeoTech]

That depends.  What do you mean by "receive data correctly"?  Do you just get timeout errors or some sort of Modbus error if you read #2 alone?  If so, many devices require you to read blocks of addresses and not just one.  That's why it starts to work when you read 0, 1 and 2.  This is a device specific thing and not part of the Modbus spec or DAQFactory.

[dle]

"receive data correctly" I meant DF receiving the expected data.

I didn't get any error or time out message. If I try to read channel 2 only, the data I received is from another channel.

e.g. If I create channel 1, 2 and 3, what I see at channel 3 is what I expect to see at channel 2.

If I create channel 0, 1, 2 and 3, then channel 2 will receives what the expecting data.   

[AzeoTech]

I have found that many device designers really just don't understand Modbus addressing, and so their documentation tends to be very misleading.  If your device docs say that to read some value you need to read holding register #2, then that should imply that they are using 0 indexed notation and that the actual protocol frame should ask for tag #2.  However, if your device docs say you need to read holding register #40002, then that should imply that they are using 1 indexed 40,000 notation, and that the actual protocol frame should ask for tag #1 (strip the 4 and subtract 1).  The problem is that many device manufacturers don't know this and do random stuff.  For example, they might specify register #2,but actually think that it should be -1, so what goes out the frame should be 1.  This is, of course, wrong, but it doesn't stop them.

 

DAQFactory tries to determine which mode your device documentation is using based on the tag #'s you specify.  By default, it assumes that your device uses 0 index notation, so specifying channel #2 sends a request for tag #2 in the protocol frame.  Once, however, you ask for a tag # in the 30,001 to 49,999 range, then it assumes that your device is actually using the 40,000 notation, so it will strip the ten thousands place and subtract 1, so channel #2 actually becomes channel #1.  This applies for all devices.  Since some devices actually are 0 indexed but include registers up in the 30,000 and 40,000 range, you can read a register in the 50,000 range once to lock DAQFactory into 0 indexed mode.

 

If your registers actually are 1, 2, and 3 (and not something else that you just simplified to 1, 2 and 3), then I'd just say that your device is messed up and has some sort of bug.  This would not be the first time.  I saw a device once that had 32 bit floating values.  Since a Modbus register is defined as 16 bits, to read a 32 bit value you have to read two consecutive registers.  So, the first register might be tag #0 (+ #1), and the second would be tag #2 (+ #3).  (Trying to read Tag #1 as the starting point would ideally generate an error).  Well, it worked correctly when you read the holding registers.  First register = #0, second = #2, etc.  But when you went to write to the holding registers, the tag #'s incremented by 1, so, reading and writing the first register would be tag #0, but reading the second register would be tag #2, while writing to that same register would be tag #1.

 

So, my guess is that your device has some bugs in their Modbus implementation...