linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Pavloff <apavloff@eason.com>
To: 'Gerald Emig' <gme@emig-software.de>
Cc: "'linux-serial@vger.kernel.org'" <linux-serial@vger.kernel.org>
Subject: RE: your mail
Date: Tue, 27 Aug 2002 09:55:04 -0700	[thread overview]
Message-ID: <D3AF5F134D627243993F2F2FC32EE4D20CE1CE@mailman.eason.com> (raw)


Hi Gerald, here's some more info:

Sending data isn't the problem.  The problem is acting as a slave and
receiving unsolicited packets from a master.   I need to determine when a
packet is complete.  If I was sending the packets (which I have done before
and am doing now), I can cheat a bit because I know the length of the packet
I'm "supposed" to be getting back.   I can't do that when acting as a slave.

This is different that the other protocol I'm familiar with.

GE's SNP uses two packets -- the first fixed size and containing the length
of the second size.
AB's DF1 has a fixed packet structure with many special characaters that
makes it easy to pull in a piece at a time

With Modbus RTU I neither know how long a packet is going to be, nor do I
have a sequence of bytes that can be used to judge the end of a packet.  I
need to be able to understand that 3.5 characters times of nothing means the
end of the packet.

Do I need a line discipline for this one portion of the driver?

Alex Pavloff
Software Engineer
Eason Technology
 


-----Original Message-----
From: Gerald Emig [mailto:gme@emig-software.de]
Sent: Tuesday, August 27, 2002 3:00 AM
To: Alex Pavloff
Cc: 'linux-serial@vger.kernel.org'
Subject: Re: your mail



To wait for at least 3.5 character times you can simply wait for this time
or more using usleep() before sending your data.

On Mon, 26 Aug 2002, Alex Pavloff wrote:

>
> Good (morning/afternoon/evening) folks,
>
> I am writing Modbus RTU code for Linux 2.4.19.  While seeminly simple to
do
> in userspace, there's one big kicker that I can't handle there easily.
> Modbus RTU is a binary serial protocol used in industrial automation.
First
> used by the Modicon PLCs, it's found on a variety of devices from a
variety
> of manufacturers.
>
> The specification is at www.modbus.org, under "Modbus Standard Library",
and
> its the Modbus Serial Protocol Reference Guide.
>
> Here's the part that I don't think I can resolve in userspace:
> -----
> RTU Framing
> In RTU mode, messages start with a silent interval of at least 3.5
character
> times. This is most easily implemented as a multiple of character times at
> the baud rate that is being used on the network (shown as T1-T2-T3-T4 in
the
> figure below). The first field then transmitted is the device address.
>
> The allowable characters transmitted for all fields are hexadecimal 0-9,
> A-F. Networked devices monitor the network bus continuously, including
> during the 'silent' intervals. When the first field (the address field) is
> received, each device decodes it to find out if it is the addressed
device.
>
> Following the last transmitted character, a similar interval of at least
3.5
> character times marks the end of the message. A new message can begin
after
> this interval.
>
> 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.
> -----
>
> 3.5 character times at high baud rates is not something I can pull off
with
> termios.  To get the Modbus RTU frames without resorting to some really
> strange code in userspace, should I write a line-discipline module whose
> sole purpose is to deal with the character timing?
>
> Any comments (yay/nay/huh?) appreciated.
>
> Alex Pavloff
> Software Engineer
> Eason Technology
>
>

Gerald Emig



             reply	other threads:[~2002-08-27 16:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-27 16:55 Alex Pavloff [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-09-03 17:36 Barnett, Andy
2020-09-18  7:56 ` your mail Johan Hovold
     [not found] <20191026192359.27687-1-frank-w@public-files.de>
2019-10-26 19:30 ` Greg Kroah-Hartman
2004-08-24  6:05 (unknown) Francisco M. Marzoa Alonso
2004-08-24  9:39 ` your mail Jan-Benedict Glaw
2002-08-27  1:48 (unknown) Alex Pavloff
2002-08-27  9:59 ` your mail Gerald Emig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D3AF5F134D627243993F2F2FC32EE4D20CE1CE@mailman.eason.com \
    --to=apavloff@eason.com \
    --cc=gme@emig-software.de \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).