Support Function Code 08 sub-function code 00?

[ChrisR]

Scott,
I have an application where I'm running as a modbus slave.
Sometimes my masters want to have redundant slaves. They use function
code 08, sub-function code 00 (return query data) as a loopback/
heartbeat test to determine if a slave is alive, to use in their
switchover logic. Of course any normal call to a slave returns a
response to the master. The advantage of this call, though, is that
the slave just returns exactly what the master sent them. That is,
this part of the master that is checking slave health doesn't need to
know anything about whether or not a given register exists in the
slave definition.
It seems like it would be quite straightforward. What do you
think?
Chris

[Scott Alexander]

Chris,

Easy enough. It'll be a week or so until I can get to it but I'll let
you know when it's done.

Scott Alexander

[ChrisR]

Thanks!

On Feb 6, 11:46 am, "Scott Alexander" <sja...@gmail.com> wrote:
> Chris,
>
> Easy enough. It'll be a week or so until I can get to it but I'll let
> you know when it's done.
>
> Scott Alexander
>

> On 2/6/07, ChrisR <christina.roma...@ge.com> wrote:
>
>
>
>
>
> > Scott,
> > I have an application where I'm running as a modbus slave.
> > Sometimes my masters want to have redundant slaves. They use function
> > code 08, sub-function code 00 (return query data) as a loopback/
> > heartbeat test to determine if a slave is alive, to use in their
> > switchover logic. Of course any normal call to a slave returns a
> > response to the master. The advantage of this call, though, is that
> > the slave just returns exactly what the master sent them. That is,
> > this part of the master that is checking slave health doesn't need to
> > know anything about whether or not a given register exists in the
> > slave definition.
> > It seems like it would be quite straightforward. What do you
> > think?

> > Chris- Hide quoted text -
>
> - Show quoted text -

[sja...@gmail.com]

Chris,

Looking a little deeper into the implementation details of function
code 8, sub function Code 00

The Modbus Application Protocol Spec V1.1a shows the Data section of
the message to be N x 2 bytes in size, yet the message does not
contain any additional byte count information. This may be ok for
Serial ASCII which wraps each message in special characters
(':"<message>"\n") but Serial RTU does not. It is unclear to me how a
Modbus Slave could determine the end of such a message...

Does anyone have any input on this? could this be a typo in the spec?
All additional function code 8 sub function codes show fixed size (two
byte) Data sections.

Scott Alexander

> > - Show quoted text -- Hide quoted text -

[Victor Rocha]

hello

please correct me if i'm wrong...
the RTU end-of-message is defined as a "t3.5" , which is 3.5 * (byte-duration).

everytime when this timer gets "triggered", CRC should be calculated
and compared to received bytes. if (calculated CRC == last bytes
received), then message is finished... else, the frame can be
discarded.

sorry, i haven't looked at the inner parts of nmodbus yet, i don't
know if this approach is viable or easy to implement. the Modbus over
Serial Line specification shows a RTU state machine which is mostly
based on timers and "flags"... that seems suitable for embedded
multi-tasking applications, which is normally the case for modbus
slaves...

greetings
victor

[Scott Alexander]

Good point Victor. It's been a while and I had forgotten the official
spec for the Modbus Serial RTU protocol was timing based.

When implementing RTU I read a lot feedback from Modbus users
complaining that timing based RTU implementations were unreliable for
their device(s). That combined with the fact that Windows is not a
real time operating system motivated my decision to provide a more
naive implementation.

In summary, the beginning of each message is read, number of bytes
remaining is calculated, then the rest of the message is read. Each
read operation is subject to a configurable Timeout to protect from an
unresponsive read.

That being the case I think I'll opt to implement a "limited" version
of function code 8, sub function code 0. That is, the data section is
a fixed 2 bytes in size.

Anyone have any thoughts on this?

Thanks!

Scott

[Victor Rocha]

hello again

On the Master side of the protocol, i think there would be no problem
in assuming that the response's data section will have just the same
size as the request's data section, since sub-function 0 would only
"echo" the sent bytes. If there is a timeout or not enough bytes to
read, the response could then be safely discarded as I/O error...

for example, when Master sends 5 bytes of data in a request, it should
just wait for 5 bytes of data in the response, plus the CRC.

On the Slave side i guess things would be rather different... using a
fixed data section would be fine for some situations, but i don't know
whether it should be set to fixed 2 bytes, or it should be a
configurable option.

For example: in Chris' situation, how many data-bytes does the Master
use for polling the redundant slaves? If the Master's behaviour is
constant and well-known, Chris could just set a variable (or define)
like "SubFunction_0_DataLength" in her slave implementation... ;-)

i'm afraid there is no easy solution without using timers... as a
first thought, I imagined reading only one byte at a time, pushing
them to a buffer, and for every byte received, perform a CRC
calculation in this buffer to check if the frame has already "closed".
But then, there would be some rare situations where some of the "data
bytes" would just accidentaly "fit" with the CRC calculation for the
beginning of the frame, thus bringing misleading results.... for
example...
if the message is "01 08 00 XX YY ZZ CRC1 CRC2"
if "YY ZZ" is (by chance) the CRC for "01 08 00 XX", we would get a
wrong result.. :-(

well... that's just some thoughts, anyway! :-)

by the way, thanks scott! i'm developing a simple data logger system
in linux, and nmodbus is working well with mono...
I only had to add a "port.DtrEnable = true" to get it working with my
485/232 converter :-)

best regards.. and good luck!

Victor

[ChrisR]

Scott,
The "limited" version with the data section being a fixed 2 bytes
in size is fine. It's certainly defensible to our integrators because
they can achieve their goal.

Thanks,
Chris

On Feb 15, 3:37 pm, "Scott Alexander" <sja...@gmail.com> wrote:
> Good point Victor. It's been a while and I had forgotten the official
> spec for the Modbus Serial RTU protocol was timing based.
>
> When implementing RTU I read a lot feedback from Modbus users
> complaining that timing based RTU implementations were unreliable for
> their device(s). That combined with the fact that Windows is not a
> real time operating system motivated my decision to provide a more
> naive implementation.
>
> In summary, the beginning of each message is read, number of bytes
> remaining is calculated, then the rest of the message is read. Each
> read operation is subject to a configurable Timeout to protect from an
> unresponsive read.
>
> That being the case I think I'll opt to implement a "limited" version
> of function code 8, sub function code 0. That is, the data section is
> a fixed 2 bytes in size.
>
> Anyone have any thoughts on this?
>
> Thanks!
>
> Scott
>

[Scott Alexander]

Chris,

The latest version (1.0
http://code.google.com/p/nmodbus/downloads/list) includes support for
function code 8, sub function code 0. Both serial ascii and rtu
masters include the method

public bool ReturnQueryData(byte slaveAddress, ushort data)

This method returns true if the data was echoed correctly by the
slave, false otherwise. I didn't feel there was any value in having
the method return the echoed data... thoughts?

As I mentioned I lack a physical device to test this on so I'm
anxiously awaiting any feedback you may have.

Enjoy.

Scott Alexander

[ChrisR]

Scott,

I think it's great to return true if the data was echoed correctly and
false otherwise. Also, the new code worked well for me.

Thanks alot!
Chris

On Feb 24, 8:11 pm, "Scott Alexander" <sja...@gmail.com> wrote:
> Chris,
>
> The latest version (1.0http://code.google.com/p/nmodbus/downloads/list) includes support for

> function code 8, sub function code 0. Both serial ascii and rtu
> masters include the method
>
> public bool ReturnQueryData(byte slaveAddress, ushort data)
>
> This method returns true if the data was echoed correctly by the
> slave, false otherwise. I didn't feel there was any value in having
> the method return the echoed data... thoughts?
>
> As I mentioned I lack a physical device to test this on so I'm
> anxiously awaiting any feedback you may have.
>
> Enjoy.
>
> Scott Alexander
>