Modbus CRC error checking

J

Thread Starter

Jeremy Stevens

I currently have a product out in the field on the customer site that is sending out particle count data via serial modbus. Anytime the customers' DCS polls our module and gets the same data two times in a row, the master device is throwing an error. When we recreate the set up with a LabVIEW master device here in the office, we can see that because the current data is the same as the previous data it is being interpreted as old data. I can only assume this is because the CRC portion of the data packet is being generated according to the data that is being sent. A cRIO module is the slave device and I would like to keep the number of registers and shared variables to a minimum. We currently have a work around using an extra register we don't need and just incrementing a value with every iteration. Does anyone know of some way to indicate to the master Modbus device that the data in the registers is still current even though it is the same as the data that was there the last time it was polled?
 
I would suggest that you talk to the DCS vendor about this problem. It might be a bug rather than a non-standard "feature" at their end. It may also simply be a non-standard option which can be turned off in the DCS configuration. If the behaviour is intentional, they would have the best idea as to how to handle it.

I would be very surprised if you were the first person to have this problem. I am trying very hard to imagine how this would work with most field devices, so there is probably a very simple solution.
 
J
The master might be doing a 'test for live sensor'.

Many times holding registers will "hold last", even when the input register is not updated with a live value. Not unusual in modbus slaves that function as remote I/O, like a wireless gateway.
The field sensor's battery (excuse me, the 'power module') goes dead and gateway's holding register still has the last valid point.

The problem with such is that one can think everything's fine, because the PV is straght lining, when it's just continued repetition of an old value.

A typical test to avoid this, that works well with floating point analogs is to compare the current value with last value, subtract the two and if identical (difference = zero), then flag a possible field sensor failure. The 4th, 5th and 6th digits to the right of the decimal point jitter from noise, even for static conditions.

Could it be that someone has implemented this kind of 'test for live sensor' for this particular device whose outputs apparently are identical from reading to reading? Or an integer value that doesn't show noise?
 
Thread starter Similar threads Forum Replies Date
P Modbus 5
F Modbus 6
N Modbus 4
E Modbus 0
M Modbus 3
Top