Consistency of data during multi-register modbus transfers.

dexdyne

Member
Join Date
Mar 2007
Location
CIrencester
Posts
53
We've got our own s/w in a box http://www.dexdyne.com/netrix which does Modbus reads from PLCs etc..

I am aware that Modbus is seen as a set of 16-bit registers.

Some of the numbers I'll want to read across a Modbus will need >1 adjacent 16-bit registers - floating point for instance needs 2, similarly some data will need 32-bit integers

It would obviously be a disaster if I read the top 16 bits of an old value, and the bottom 16 bits of a new one. Integer counters could be wrong by 64K, floating point values by almost any amount.

Our netrix modbus driver will use a block-read on any adjacent blocks of registers.


My questions are - when you do the multi-register-read:

1. Does the PLC firmware snapshot a simultaneous sample of all the Modbus registers in the requested block to a holding area , then send them to you from there?. ( as opposed to fetching them one by one as the serial data is sent )

2. If it does do such a snapshot, then is it guaranteed NEVER to occur halfway through the running PLC application updating a 32-bit value... in other words if I ask for the Modbus read while a write to Modbus-visible-memory of a 32-bit integer or floating point value is taking place, can I ever get half the old value, and half the new?



If I can't be sure of this, then I need to do multi-register transfers using all sorts of software semaphores and insist there are software routines built into the PLC application software to be certain of consistency. That is a horrible idea.



--------------------------

I know computer makers get paranoid about this sort of stuff, I don't know if PLC people get to same depth. I suppose they must or other people would have fallen over it before now - I just want to see it in black and white somewhere J



Is there maybe a written Modbus spec that might cover the question?



[font=&quot]David[/font]
 
I found this on my hard drive if its any use....

Modicon Modbus Protocol Reference Guide
 
well that doesn't tellme much

An extract from the modicon modbus manual

"Data is scanned in the slave at the rate of 125 registers per scan for 984–X8X controllers (984–685, etc), and at the rate of 32 registers per scan for all other controllers. The response is returned when the data is completely assembled."

Nowe that might mean "provided you ask for less than 32 registers, they will be snapshotted while the application is frozen"

But it doesn't exactly set in concrete a standard for all time, that binds Siemes and everyone else, does it.
 
I personally think you are worrying over nothing, we use PLC's linked to a Modbus\Ethernet gateway (the gateway converts RS485 to ethernet) and do multiple reads (125 registers at a time) from up to 20 modbus devices, we have never had an issue

We are reading Floating point double words, integers, bit status etc etc and have never had an issue

When the PLC is asked to go off and read the device it goes and gets the value at that point in time and transfers them into PLC memory, we then display these on an HMI or SCADA
 
well I know I'm not worry over nothing, exactly.

If I was writing an interrupt routine on a coomputer with 16-bit memory locations which was handling 32-bit values as pairs of 16-bit chunks the problem would be only too real. If you kept wring values in the main program, and reading them in the interrupt routine, with no precautions taken, eventually you would see it.

If the PLC manufacturers have sorted the possible problem out, so it can never be a real problem, then hooray.

But I'd be interested in seeing what would happen if I set up a tight loop in the PLC writing 0xffff0000 then 0x0000ffff to a 32-bit integer, and reading it on the modbus. If you can swear that on no PLC will I ever read 0x00000000 or 0xffffffff then I'm delighted.
 
well why dont you write it then and find out ?

its generally accepted that if you are in doubt about a routine then you write a sample and see what the results are, then work on a soultion

i guess thats what 99% of people would be doing right now if they were you, i certainly would be

when you have some results then come back and let us know, if you have a problem then somebody may be able to offer a solution but at the moment you dont really have a problem do you ?
 
I only bother when I have very large block transfers and slow comms rates. These are some of things that I can do to keep the data consistent.
1) Write a message number to the first word -> Copy the data -> write the same message number ot the last word. System at the other end checks if the message numbers are the same. If not reject the data.
2) In the PLC perform a Block copy of data and the HMI only reads from the result. eg CLX the CPS command (synchronous copy)

Usually this is not a problem - Look at all of the HMI's trending they don't get spikes in the double integer data value. I find it only necessary when I have a large qty of recipe data (100's of words) that must be all from the same recipe.


P.S. your test should be interscan, 0x0000FFFF early in the scan final value word at the end of the scan.
 
>But it doesn't exactly set in concrete a standard for all time, that binds Siemes and everyone else, does it.

In short, no, it doesn't bind anyone to it, probably not even Siemens.

Modbus is an open standard and its implementations are all over the map. Somee much better than others. masters or slaves.

There are no guarantees when various manufacturers implement Modbus for their particular purposes and markets.

If you want guarantees, then you have to partner with the big boys and pay the costs of the joining the 'bus' or 'net' clubs, like Profibus/net or Devicenet, where there are certification programs for compliance.

There is/was a Modbus cert/testing program by some university in Michigan, and ModbusIDA has mentioned some testing program run in China, but I'm a user, not a designer, so I haven't investigated details of either.

Dan
 
Just for reference i am sat in front of a control panel now transferring 1600 modbus words (including a mixture of 16 bit integers, double words, floats) from 12 different slaves, we have not had one misread or corrupted value

make of that what you will
 
I'm with Steve Bailey on this one. If the device manufacturer's haven't taken care of it for you there isn't much you can do as an end user. If you have the data space and the programmability MichaelG tossed out a pretty good check. However, it comes down to how the device manufacturers have implemented their data shifting from the comm interface to global memory.

One thing that will help some is that most plcs don't have uncontrolled access to memory. Most of them will only provide access to internal memory from external devices at very specific times in the program scan. This helps protect you some. As MichaelG also mentioned, plcs that do provide open access tend to provide tools to maintain data consistency. But again, if the data consistency question isn't taken care of at the hardware/firmware level there isn't anything you can do about it.

Keith
 
Embedded Control 101

If I was writing an interrupt routine on a coomputer with 16-bit memory locations which was handling 32-bit values as pairs of 16-bit chunks the problem would be only too real. If you kept wring values in the main program, and reading them in the interrupt routine, with no precautions taken, eventually you would see it.
Is this in your device? Then you have a problme that is easily fixed. You should save the state of the interrupts and disable them. Then copy the data to a transmit buffer and then restore the state of the interrupts. The interrupts should be off for only a short period of time while copying. Don't screw with the buffer until the data is sent!

If the PLC manufacturers have sorted the possible problem out, so it can never be a real problem, then hooray.
The PLC manufactures have gotten past embedded control 101. What they often screw up is the character timing. How to you make sure your character timing mets the specifications? 1.5 and 3.5 character times are not easy to measure. Especiall when receiving data.
 
Thanks everyone.

I'm pleased to know that people seem to agree that there is a "potential" problem here.

The reasons I don't write a program and try it are:

1. I don't have the skills for programming PLCs.
2. My product is meant to be connected by my customers to any-old PLC, and work.

Since there IS a potential problem, I can put on the jobs list for my programmer who works on the modbus driver "take successive samples on modbus, and only pass on ones that look consistent across 2 successive scans".

Thanks all.
 

Similar Topics

Hi, I've got an issue with externally read DINT array data consistency on A-B 1769-L33ER controller. I'm periodically reading (writing) data...
Replies
8
Views
5,675
Hey all, One more Newbie Question I just posted up about the same exact line on a separate problem but I have a challenge that several of us at...
Replies
0
Views
694
Hello all, I hope someone can help me to solve this rather weird problem. When I compile the hardware config I get an error to the effect that I...
Replies
2
Views
1,426
Hi All, I have run into a problem altering some software that has been recently altered by A.N.Other. I have done my changes which are fine yet...
Replies
3
Views
2,170
Dear friends, Could somebody recommend me reliable producer of pulp consistency transmitters? Best regards, Goran Vuckovic.
Replies
3
Views
1,570
Back
Top Bottom