Serial Communication Protocol

[Nexus]

Hi,

Does someone have an example how to setup a VI that is capable of handling data from/to the serial port using a "custom defined" communication protocol?

I do have a specification on datalink level and want to convert into a VI.

Thanks in advance.

Nexus

[Louis Manfredi]

Hi Nexus:

I've done a fair amount of messing around with serial ports, as have many others in the forum.

Much of my work has been with byte stuffed protocols for eight bit data transmission & also with tricks to bypass Windows so I can get better timing control on outbound trigger messages.

Others in the forum can probably help better with other kinds of comm. protocols & issues.

Tell us a little more about your application, and I'm sure the right person will jump in.

Best Regards & good luck, Louis

[Nexus]

Louis Manfredi:

The communication protocol consists of two layers:

- The datalink. The datalink handles exchanging of messages between the modules in the system.

- The application layer. On application level the actual exchange of data takes place. To make this possible several commands are defined.

To make it easy to connect a PC, the system uses a standard baudrate (19200 baud) and 8 bits per data byte. It is possible to use other baudrates.

Datalink

The protocol is a binary protocol. Each message starts with a DLE character, followed by a function byte. The function byte contains the message type and contains other information dependent on the message type.

The following figure shows an example of a message type (Request) the datalink of the protocol uses. (Total 5 different messages are used).

--------------------------------------------

| DLE | type | length | data | CRC |

--------------------------------------------

type = bits 5 -7 destination address, bit 4 reserved (0), bits 0 - 3 type 0001

length = bits 5 - 7 source address, bit 4 reservedd (0), bits 0 - 3 message length minus 1

With a request a module can send data to or request data from another module. This module should respond on the request with a response message or with a status message if an error occurred.

If there is no response within a time-out of 224 ms or an error is returned by the receiver of the request, the sender of the request sends a token to the next node. If it receives a token with its own address again, it sends the request again. This repeats until either a response message is received or the maximum number of retries is reached. If the number of retries is reached an error is returned to the application.

I do have a flowchart of the datalink but this would be to much to use this here.

Maybe you can give me a clue how to setup a VI which handles the datalink with a simple datalink protocol.

Thank you.

Nexus

[Louis Manfredi]

Hi Nexus:

The attached zip file contains some vi's for a different communications protocol you might find useful as a clue.

I think I've included enough for you to see the drift of things, let me know if the vi's arrive broken arrow or otherwise unusable.

They are provided as-is and with no warranty or guarantee of anything.

Download File:post-1144-1112373848.zip

They were designed for a slightly different communications protocol: Variable message length, eight bit data. Shared comm. channel for multiple units with differing addresses.

Every message is of the form:

<DLE><STX><MESSAGE BODY><DLE><ETX><CHECKSUM>.

Typically, <MESSAGE BODY> contains <ADDRESS BYTE><MESSAGE TYPE BYTE>[<DATA BYTE(S)>]

If <MESSAGE BODY> contains an embedded <DLE> it is replaced with <DLE><DLE> (byte stuffed) so it isn't confused with the beginning or end of a message.

Although different from your protocol, the examples should provide some help. Pointers to note:

1. Both my knowledge, and Labview itself, have progressed since these were written, there are some stylistic faults (use of globals, etc.) which are out of style now (or always were), but I haven't bothered to change them since the routines work for me.

2. The message receiver is a state machine. Building error-tolerant communications receivers are good examples of a place where a state-machine architecture is a really helpful approach. (Some Programmers will claim that everything should be done with state machines-- I'm not so sure, but this is a pretty clear-cut case where it is useful.)

3. Best to use single message transmitter and receiver vi's, called from all the places where the program communicates with the remote thingies-- That way you can keep track of port use & don't end up using the port for two different messages at once. If messages are short, and timing isn't super critical, make a single vi that calls the transmitter, waits for the response, then calls the receiver. Make it non-reentrant. Might not be most efficient use of time, but saves all kinds of headaches with sending two messages and getting two (scrambled) responses.

4. Generally, only need to call the initialize routine once, when you boot your program.

5. Seems like there's about a billion different CRC routines out there--- Myself and a number of other forum members have posted lots of information on some of them in a forum thread that should show up under a search.

Hope this is at least a bit of a help, feel free to ask more questions if the examples aren't clear.

Best Regards, Louis

[Nexus]

Hi Louis:

I believe the examples will help me a lot!

Also the state machine approach is very usable in this case.

I also found the CRC threads and also these can help me further!

Thank you for your spontaneous assistance!

Kind regards,

Nexus.