LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Pulling serial data from Arduino, running into problems

Solved!
Go to solution

I'm very new to Labview and I'm looking for some insight into an error here.

 

I have an Arduino running some very simple code that pulls some measurements off of a pair of devices and stores the latest values. When sent a query from my Labview VI it responds with the requested data, pressure data for a '1' and flow data for a '2'. I need to make sure that I first request data, then wait for the whole 4 byte float to arrive before reading and plotting.

 

Right now I have the block diagram organized by having the Serial write function send the query, then I sit in a while loop delaying until 4 bytes of data have arrived before reading the data, processing, and graphing. I do this twice per loop, once for the flow data and once for pressure.

 

The problem I have is that unless I add a significant delay into the "wait for data arrived" loops (wait for at least 10-20 ms) I sometimes get a zero being sent to the graph. I'm assuming that the read function is trying to read before the arduino has actually responded, but I'm not sure why adding a delay into those loops is necessary, or why it needs to be so long. Honestly I'm not at all sure the way I'm doing it is right at all, and I'd really appreciate any correction or advice from someone who actually knows what's going on.

 

I'm not allowed to attach .ino files but I can give the arduino code if needed.

0 Kudos
Message 1 of 7
(234 Views)
Highlighted
Solution
Accepted by topic author Tarnarmour

Hi Tarnarmour,

when do people learn to NOT use BytesAtPort?

 

Simplified:

Are you sure you receive exactly 4 bytes from your Arduino? Then you should NOT use ConvertStringToFloat, but DeserialiseString (with its option to set byte order as needed)!

When receiving "binary" data you should also TURN OFF the TermChar…

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 2 of 7
(225 Views)
Highlighted
Solution
Accepted by topic author Tarnarmour

A generally suggested alternative to what you're doing would be to use Termination Characters, a large number of "Bytes to Read" >> length (4), and then a long(ish) timout.

 

The typical termination characters would be CR or LF (Carriage Return, Line Feed), and you can use Serial.println(myValue) on Arduino to append a CR/LF pair automatically (LF is the default Term Char in LabVIEW's VISA Configure Serial Port).

Take care to handle the extra CR that appears on the end (consider e.g. Trim Whitespace or similar).

 

Then you don't need to handle the waiting, the polling or the missing messages - everything becomes simpler.

 

See also Crossrulz's presentation from VI Week about this (and similar topics): Proper way to communicate over serial.


GCentral
Message 3 of 7
(221 Views)
Highlighted

As a separate problem, I'm also seeing your inner loops using "Bytes at Port" != 4 as the stop condition. That presumably isn't what you want... (although as already mentioned, there are better approaches than using Bytes At Port, especially if you control both ends of the communication (Arduino + LabVIEW code)).

cbutcher_0-1600188277444.png

 


GCentral
0 Kudos
Message 4 of 7
(216 Views)
Highlighted

@GerdW wrote:

when do people learn to NOT use BytesAtPort?


Probably when NI fixes their examples...but that is a fight I have had for a long time.  That was one of my reasons for the VI Week presentation (VIWeek 2020/Proper way to communicate over serial).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 5 of 7
(204 Views)
Highlighted

Wow, thanks a ton. That looks so much nicer than what I had. This is just what I was worried about, I was doing this in some horribly over-complicated and bad way. Ah well, that's learning I suppose. Thanks again for the swift reply, I really haven't loved the tutorials or docs by NI so far but this forum seems like it more than makes up for it.

0 Kudos
Message 6 of 7
(181 Views)
Highlighted

Well this is a very timely video to discover, much appreciated

0 Kudos
Message 7 of 7
(180 Views)