Checksum Correct , ID Wrong

[Davarius]

I found a problem with Modbus RTU where the checksum passes but data is not for the proper device id.

calling sequence is something like:

try

myread=device.mydevice.readholdings16(id,start,100)

some text here to display "read o.k." and time stamp (debug)

catch()

some text here to show last error and time stamp (debug)

endcatch

The catch statement is used to throw some flags to ignore a channel fill sequence called by my read sequence. Trending data showed some blips where the data went totally out of a reasonable tolerance. Using the debug text i placed in the Code above and the comm monitor, I found successful reads reported by debug text where the comm monitor shows a response from a different device. This was causing the data from a different device to be accepted and therefore filled into a channel. What is the deal there? Does the CRC used in Mod-RTU take into account device id? Each time the read sequence runs the start address and number of registers remains the same; only the id changes. There is 1000 ms delay for timeout and 300ms delay between requests, also a 1 sec delay at the end of each call of the read sequence. Is there any way I can get the actual response stream or at the very least which device the response came from? That way I could verify the id.

[AzeoTech]

Are you getting any timeouts? The only time you should see this is if the device replies after the timeout period and after the next query.

[Davarius]

Yes, the device does reply after the time out period and other requests. The problem at the site that you visited in Lane County,Oregon. You took pictures, etc and there were discussions about communication, and signal strength while you were there. We have sites we manage with similar setups and there hasn't been a problem until this particular one, so all we really need is a band-aid solution.

[AzeoTech]

The CRC doesn't matter in that case, as it is correct for the response packet. The frames are getting intermingled. Once the port is unlocked (ie from the timeout) there is nothing to prevent this. Ideally, we'd want to check the ID and address, but modbus doesn't return the address, just the ID. Presumably, however, a single device is going to return things in order, so just checking the ID should help with this problem.

And so... attached is an update to the RTU driver that should make sure that the ID of the response matches the request. If not, it'll throw an error (0014: ID Mismatch). That should solve your problem. Copy the dll into the DF directory after stopping DF.

mb.zip

[ccdubs]

Hi Guru,

Do you mind summarising the issue and solution for this post? I use MODBUS RTU with a number of slaves and incorrect responses that fulfill the CRC and other error checking could be really problematic.

Thanks

[AzeoTech]

Sure. So, Davarius has a radio system where he is polling several modbus devices located remotely around a landfill. The radio doesn't really come into play in the protocol except that it means that things are slower than a direct connect. He's got some sort of loop running that polls device 1, then device 2, then device 3, etc. Well, what's happening is this:

1) he polls device 1 and gets a response within the timeout

2) he moves on to device 2. The query goes out, but no response comes back from the device before the timeout expires and he gets a timeout error

3) he moves on to device 3 and sends a query. Device 2 finally gets around to sending its response back, and it comes in before device 3 responds. DAQFactory assumed the response it got was device 3 and ends up using the wrong data (from device 2). Device 3 probably eventually responds, but the data is tossed somewhere

So, normally, lockport() takes care of this, ensuring that a frame (query and response) stay together. However, it really only protects against frame mangling on the DAQFactory side. In this case, the mangling is occurring on the device side because of the delay. A longer timeout and/or a delay between querying different devices would help, but the best is the mod that was made to the protocol driver attached above which causes DAQFactory to actually check the response to ensure it matches the ID of the query it just sent. This ensures that the response matches the query, at least on a device level.

[Davarius]

Thanks for the patch, we were toying around with some solutions just in case, but now its even better that this mod will allow checking for mismatched id's.

[Davarius]

Just to verify, the attached file gets put in the DAQ folder correct? If so is it o.k to "get rid" of the existing file (e.g. move it into another folder, not write over it).

[AzeoTech]

Correct. Its the same as the existing file with the added feature of watching the IDs.

[ccdubs]

Thanks for the summary.

My scenario is almost the same as Davarius with 30+ remote stations. As yet I haven't noticed any issues , this may be to do with the speed of our network and that I have a 0.5s delay between polls.

For safety I will install the patch as well.