Consistency of data during multi-register modbus transfers.
- Thread starter dexdyne
- Start date
Peter Nachtwey
Member
That is NOT the way to fix this. The PLCs do it right. It is your device that doesn't. You should have your embedded programmer continue this thread or go to the comp.arch.embedded newsgroup.dexdyne said:
rsdoran
Lifetime Supporting Member
Originally asked and never answered, does the plc etc take a snapshot of the data, simple answer is yes. In other words it does not matter what or how much data you collect, you will get what is available AT THE TIME YOU REQUEST IT.
BTW I too think you are over complicating the issue.
BTW I too think you are over complicating the issue.
Last edited:
Peter, rsdoran, and anyone else.
Thanks for all the contributions. I think I now understand what it is all about.
First off, if the communication was, say, a modbus slave running in a computer, the problem would be real. That is because the many tasks in a normal computer run all the time, asynchronously. If a modbus message handler ran as an interrrupt routine in a PC, then it could well try to pick up a multi-byte value in a half-updated state.
I'm a computer programmer, not a PLC one, and I have learned to worry about such stuff in my bones.
Now what I sort of knew, but didn't understand, is that PLCs work on a step-cycle. They take all the inputs, compute all the outputs, pause for breath and go round and do it again.
What is becoming clear is that Modbus transations are handled by the executive software in the PLC DURING the pause for breath. So if any values are going to change, they won't be doing it while the PLC is constructing a modbus reply.
So the simple answer is - there is no problem, and I'm over - complicating things --- as people around here keep trying to tell me. I thought they didn't understand, but what they were trying to say was "There's no problem BECAUSE IT'S A PLC.
Which all sounds great, and I'm happy, except.
The S7 manual I read said "on model x you can sample up to 32 modbus registers for a modbus reply, and the modbus reply will be sent when the block is complete"
That's saying that even though the PLC may support a modbus block fetch of , say 150 registers, it will only build up the output message with 32 registers in any pause for breath between steps. SO 150 registers would need 5 step times to build it up.
So, in theory, the problem I'm worrying about could occur, if I try to fetch a long block of registers ( >32 in this case ) and the multi-register value I'm fetching spans the gap between registers 32 and 33, 64 and 65 etc. In that case you'd have no problem at all in fetching half of a value from one step, and half of one from the next.
So my answer is to set up a "maximum fetch size" for each PLC on the modbus, and never to fetch a value which doesn't lie wholly within such a block size.
Anyone want to disagree?
David
Thanks for all the contributions. I think I now understand what it is all about.
First off, if the communication was, say, a modbus slave running in a computer, the problem would be real. That is because the many tasks in a normal computer run all the time, asynchronously. If a modbus message handler ran as an interrrupt routine in a PC, then it could well try to pick up a multi-byte value in a half-updated state.
I'm a computer programmer, not a PLC one, and I have learned to worry about such stuff in my bones.
Now what I sort of knew, but didn't understand, is that PLCs work on a step-cycle. They take all the inputs, compute all the outputs, pause for breath and go round and do it again.
What is becoming clear is that Modbus transations are handled by the executive software in the PLC DURING the pause for breath. So if any values are going to change, they won't be doing it while the PLC is constructing a modbus reply.
So the simple answer is - there is no problem, and I'm over - complicating things --- as people around here keep trying to tell me. I thought they didn't understand, but what they were trying to say was "There's no problem BECAUSE IT'S A PLC.
Which all sounds great, and I'm happy, except.
The S7 manual I read said "on model x you can sample up to 32 modbus registers for a modbus reply, and the modbus reply will be sent when the block is complete"
That's saying that even though the PLC may support a modbus block fetch of , say 150 registers, it will only build up the output message with 32 registers in any pause for breath between steps. SO 150 registers would need 5 step times to build it up.
So, in theory, the problem I'm worrying about could occur, if I try to fetch a long block of registers ( >32 in this case ) and the multi-register value I'm fetching spans the gap between registers 32 and 33, 64 and 65 etc. In that case you'd have no problem at all in fetching half of a value from one step, and half of one from the next.
So my answer is to set up a "maximum fetch size" for each PLC on the modbus, and never to fetch a value which doesn't lie wholly within such a block size.
Anyone want to disagree?
David
Steve Bailey
Lifetime Supporting Member + Moderator
I hope you'll forgive me for pointing out that you seem to be investing a lot of time and effort reinventing the wheel. Modbus has been around for years and there drivers available from many sources that you could incorporate into your product. At this late date, what are you bringing to the marketplace that hasn't already been done?
Peter Nachtwey
Member
Not if the interrupts are turned off as the tasks copy the data to or from the buffer.dexdyne said:
There is a problem that you identified below.
You shouldn't be happy yet.
The data consistency problem is not a problem IF the PLC copies the whole 150 words at once into the buffer. Actually, I think the most that can be copied is 125 words because there is some over head and the byte counter only counts 256 bytes.
You are getting close. The problem is character timing. First, what you call a step is what PLC people call a scan. If the scan time is long the S7 will have gaps between the groups of 32 words that are sent out. A proper Modbus implementation will see there is a gap between the characters and consider the next group of 32 words to be a new packet. Check the specifications about character timing. Timing 1.5 and 3.5 characters is not easy.
Therefor you gut feel IS CORRECT. You need to limit packet size to the amount of data that can be sent per scan by the PLC. If a packet requires two scans there may be a gap between the two groups of data and each will be interpreted as its own packet by the receiving device.
We have had this problem with an old Moeller PLC. The PLC programmer had to make the packets smaller so they can be sent in one scan because the PLC scan was about 100 milliseconds.
mjduffy
Member
some plcs allocate comms functions to a separate time when scanning of the plc program is not happening, others allocate comms in an asynchronous way which i guess is your issue.
I don't think you have a problem though.
The modbus protocol includes a checksum (CRC or BCC) so all data values muse be consistent for the checksum to be valid. so there should be a snapshot before the data is actually transmitted.
hope this helps.
I don't think you have a problem though.
The modbus protocol includes a checksum (CRC or BCC) so all data values muse be consistent for the checksum to be valid. so there should be a snapshot before the data is actually transmitted.
hope this helps.
Peter Nachtwey
Member
The dead horse rises
Steve, this has been done before but the code may not work in dexdyne's device without a lot of modification. There is also the NIH factor. I know we suffer from it because we feel we can always do it better. For instance, we cannot turn off the interrupts because the motion control interrupts must happen ASAP. Dexdyne may have similar concerns. Finally, Dexdyne is making a product like us and we don't want to pay royalties on something that is easily developed.
The data consistency problem should not be a problem. This is trivial. It is the character timing that is a real b!tch.
That was implied withrsdoran said:
peter said:
Steve, this has been done before but the code may not work in dexdyne's device without a lot of modification. There is also the NIH factor. I know we suffer from it because we feel we can always do it better. For instance, we cannot turn off the interrupts because the motion control interrupts must happen ASAP. Dexdyne may have similar concerns. Finally, Dexdyne is making a product like us and we don't want to pay royalties on something that is easily developed.
The data consistency problem should not be a problem. This is trivial. It is the character timing that is a real b!tch.
Steve, Peter, et al.
I think I've got a grip on this, but now other people are worrying me
I, personally, don't have control of the bottom level driver. So I'm not going to get drawn into the character timing stuff. Though I will talk to my guy who IS in control of that stuff, and check he's confident.
I started out with a very simple question - "If we fail to pay sufficient attention to the way we use multi-register reads on the modbus, is there any possibility of picking up from the PLC two inconsistent parts of a multi-register modbus value, such as a floating point one."
Now I've become clearer that MOST PLCs operate on a SCAN-SCAN-SCAN algorithm, and probably process modbus interactions between scans.
They build up a "response packet", and only start sending it when it is complete in an outgoing buffer.
I ASSUME that once the transmission does start, the characters will be transmitted smoothly, even during the other PLC operation - because that is a very basic requirement of all modbus comms.
So you have much less reason to worry about interrupting the storing of a multi-register number, by the PLC applicaton, to a modbus visible area, AS YOU WOULD HAVE TO WORRY/HANDLE ON A uP WHICH USED PRE-EMPTIVE MULTI-TASKING. ( the environment I'm more used to )
Now, that's the simple answer, but I've also realised that if you ask a PLC for 150 contiguous registers in a single modbus transaction it may decide that it doesn't have time between-steps to build a packet of that length. So it may transfer 32 between two steps, the next 32 between the following steps, and so on.
Now if no attention is being paid, and a multi-register value occupied registers 32 and 33 of the area, and an update took place between the first build step, and the second - a half-and-half value COULD be returned.
The answer to that is for the modbus master to always ask for any multi-register value WITHIN A SINGLE READ.
It's probably sensible to never ask for more than 32 registers at once( or whatever value fits all PLCS or each actual PLC ), even if they are not multi-register.
If we ever start to use "structures" they should be treated in the same way ( fetched in a sinbgle modbus trannsaction), but at that point we may need a flag register to disable fetching of the structure dring update by the PLC anyway. And in a perfect world we'd want a system which could handle structures bigger than the 32 byte restriction.
Anyone disagree with my analysis?
David
I think I've got a grip on this, but now other people are worrying me
I, personally, don't have control of the bottom level driver. So I'm not going to get drawn into the character timing stuff. Though I will talk to my guy who IS in control of that stuff, and check he's confident.
I started out with a very simple question - "If we fail to pay sufficient attention to the way we use multi-register reads on the modbus, is there any possibility of picking up from the PLC two inconsistent parts of a multi-register modbus value, such as a floating point one."
Now I've become clearer that MOST PLCs operate on a SCAN-SCAN-SCAN algorithm, and probably process modbus interactions between scans.
They build up a "response packet", and only start sending it when it is complete in an outgoing buffer.
I ASSUME that once the transmission does start, the characters will be transmitted smoothly, even during the other PLC operation - because that is a very basic requirement of all modbus comms.
So you have much less reason to worry about interrupting the storing of a multi-register number, by the PLC applicaton, to a modbus visible area, AS YOU WOULD HAVE TO WORRY/HANDLE ON A uP WHICH USED PRE-EMPTIVE MULTI-TASKING. ( the environment I'm more used to )
Now, that's the simple answer, but I've also realised that if you ask a PLC for 150 contiguous registers in a single modbus transaction it may decide that it doesn't have time between-steps to build a packet of that length. So it may transfer 32 between two steps, the next 32 between the following steps, and so on.
Now if no attention is being paid, and a multi-register value occupied registers 32 and 33 of the area, and an update took place between the first build step, and the second - a half-and-half value COULD be returned.
The answer to that is for the modbus master to always ask for any multi-register value WITHIN A SINGLE READ.
It's probably sensible to never ask for more than 32 registers at once( or whatever value fits all PLCS or each actual PLC ), even if they are not multi-register.
If we ever start to use "structures" they should be treated in the same way ( fetched in a sinbgle modbus trannsaction), but at that point we may need a flag register to disable fetching of the structure dring update by the PLC anyway. And in a perfect world we'd want a system which could handle structures bigger than the 32 byte restriction.
Anyone disagree with my analysis?
David
Why are we writing/maintaining our own modbus driver?
We are running on a linux system, talking to multiple PLCs multi-drop over a 485 link.
Most transactions will be reads, though writes are possible, and need to be handled. But they can be tacked-on.
We need to be able to specify any pattern of named registers, containing all the various number types, and including packed - bits - in - holding - registers.
These definitions, which will not be in device or register address order, need to be sorted and concatenated INTO device and address order.
From that sorted table an efficient series of multi-register modbus transactions needs to be created, across a range of devices, and decodes to appropriate C-language numeric types, repeated ever 500ms or so.
The transcation ( we now discover ) need to respect the 32-byte or whatever, restrictions on modbus transactions
The results need to be filed away, as the new current values of the items in the original random-order list.
Now if we can go and grab a license-free lump of code to do that, we'd be delighted to hear of it. We failed in our original search some time back, but maybe things have moved on.
David
We are running on a linux system, talking to multiple PLCs multi-drop over a 485 link.
Most transactions will be reads, though writes are possible, and need to be handled. But they can be tacked-on.
We need to be able to specify any pattern of named registers, containing all the various number types, and including packed - bits - in - holding - registers.
These definitions, which will not be in device or register address order, need to be sorted and concatenated INTO device and address order.
From that sorted table an efficient series of multi-register modbus transactions needs to be created, across a range of devices, and decodes to appropriate C-language numeric types, repeated ever 500ms or so.
The transcation ( we now discover ) need to respect the 32-byte or whatever, restrictions on modbus transactions
The results need to be filed away, as the new current values of the items in the original random-order list.
Now if we can go and grab a license-free lump of code to do that, we'd be delighted to hear of it. We failed in our original search some time back, but maybe things have moved on.
David
Peter Nachtwey
Member
I wouldn't assume that. I have never had problems with inconsistent data within one packet. I have had problems when the PLC could not send all the data in one scan so the gap between scans caused our controller to think the first part of the packet was complete and the second part of the packet was the start of a new packet. Obviously the checksums didn't work out so communications failed. This problem was fixed by keeping the packet size limited to what could be sent in one scan.dexdyne said:
Modbus messages can't be 150 words long. Have you read the spefications? You should be saying things like this if you have. The request will fail. There is nothing in the protocol that automatically divides a 150 word request into smaller requests. You can do this in your master but the slave device will just see a series of smaller request. There will be no data consistency between packets unless the slave device is smart enough to copy all the data into a buffer based on some command. That isn't likely.
If you requires 100 words you should receive a packet of 100 words of consistent data. What I am saying is that the PLC may not be able to send more than 20 words in a scan so the packet times out after the 20 words. The checksum will fail and the driver should return an error.
YES, but you may need to limit the length to what the PLC can send in a scan. This means your driver needs to have a message length limit that can be adjusted for each slave device.
This question doesn't make sense.
Modbus does not have a 32 byte restriction. Do you have the spefications?
I have not seen you mention character times.
If you ask for a packet of 120 words you should expect the data to be consistent within that packet.
A proper Modbus driver is going to have two internal buffers of about 256 bytes, one for sending and one for receiving. The data the goes into and out of the buffer should be consistent as long as one doesn't modify the buffer while sending or receiving. The problem that arises is that the data in these buffers must be sent and received one character after the other with gaps greater than 3.5 character times. This is where I have seen problems with some PLCs.
You should have a communication log where you log what is sent and received and the times and the errors. Some devices do not meet the specifications and this log will point the finger at the guilty party or at least prove the problem is not yours. We have excellent diagnostics with our product and a good log will save you many hours in the end.
Your linux device is the master and you can limit the packet sizes where required.
Our product is a slave device. It has a scatter/gather feature so data from many places within our slave device can be sent in one Modbus packet. This way our slave can send consistent data to the master. If the slave devices do not have this feature then they must have a way of copying data from many different parts into one buffer that can be sent in one message if you expect all the data to be consistent.
You cannot expect consistent data with multiple reads or writes.
> I wouldn't assume that. I have never had problems with
> inconsistent data within one packet. I have had problems when
> the PLC could not send all the data in one scan so the gap
> between scans caused our controller to think the first part
> of the packet was complete and the second part of the packet
> was the start of a new packet. Obviously the checksums didn't
> work out so communications failed. This problem was fixed by
> keeping the packet size limited to what could be sent in one
> scan.
eeek.
Isn't that just a basic failure to do modbus properly? the slave should pre-build a buffer and transmit it continuously or it isn't working.
> Modbus messages can't be 150 words long.
sorry, for 150 read 120. I had misremembered the limit.
> If you requires 100 words you should receive a packet of 100
> words of consistent data. What I am saying is that the PLC
> may not be able to send more than 20 words in a scan so the
> packet times out after the 20 words. The checksum will fail
> and the driver should return an error.
I assume the documentation for a device like that should say somewhere "never ask me for more than n registers at once or I will fail"
> This means your driver needs to have a message length limit
> that can be adjusted for each slave device.
yup, that's on the to-do list. Have to have a limit of 125 anyway of course.
> Modbus does not have a 32 byte restriction. Do you have the
> specifications?
No, but a particular slave whose spec I was reading said it could only build it's reply up at the rate of 32 registers per scan. It said it wouldn't start to stream the reply out till it was complete though, so it would be a valid modbus packet with no gaps.
> I have not seen you mention character times.
I'm hoping I will never have to care, at the level at which I'm working.
> A proper Modbus driver is going to have two internal buffers
> of about 256 bytes, one for sending and one for receiving.
> The data the goes into and out of the buffer should be
> consistent as long as one doesn't modify the buffer while
> sending or receiving.
well if the sending buffer is built up in, say, 32 register chunks each scan, then the final buffer contents would be inconsistent in time by 4 to 5 scans. Shouldn't matter much usually.
But if any floating-point value spanned the gap across 2 32-register chunks, I don't see how one can say it isn't possible to get half of an old value and half a new one.
And the flowmeter I'm looking at actually returns 18-byte strings packed into 9 successive registers. I don't want to be able to pick up an inconsistent result from them either, if an error message happens just at the wrong moment.
> The problem that arises is that the data in these buffers
> must be sent and received one character after the other with
> gaps greater than 3.5 character times. This is where I have
> seen problems with some PLCs.
pray God I never meet one of those
> or at least prove the problem is not yours. We have excellent
> diagnostics with our product and a good log will save you
> many hours in the end.
Yup, if we run into problems I can chuck technology at it.
What I'm trying to do is to set up a set of rules the modbus master driver must obey when building up it's list of data requests.
Like, say
1. Keep packet sizes below 32 bytes for this particular PLC,
even if all values in it are single-register .
2. Ensure a 2-register fpt value is always fetched within
a single packet. Ditto 9-byte strings.
> Our product is a slave device. It has a scatter/gather
> feature so data from many places within our slave device can
> be sent in one Modbus packet.
The flowmeter I'm looking at has a feature like that.
In the modbus master we have to do some sort-gather-post stuff, if we are not to fetch each register in a separate modbus read.
We need to ensure a single fetch stays under 125 registers anyway - to meet the modbus spec. But it seems we should have a per-device lower limit, and a "don't break objects across packets" rule too.
> This way our slave can send consistent data to the master.
> If the slave devices do not have this feature then they must
> have a way of copying data from many different parts into one
> buffer that can be sent in one message if you expect all the
> data to be consistent.
> You cannot expect consistent data with multiple reads or
> writes
I have a lower target than that at present. I just want make absolutely sure that 4-byte ints and floats, and 9-register strings are not read half way through changing.
David
> inconsistent data within one packet. I have had problems when
> the PLC could not send all the data in one scan so the gap
> between scans caused our controller to think the first part
> of the packet was complete and the second part of the packet
> was the start of a new packet. Obviously the checksums didn't
> work out so communications failed. This problem was fixed by
> keeping the packet size limited to what could be sent in one
> scan.
eeek.
Isn't that just a basic failure to do modbus properly? the slave should pre-build a buffer and transmit it continuously or it isn't working.
> Modbus messages can't be 150 words long.
sorry, for 150 read 120. I had misremembered the limit.
> If you requires 100 words you should receive a packet of 100
> words of consistent data. What I am saying is that the PLC
> may not be able to send more than 20 words in a scan so the
> packet times out after the 20 words. The checksum will fail
> and the driver should return an error.
I assume the documentation for a device like that should say somewhere "never ask me for more than n registers at once or I will fail"
> This means your driver needs to have a message length limit
> that can be adjusted for each slave device.
yup, that's on the to-do list. Have to have a limit of 125 anyway of course.
> Modbus does not have a 32 byte restriction. Do you have the
> specifications?
No, but a particular slave whose spec I was reading said it could only build it's reply up at the rate of 32 registers per scan. It said it wouldn't start to stream the reply out till it was complete though, so it would be a valid modbus packet with no gaps.
> I have not seen you mention character times.
I'm hoping I will never have to care, at the level at which I'm working.
> A proper Modbus driver is going to have two internal buffers
> of about 256 bytes, one for sending and one for receiving.
> The data the goes into and out of the buffer should be
> consistent as long as one doesn't modify the buffer while
> sending or receiving.
well if the sending buffer is built up in, say, 32 register chunks each scan, then the final buffer contents would be inconsistent in time by 4 to 5 scans. Shouldn't matter much usually.
But if any floating-point value spanned the gap across 2 32-register chunks, I don't see how one can say it isn't possible to get half of an old value and half a new one.
And the flowmeter I'm looking at actually returns 18-byte strings packed into 9 successive registers. I don't want to be able to pick up an inconsistent result from them either, if an error message happens just at the wrong moment.
> The problem that arises is that the data in these buffers
> must be sent and received one character after the other with
> gaps greater than 3.5 character times. This is where I have
> seen problems with some PLCs.
pray God I never meet one of those
> or at least prove the problem is not yours. We have excellent
> diagnostics with our product and a good log will save you
> many hours in the end.
Yup, if we run into problems I can chuck technology at it.
What I'm trying to do is to set up a set of rules the modbus master driver must obey when building up it's list of data requests.
Like, say
1. Keep packet sizes below 32 bytes for this particular PLC,
even if all values in it are single-register .
2. Ensure a 2-register fpt value is always fetched within
a single packet. Ditto 9-byte strings.
> Our product is a slave device. It has a scatter/gather
> feature so data from many places within our slave device can
> be sent in one Modbus packet.
The flowmeter I'm looking at has a feature like that.
In the modbus master we have to do some sort-gather-post stuff, if we are not to fetch each register in a separate modbus read.
We need to ensure a single fetch stays under 125 registers anyway - to meet the modbus spec. But it seems we should have a per-device lower limit, and a "don't break objects across packets" rule too.
> This way our slave can send consistent data to the master.
> If the slave devices do not have this feature then they must
> have a way of copying data from many different parts into one
> buffer that can be sent in one message if you expect all the
> data to be consistent.
> You cannot expect consistent data with multiple reads or
> writes
I have a lower target than that at present. I just want make absolutely sure that 4-byte ints and floats, and 9-register strings are not read half way through changing.
David
Peter Nachtwey
Member
That would be nice but I, my customers actually, have been bitdexdyne said:
> Modbus does not have a 32 byte restriction. Do you have the
> specifications?
Fine, so you are sending 32 registers per scan but what if the scan is longer than the time it takes to send 32 registers? Then there will be a gap that will cause an error.
In a case like this I would just make the maximum packet size for that device 32 registers.
> The problem that arises is that the data in these buffers
> must be sent and received one character after the other with
> gaps greater than 3.5 character times. This is where I have
> seen problems with some PLCs.
Yes, then you should be OK.
Peter,
sorry I haven't worked out how to do these clever quote boxes
> Fine, so you are sending 32 registers per scan but what if the scan
> is longer than the time it takes to send 32 registers? Then there
> will be a gap that will cause an error.
I think it said, and I think I explicitly said above, that it would build the reply in it's output buffer at the rate of 32 registers per scan, but only start transmitting once the reply was complete in the buffer. That should remove any charater timing iissues, at the expense of a longer delay before the reply.
I''m quite prepared to believe that there are **** implementation about which send partial replies with incorrect gaps that violate the protocol... If I meet one I'll have to deal with it
Whoever decided that 3.5 character times was significant compared with 3 or 4 anyway? SOmeone with nowt better to do I think.
sorry I haven't worked out how to do these clever quote boxes
> Fine, so you are sending 32 registers per scan but what if the scan
> is longer than the time it takes to send 32 registers? Then there
> will be a gap that will cause an error.
I think it said, and I think I explicitly said above, that it would build the reply in it's output buffer at the rate of 32 registers per scan, but only start transmitting once the reply was complete in the buffer. That should remove any charater timing iissues, at the expense of a longer delay before the reply.
I''m quite prepared to believe that there are **** implementation about which send partial replies with incorrect gaps that violate the protocol... If I meet one I'll have to deal with it
Whoever decided that 3.5 character times was significant compared with 3 or 4 anyway? SOmeone with nowt better to do I think.
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...
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...
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...
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...
Dear friends,
Could somebody recommend me reliable producer of pulp consistency transmitters?
Best regards,
Goran Vuckovic.
