Serial Packets: how to receive them correctly

[Mark_Yedinak]

Are you reading and decoding the header? Are you sure that all of your messages are the same length. First and foremost I would read the header only and use the length provided to read the rest of the data. When reading the header you can verify you have valid data by verifying the first two bytes are 0xA5 0x09. The read the length value followed by a read of teh length you just read. If your header is not valid begin reading the data and search through it to find the first valid header. Discard any data up to that point. Once you have your header begin processing the packets again.

[lesher]

If there's no term char or EOF Byte that doesn't show up in the data, and if the length is variable (which I understand is not the case, here), or if the data drops, then this state machine works well. To use the data, I put a case statement in the first state. "Good packet" in a shift register sends the complete packet to another queue. I can add a picture in a few hours.

[nickpuy]

Thanks lesher the picture will be of great help!

thanks!

[Coq_Rouge]

This is a crude example on how to do it from the top of my head. Using state machine structure. It should work I hope. Use it as a template as it only show the principles. I have omitted error control on many places. That task I leave to you. If no instrument is present the app will appear to hang. Also the synch part should be made in a sub VI. So it stil a lot of work to do 😉

[Todd_Lesher]

I love queues! But I love reusable code more. Oh, and flexible code. The attached method (LV10, as OP mentioned) is how I typically handle these. It allows for simple Bytes-per-second information, as well as knowledge of exactly which Bytes may have been dropped, and counting packet types.

Granted, it is overkill for a single-function device with fixed-length transmission.