modbus frame size

M

Thread Starter

Mario de Sousa

Hi,

Could anybody please confirm/deny that the maximum frame size for modbus rtu is: 6 (header) + 250 (data) + 2 (crc) bytes

This is both for queries and responses.

I figured this out from the maximum number of I/Os and registers that can be read/written to for several PLCs.

I did not find any clear statement giving the maximum frame size.
Granted, I didn't look too hard for it...


Thanks

Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Greg Goodman

> Could anybody please confirm/deny that the maximum frame size for
> modbus rtu is: 6 (header) + 250 (data) + 2 (crc) bytes

[snip]

> I did not find any clear statement giving the maximum frame size.
> Granted, I didn't look too hard for it...

Mario,

Section 5.1 of the Modicon spec
(http://www.modicon.com/techpubs/app7.html) has tables listing the maximum amount of data that each [Modicon] controller can request or send in a master query, or return in a slave response. Several of the messages (such as 'read general reference') are not measured in data elements, but in bytes, and carry the following note:

"The maximum length of the entire message must not exceed 256 bytes."

We have always used this as the maximum message size for any Modbus protocol message.

Greg Goodman
Chiron Consulting

_______________________________________________
MAT-devel mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/mat-devel
 
M

Mario de Sousa

Greg Goodman wrote:
>
> Section 5.1 of the Modicon spec
> (http://www.modicon.com/techpubs/app7.html) has tables listing the
> maximum amount of data that each [Modicon] controller can request or
> send in a master query, or return in a slave response. Several of the
> messages (such as 'read general reference') are not measured in data
> elements, but in bytes, and carry the following note:
>
> "The maximum length of the entire message must not exceed 256 bytes."
>
> We have always used this as the maximum message size for any Modbus
> protocol message.

Yes, I had already found that too, but since the note is supposed to refer only to the 20 and 21 functions, you cannot take this as a global rule.

In particular, if you add up the size of a 0x03 funtion with 125 registers (the accepted limit of 984 PLC), then you get a message size with a grand total of 257 bytes + 2 CRC!! (6 header, 1 byte count, 250 data 2 CRC) ;-)
And if you follow the spec, this is supposed to be legal! That is one reason why I don't quite believe in the 256 byte limit!

Yesterday I had already decided to take Randy's approach, and decided for a 260 byte limit. But this does not yet take into account any limit to the 20 (0x14) master query message. What is the limit to this message?

Since I'm not currently implementing that message, I'm not going to worry too much about it...

BTW, there is also an inconsistency in the spec regarding the maximum inter character interval! I'm in a big rush now, but I can point you to it later on...

Cheers,

Mario.


----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 
M

Mario de Sousa

Arghhh!!!...

I have just found a few minutes to calmly re-read my message, and found that it is full of errors!! It's what comes from writing in a rush...
:-(

Mario de Sousa wrote:
>
> Yes, I had already found that too, but since the note is supposed to
> refer only to the 20 and 21 functions, you cannot take this as a global
> rule.

I stay by the above paragraph. I have not yet seen a hard and fast rule stating that the limit is 256 bytes.

> In particular, if you add up the size of a 0x03 funtion with 125
> registers (the accepted limit of 984 PLC), then you get a message size
> with a grand total of 257 bytes + 2 CRC!! (6 header, 1 byte count, 250
> data 2 CRC) ;-)
> And if you follow the spec, this is supposed to be legal! That is one
> reason why I don't quite believe in the 256 byte limit!


Now here I messed things up. I wanted to refer to function 16 (preset multiple registers), but went and got the limit to function 03. The
correct limit to function 16 is 100 registers (giving a message of 207 + 2CRC bytes) and not 257 as stated before.

But the question remains: can we be sure that in the future there won't be a PLC supporting more registers?

> Yesterday I had already decided to take Randy's approach, and decided
> for a 260 byte limit. But this does not yet take into account any limit
> to the 20 (0x14) master query message. What is the limit to this
> message?

The above was really stupid. Here we are discussing the note that states the limit to function 20, and I go and ask for it again. Really
stupid of me...


> BTW, there is also an inconsistency in the spec regarding the maximum
> inter character interval! I'm in a big rush now, but I can point you to
> it later on...

Well, I have had a chance to read it more carefully, and it is not so much an inconsistency, but really a strange behaviour...

Right, here it is:

"The entire message frame must be transmitted as a continuous stream. If a silent interval of more than 1.5 character times occurs before
completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a
new message.

Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a
continuation of the previous message. This will set an error, (...) CRC will not be valid (...)".

The above means that if we stop transmitting in the middle of a frame, we can start a new frame afresh after 1.5 character intervals. But if we
send a frame correctly to the end, there must be a silence of 3.5 character times before the beginning of the next frame. I don't know about you, but I find this strange... Is there any reason for the above behaviour? Why not use only the 3.5 value? It would make implementation
much simpler...


Cheers,

Mario.


P.S. Sorry for taking up bandwidth with my stupidities...


--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario (quoting a spec):
> Right, here it is:

> "The entire message frame must be transmitted as a continuous stream. If
> a silent interval of more than 1.5 character times occurs before
> completion of the frame, the receiving device flushes the incomplete
> message and assumes that the next byte will be the address field of a new
> message.

> Similarly, if a new message begins earlier than 3.5 character times
> following a previous message, the receiving device will consider it a
> continuation of the previous message. This will set an error, (...) CRC
> will not be valid (...)".

Judging just by that, I'd expect that gaps of between 1.5 and 3.5 chars may or may not be considered a continuation (undefined behaviour). It's a rather large margin, but quite understandable if some models look for a two-character gap and some for a three-character one.

But that's just my (conservative) reading. The reality may be anything.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Mario de Sousa wrote:
> Well, I have had a chance to read it more carefully, and it is not so
> much an inconsistency, but really a strange behaviour...
>
> Right, here it is:
>
> "The entire message frame must be transmitted as a continuous stream. If
> a silent interval of more than 1.5 character times occurs before
> completion of the frame, the receiving device flushes the incomplete
> message and assumes that the next byte will be the address field of a
> new message.
>
> Similarly, if a new message begins earlier than 3.5 character times
> following a previous message, the receiving device will consider it a
> continuation of the previous message. This will set an error, (...) CRC
> will not be valid (...)".
>
> The above means that if we stop transmitting in the middle of a frame,
> we can start a new frame afresh after 1.5 character intervals. But if we
> send a frame correctly to the end, there must be a silence of 3.5
> character times before the beginning of the next frame. I don't know
> about you, but I find this strange... Is there any reason for the above
> behaviour? Why not use only the 3.5 value? It would make implementation
> much simpler...
>

Ah! I have found the inconsistency...

Right at the top of the page the spec states:
"In RTU mode, messages start with a silent interval of at least 3.5 character times".

This seems to conflict with the above first paragraph stating that a new frame may begin 1.5 character times after an aborted frame!

Am I mis-reading the spec?

Anyway, there is no way we can implement this unless we do it as a kernel module/device driver, so it is probably useless trying to figure out what the spec is really saying.

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Jiri Baum wrote:
> Judging just by that, I'd expect that gaps of between 1.5 and 3.5 chars may
> or may not be considered a continuation (undefined behaviour). It's a
> rather large margin, but quite understandable if some models look for a
> two-character gap and some for a three-character one.
>

Yes. After another moment's thought I guess that the desired behaviour is that any bytes sent between the 1.5 and 3.5 character interval after
an aborted frame should simply be discarded.

Please forgive me. I'm a bit slow this morning... ;-)

Cheers,

Mario.

--
----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> Jiri Baum wrote:
> > Judging just by that, I'd expect that gaps of between 1.5 and 3.5 chars
> > may or may not be considered a continuation (undefined behaviour). It's
> > a rather large margin, but quite understandable if some models look for
> > a two-character gap and some for a three-character one.

Mario:
> Yes. After another moment's thought I guess that the desired behaviour is
> that any bytes sent between the 1.5 and 3.5 character interval after an
> aborted frame should simply be discarded.

I think it's more that they may or may not be joined to the previous frame, depending on the phase of the moon, the Dow Jones index and so on.

Ie, don't send anything in that time period; if you receive something, do as you wish (perhaps make the cut-off time 2.5 or something).


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Mario.

I'm just curious if the preemptable kernal patch would let us do this except for the occasional long lock?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Gilles Allard

Receiving a Modbus RTU message is not easier.
The inter-character timer is not implemented in hardware. So it must be implemented in the driver (retriggered on every interrupt).
You should also disable the FIFO on the UART. I do not think this protocol will be easy to implement on a general-purpose OS.

Gilles


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
W

Wayne Johnston

I think everyone who ever implemented Modbus has come up with the same question. My interpretation of it is this.

The transmitter must ensure there is no gap larger than 1.5 character times.

The receiver detects the start of a new message as the first character following a gap of at least 3.5 character times. It detects the end of a
message when 3.5 character times elapse following a character.

If the receiver detects a gap of more than 1.5 characters in the middle of a message, it should discard the message and wait for the start of a new message.

In practice you can likely skip the last test, since the test for the end of a message accomplishes the same thing, although the timing is not the same. There are a lot of implementations out there that are not very good at meeting the first rule. Testing for it may make the driver work worse.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G
> correct limit to function 16 is 100 registers (giving a message of 207 + 2CRC bytes) and not 257 as stated before.
>
> But the question remains: can we be sure that in the future there won't be a PLC supporting more registers?

No, we can't be sure that there won't be such a PLC, but we can be sure that we don't care.

Just because a PLC might be able to generate a response message longer than 256 bytes doesn't mean it will ever get the chance. If your Modbus master code nevers makes a query that requires more than 256 bytes worth of answer, that hypothetical capability never gets excercised while the PLC is talking to your master.

And if you're writing a PLC slave module rather than a master, you can pick any upper limit you like, for the same reason. You will only ever get to answer the questions asked by a master. A master that believes a Modbus message cannot be longer than 256 bytes will not (or at least should not) ask a question whose answer violates the limit. And any master that asks a question that implies a longer answer will have to deal with what it gets: either a legally formed long answer, or an error response indicating an illegal request. Either way, the response is correct for your slave, especially if the issue is explicilty addressed in your documentation.

In fact, it seems to me that there is no reason to implement any particular response message length limit in a slave module. Just answer the questions you're asked, and leave it to the master to ask questions it can handle the answers to.

This approach, by the way, has no sanction from Modicon, and no explicit support in the Modbus spec. It's just my two cents,

Greg Goodman
Chiron Consulting
 
S

Silbaugh, Randy D.

Mario wrote:

>>> But the question remains: can we be sure that in the future there won't
>>>be a PLC supporting more registers?

Nope.

I deal almost everyday with vendors who work hard to use what they consider the proper use of the protocol spec. And a high percentage of the time they become compatible with only one or two other vendors equipment. One of the goofy problems I have come across: two piece of equipment that both said they could talk to each other. One (reading the spec) hard coded their device to no parity and two stop bits. The other (the creator of the spec) decided to hard code one of their device lines to one stop bit....

If you are picking a limit for the Modbus Response, I again would look at the limit in the data length field. this would be the max response no matter what the function code or device. You may set what ever limit you see fit. Modicon gives the 984 PLC a 125 byte limit based upon that being the maximum that the PLC can process in one scan.

Now the query implementation is a little trickier. Here you have two bytes for the starting address and two bytes for the number of registers. While I know of no hardware that would allow you to send or ask for that much data at once, you would be creating a possible incompatibility if you assumed lower. With that said I think that if you go with the 255 byte max response data field then you could say that your maximum query number of register request to be 255 * 16 = 4080 (for coils/inputs).

And Mario, we all have our off days....I just wish mine were so short.....

Randy.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

The preemptable patch should be removing those long locks, so we shouldn't have a problem there.

Unfortunately, the above would not be enough. You would still have to take into account the scheduling policy and the scheduling parameters.
Some scheduling policies would not even be able to support it, no matter what the parameters.

The short answer is: it depends, but it would help.

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G
> Greg, I believe you support Modbus on the PuffinSCADA? Can you give us
> an idea of how you went about working around the issues we have been
> discussing? Or better yet, would it be possible to publish your modbus
> code under the GPL? It doesn't make much sense to duplicate our efforts
> here...

Yes, PuffinSCADA has a Modbus implementation. And yes, it will be released with the rest of the package. However, the answer to your question about addressing the issue under discussion is "we don't worry about it". Our protocol driver (like virtually every other PC-based
implementation of serial Modbus communications) is a user-space program that does serial reads and writes. The closest we come to handling the
character timing in the spec is configuring the inter-character timeout for reads on the open serial port. We write messages in a single write;
if the hardware or the OS can't handle that without introducing gaps of greater than 1.5 characters, then we need a better platform.

To get a message, we read all the data on the port until there isn't any more, then parse messages based on expectation and inspection of
content.

do I or do I not expect a message?

from what slave address, and in response to what query?

how many bytes do I need to have before I can try interpreting a
header?

how many bytes does this message have, assuming I'm actually looking at
a header?

is that message length reasonable?

do i have that many bytes?

is there a checksum out there that agrees?

We do not detect aborted frames by the timing gap. We determine that the "message" we got isn't any good. At that point, we can either do
something sophisticated or something simple. The sophisticated approach is to step through the available data stream, looking for the start of a
legal message. The simple approach is to throw away the entire message (or collection of fragments, or noisy garbage, or whatever it was we
actually got) and ask the question again.

Personally, I prefer the simple solution. Any number of things can cause a response to be garbled, requiring that the master re-request the
data. And noisy comm lines seem to occur a whole lot oftener than a deliberately aborted frame. So we keep the code simple and occasionally
suffer a small inefficiency. I have implemented "sophisticated" before, to no apparent benefit. PuffinSCADA currently implements "simple".

I'm pretty sure that's not the answer you were looking for, but I'll bet that more PC-based Modbus implementations do lazy error handling at the application level than do righteous realtime handling in a kernel module. And it seems to work for most people most of the time.

Regards,

Greg Goodman
Chiron Consulting

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Greg Goodman wrote:
>
> > Greg, I believe you support Modbus on the PuffinSCADA? Can you give us
> > an idea of how you went about working around the issues we have been
> > discussing? Or better yet, would it be possible to publish your modbus
> > code under the GPL? It doesn't make much sense to duplicate our efforts
> > here...
>
> Yes, PuffinSCADA has a Modbus implementation. And yes, it will be
> released with the rest of the package. However, the answer to your
> question about addressing the issue under discussion is "we don't worry
> about it". Our protocol driver (like virtually every other PC-based
> implementation of serial Modbus communications) is a user-space program
> that does serial reads and writes. The closest we come to handling the
> character timing in the spec is configuring the inter-character timeout
> for reads on the open serial port. We write messages in a single write;
> if the hardware or the OS can't handle that without introducing gaps of
> greater than 1.5 characters, then we need a better platform.
>

Yes, considering that I had also decided on not implementing it as a kernel device driver, there is simply nothing we can do on this respect.

Howerver, I do check whether the write() returns with the appropriate number of characters, and re-send otherwise. There is a maximum number of retries.

In other words, I may send out aborted frames! Not intentionally, mind you, but because the OS might be interrupted by something else during
the call to write(). So the slaves must be prepared to handle them.

I guess it would be better to continue sending an aborted frame, even if it has an interval larger than the 1.5 character limit? It seems most
implementations (at least on PCs, I don't know about PLCs, anyone?) don't care about these delays, and would therefore consider that frame
perfectly correct, even though it is not following the modbus spec.
But, on the other hand, if we are talking to a slave that follows the modbus spec, then it won't understand our query, and we will only re-issue it once we time-out on the response from that slave.

So, let me sum up my current doubt this way. Should we:
1) Continue sending a frame to the end, even though we know we have an interchacarcter interval larger than 1.5 characters.
2) Abort sending a frame that we know has an intercharacter interval larger than the 1.5 character time limit. Re-send the frame from the
start.

1) will we better for PC slave applications, that do not follow the spec, but worse for implementations that do follow the spec, because we will ony re-send the query after a time-out waiting for the response.
2) Is the other way around.

Currently my implementation uses 2), and my guess is that your's follows 1). Which one should it be?

I believe I will probably make this a user defined option. But the question remains, which of them should be the default? 1) which doesn't
follow the standard, or 2) that does?

(...)
>
> We do not detect aborted frames by the timing gap. We determine that
> the "message" we got isn't any good. At that point, we can either do
> something sophisticated or something simple. The sophisticated approach
> is to step through the available data stream, looking for the start of a
> legal message. The simple approach is to throw away the entire message
> (or collection of fragments, or noisy garbage, or whatever it was we
> actually got) and ask the question again.
>
> Personally, I prefer the simple solution. Any number of things can
> cause a response to be garbled, requiring that the master re-request the
> data. And noisy comm lines seem to occur a whole lot oftener than a
> deliberately aborted frame. So we keep the code simple and occasionally
> suffer a small inefficiency. I have implemented "sophisticated" before,
> to no apparent benefit. PuffinSCADA currently implements "simple".
>
> I'm pretty sure that's not the answer you were looking for, but I'll bet
> that more PC-based Modbus implementations do lazy error handling at the
> application level than do righteous realtime handling in a kernel
> module. And it seems to work for most people most of the time.

That is exactly the answer I was looking for! What you implemented, and most improtantly, the rationale behind it!

I have almost come to the decision of implementing both approaches. Doing my best to figure out what is being sent over the bus, but if all else fails, then re-send the query.

The reason I will probably go the hard way is that on the back of my mind I have always been considering re-using the same code for a modbus
slave module, and on a non-RT OS it seems to me that we can't be too lazy here, or else the slave gets out of synch with the state of the bus. Especially if the master follows the spec and uses the method 2) I discussed above.

I guess a lazy implementation will also work most of the time on a slave because
a) there will be very few aborted frames on the bus;
b) most query-response transactions will usually have large delays between the query and the response, and the slave will be able to synch
with the state of the bus using these silent intervals. But we have no guarantees this will occur, especially if the slave is on a heavily
loaded system.

Once again, I'm sorry for rambling on. I'm still considering all the pro's and con's of each approach. That's why I am asking for everybody's
ideas and opinions...

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G
> Howerver, I do check whether the write() returns with the appropriate
> number of characters, and re-send otherwise. There is a maximum number
> of retries.
>
> In other words, I may send out aborted frames! Not intentionally, mind
> you, but because the OS might be interrupted by something else during
> the call to write(). So the slaves must be prepared to handle them.

Sure. A write() that doesn't send the specified number of characters is a failed write. The assumption has to be that we put garbage on the
line, and that it will be ignored by the slave.

> I guess it would be better to continue sending an aborted frame, even
> if it has an interval larger than the 1.5 character limit? It seems most
> implementations (at least on PCs, I don't know about PLCs, anyone?)
> don't
> care about these delays, and would therefore consider that frame
> perfectly correct, even though it is not following the modbus spec.

It depends on how big the gap is, as perceived by the receiver (slave). If the message is completely available to the slave when it gets around to reading the port, then there is no gap. If the message is only partially available when the slave tries to read it, then it's garbage.

> So, let me sum up my current doubt this way. Should we:
> 1) Continue sending a frame to the end, even though we know we have an
> interchacarcter interval larger than 1.5 characters.
> 2) Abort sending a frame that we know has an intercharacter interval
> larger than the 1.5 character time limit. Re-send the frame from the
> start.

[snip]

> Currently my implementation uses 2), and my guess is that your's
> follows 1). Which one should it be?

If I understand your summary, our implementation uses (2). That is, if the write() fails, we resend the entire message. We do this in a retry
loop up to a configurable max, and implement a deliberate wait between writes to make sure the slave has time to clear the garbage. (The wait
is currently hard-coded, and should probably be calculated from the configured baud rate.)

> I believe I will probably make this a user defined option. But the
> question remains, which of them should be the default? 1) which doesn't
> follow the standard, or 2) that does?

I don't expect it will happen often enough to matter. Pick whichever one makes you happy. As long as it's an option, users can tune their
own applications. The fun part is documenting the configuration switch well enough to let users make well-informed choices.

> I have almost come to the decision of implementing both approaches.
> Doing my best to figure out what is being sent over the bus, but if all
> else fails, then re-send the query.

My suggestion: implement as many different approaches as you think are warranted, but start with the simplest, most robust, most bullet-proof,
easiest-to-maintain. Make sure it works. Then add sophistication as time and interest allow, or as practical application requirements dictate.

> The reason I will probably go the hard way is that on the back of my
> mind I have always been considering re-using the same code for a modbus
> slave module, and on a non-RT OS it seems to me that we can't be too
> lazy here, or else the slave gets out of synch with the state of the
> bus. Especially if the master follows the spec and uses the method 2) I
> discussed above.
>
> I guess a lazy implementation will also work most of the time on a
> slave because ...

I agree. As I see it, the slave can afford to be as lazy as it likes. Since Modbus is a synchronous protocol, the master will not get an
acknowledgment for any message the slave chooses to ignore, and so will (probably) resend it. The communication takes place for the the master's benefit, and so it falls to the master to assume the burden of correcting comm faults. (Consider it a sort of passive-aggressive behavior on the part of the slave, which seems somehow appropriate. :^)

On the issue of duplication of effort, I wouldn't worry about it much. The portions of code that are likely to be share-able are the most
trivial: message formatting and parsing, CRC calculations, etc. The complicated part - deciding what data to ask for, converting application configuration into stdio() calls to configure the port, handling the data returned by a slave - is all very specific to the application, its configuration and its data structures. Which is not to say that there's
no reason to share code. Just that a surprisingly small portion of a "protocol driver" actually concerns itself with the protocol; the bulk of the driver deals with higher-level issues of configuration, database management and client/server communication.

Regards,

Greg

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
G Modbus 1
R Modbus 1
J Modbus 5
J Modbus 7
B Modbus 10
Top