search for header data in serial data

[lafox24]

Hi,

I'm new to LabVIEW and trying to use the serial port to search for header data to synchronise with.

I can't get the program to run without an overrun error.

Any ideas?  The program should run through three states, wait for header, size and receive data. 

Many thanks.

[crossrulz]

I haven't managed to get 2019 installed yet.  Could you please do a File->Save For Previous?  I do have 2018 installed, but 2016 in currently my preferred version (due to the programs I am working).

[Bob_Schor]

Wow -- you really need to learn some LabVIEW!  Here are some important things to learn and fix:

• In general (though your application might be an exception to this "rule"), Serial Communication usually involves receiving (and sending) Ascii Strings ending in <CR><LF>, which "works best" when Configure VISA is left in its default "Use Termination Character", with <LF> (0xA) as the default.  Your VISA Read then asks for 1000 characters, terminating when it gets the <LF>.
• Learn about Queues (or better, don't learn about, and don't try to use Queues, until you know a lot more about LabVIEW).  Why you would wire the data you might get from your VISA Read into the name input for Create Queue is beyond my comprehension.
• The Queue runs directly from Obtain Queue to Dequeue Element.  As the Queue is initially empty, Dequeue Element will never "fire", and your While loop will never do anything.

Here's what you want to do:

1. Understand your VISA Device.  Important questions are the following:  Is it sending data as Ascii Strings (terminated with <LF>), or is it a really old device that sends binary data, such as 12-bit signed (or unsigned) integers packed four per 3 U16 LabVIEW numbers?
2. If Ascii, then you want to use the suggestions in the first Bullet Point, above.  There have been lots of Posts in the Forum about reading from VISA, many showing examples of the "correct" way to use the Termination character, specifying a Big Read (I like to use 1024 character reads because I Like Binary).
3. If Binary data, understand enough about your device to recognize its "Start of Packet" signal, that is, the unique quantity it sends to say "The Data Start here".  Read single U8s or U16s until you find this "Start" element, then read the rest of the packet, assemble it, and parse it according to the Manual.

You should not need a Queue for any of this.  You don't appear to have any understanding of how Queues work and when you should use them.  Learn Basic LabVIEW first, then get fancy.

Bob Schor

[lafox24]

Here you go, I have saved as version 16.

[crossrulz · Accepted solution]

Well, at least you are better off than many of the serial port help requests I see around here.  You at least know you have a binary format for your data and you know the format of the message.  How often does your device send out data?  Or do you have to request it in order to get a response?

So the first thing you did right was turn OFF the Termination Character.  However, it all goes down hill from there.  You need to be reading inside of the loop.  What I do in this situation is read 1 byte and see if it matches your sync byte.  If it does, then you can read the length byte(s) and use that value to read the rest of the message.  No real need for a state machine here.

If you want to take this further, you really should be using a queue to pass the data from this loop to another loop running in parallel for processing.  Keep this loop strictly to the instrument IO.

[lafox24]

Thanks, that seems a much simpler solution, now I get the following error:

Error 74 occurred at Unflatten From String.

Possible reason(s):

LabVIEW: (Hex 0x4A) Memory or data structure corrupt.

Any ideas why this would happen?

[crossrulz]

---

@lafox24 wrote:

Thanks, that seems a much simpler solution, now I get the following error:

Error 74 occurred at Unflatten From String.

Possible reason(s):

LabVIEW: (Hex 0x4A) Memory or data structure corrupt.

Any ideas why this would happen?

---

Did you change that numeric constant to a U8?  If you left it as an I32 (the default), you will get that error since it expects 4 bytes instead of 1.