Need a simple protocol

Daveb schrieb:

I assume you'll get faster and better results when you just implement your own protocol, compared to exaktly implementing an existing one - especially if it's only "simple" [tm] communication.

Something like: Master sends data . Slave answers with or , and then data if needed. "Data" should be only visible 7-bit ASCII characters for additional range checking.

First byte(s) of master data contain a command code, and the last bytes a checksum (CRC-8 or the like). If the master does not receive an , or receives nothing, or receives data that doesn't match the CRC, it simply retries for a given number before it reports an error.

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

The main problem of Modbus binary serial encapsulation is the difficulty of marking the frame boundaries. The protocol uses two ways:

- when the transfer stays in sync, the receiver may parse the received packet and imply the pacekt length from the contents,

- when the transfer drops outp of sync, there are time limits (max 1.5 octet times inside a frame, min 4 octet times between frames) which enable re-synchronization.

The packet parsing requirement forces the serial receive interrupt driver to understand the whole packet structure, and it prevents a sensible layer separation of the protocol handlers.

The timing requirements are difficult to keep with any PC system, as the operating system is not prepared to handle and obey them. For receiving, the hardware FIFO has to be disabled to detect the incoming character gaps properly. None of the PC Modbus programs I have used, does conform to the timing requirements.

IMHO, you'd be better off using a packet protocol resembling the PPP over HDLC-style encapsulation. It's completely binary-transparent and it can easily catch up after a character loss / mutilation. Of course, the frame with the dropped character is lost, anyway.

Been there - done that.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

Yep. No new information, but just to emphasize ... I agree that the PPP HDLC framing (RFC1662) is the best way to go with this type of application.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

I've also known of people who kept a running CRC on the receive stream and declared a frame end when the CRC came out right. That works even on unknown command/response frames where you don't know how the length is implied.

The Modbus timing requirements are difficult even with a custom designed embedded system. As you point out, it completely precludes the use of a receive FIFO unless the FIFO has been specifically designed to detect the inter-character timeouts like those used by Modbus (I know of one that was). It's easy enough if you can run one-interrupt-per byte and dedicate a hardware timer to each receive stream. Trying to support multile high-baud-rate receive streams gets unpleasant.

PC programs are almost invariably masters, and masters don't need to be able to detect the inter-character timeout. If they get confused they just stop sending commands and wait for a while. The only situation where the timeout really has to work is on something like a 2-wire RS-485 bus where command and response frames are on the same "wire" and all of the slaves see both.

I agree 100%. I rather lean toward STX/ETX framing with HDLC-style escaping of STX/ETX. I don't think it really matters much, but I like having start/end delimiters differ.

--
Grant Edwards                   grante             Yow!  The PINK SOCKS were
                                  at               ORIGINALLY from 1952!! But
                               visi.com            they went to MARS around
                                                   1953!!

You might want to consider the Burroughs (now Unisys) poll/select protocol or some variant. It can handle multiple devices, has a fairly low overhead and has been around forever. Sticking with the standard exactly also lets you use varoius gateway devices in case you ever find you need to hook up to ethernet, RS-232, etc.

The IBM BISYNC protocol is another possibility, though perhaps not quite as well suited.

hope that helps

Joe Power

As well as the other suggestions you could look at the SNAP protocol.

--

John Devereux

We have a protocol that we use for RS-485 based multi-drop systems. I have emailed a copy directly to Daveb.

The protocol includes addressing for up to 252 drops, but is easily expandable. A couple of addresses are reserved for broadcasting to all receivers.

The protocol is also ASCII based to allow easily readable control messages.

I can email a copy to anyone interested or post it on a web site if there is enough interest.

--
Scott
Validated Software Corp.

Scott

Sorry, my last post had an out of date email address. Use the reply here, with the necessary corrections of course.

well

Forget it. BISYNC is bloody complicated as soon as binary transparency is required.

Also, it suffers of the same fault in determining the frame length as Modbus: the receiver interrupt handler has to parse the data stream with a fancy state machine to know when to stop receiving.

Once again: PPP over HDLC-style framing was the first time the binary-transparent packet over an async line transfer problem was solved correctly.

--

Tauno Voipio
tauno voipio (at) iki fi

And even that isn't possible if you've got a network of mixed-vendor devices and as a slave you've got to watch commands/responses that you don't "understand" because they're extensions that some other vendor pulled out of somewhere.

There were a some other similar flag/escape protocols before that that were probably just as good, but PPP's async-HDLC scheme seems to be the first one that was at all widespread.

--
Grant Edwards                   grante             Yow!  Now I'm telling MISS
                                  at               PIGGY about MONEY MARKET
                               visi.com            FUNDS!

Thanks to all who replied to my original post.

. .

Just the kind of experience I was hoping to hear about, I'm curious why Modbus is so popular though with this drawback. The HDLC protocol looks interesting. I had some experience with PPP a long time ago & remember it being quite complex, perhaps unncessarily so for this application. I also thought it was point-to-point rather than point-to-multipoints but I presume more than one connection can be established over the same link. Will need to look a bit into this option.

Again, thanks for the pointers

Dave

Because Gould/Modicon sold a lot of PLCs. Those PLCs talked Modbus. So all the control system vendors implemented Modbus.

The best doesn't win. The first on that's "good enough" wins.

--
Grant Edwards                   grante             Yow!  I want a VEGETARIAN
                                  at               BURRITO to go... with
                               visi.com            EXTRA MSG!!

I completely agree.

Steve (who's done a lot of these...)

Modbus was designed for the Gould Modicon controllers aeons ago, roughly at the time of BISYNC. IMHO, the problems of easy frame recognition and protocol layer separation was not understood yet, and a minimum length coding was the ideal.

What I do not understand, is that the Modbus people succeeded on mis-designing the Modbus on TCP/IP also, by transferring clearly defined frames on TCP which destroys the frame boundaries, and requires otherwise unneeded connection build and tear-down phases to the transfer.

--

Tauno Voipio
tauno voipio (at) iki fi

After some not-so-good experiences, now I am much more cautious in reinventing a new protocol each time I need one.

I think that *robust* protocol design requires a little more thought than what many think.

What happens for example if the slave receives a correct packet, sends back ACK, but the master never receives it (for whatever reason... line noise, etc) ? Well, that's why we have timeouts. Okay, but... on timeout, master will think the packet has not been received correctly, so it will resend the message. This time also the packet arrives correctly, and the masters receives back the ACK. So, master is happy, slave is happy. But slave received TWO packets instead of the single one.

Suppose this was a "move +100 steps" command for a stepper controller... bad move.

At the very least you should implement a "sequence number" in the ACK answer. Even if you just want to send just one message at a time. A simple 0/1 bit, toggling, in the ACK is enough.

Google for "alternating bit protocol", this is one of the simplest and formally proven procotols. Some time ago someone (thanks to you, guy!) posted this link:

There you can download FREE this very good book, Gerard J. Holzmann - "Design and Validation of Computer Protocols".

Chapter 4 is very useful.

By the way... someone has a real good *robust* simple protocol done ? I need one, also :-)

Modbus ASCII does have trivial frame recognition (it looks a lot like Intel Hex format). Did Modbus ASCII come out before Modbus RTU (binary)?

That seems to be pretty typical. Most of the propietary "binary protocol on top of TCP/IP" schemes that I've had to mess with were kludges that worked most of the time, but fell down when a few packets got merged or split along the way.

--
Grant Edwards                   grante             Yow!  I feel real
                                  at               SOPHISTICATED being in
                               visi.com            FRANCE!

Never discussed in this thread, but CAN might be another protocol to go.

bit rates of 10 or 20Kbit/s should work up to 5000m, optical isolation is recommended. 8 bytes per message might be enough for your device control & status information.

Regards Heinz

Don't forget to register to the 11th intl. CAN Conference

Antonio Pasini schrieb:

Of course that method implies that only "absolute" commands are used, that can be repeated without misfunctions. That would be direct i/o status data, or absolute positioning commands for your example of a stepper motor.

With these restrictions in mind, the above is the simplest "proven" protocol (IMHO).

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

"Daveb" skrev i meddelandet news: snipped-for-privacy@p79g2000cwp.googlegroups.com...

GSM 07.10?

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB