unexplained spikes on waveform graph - values read from visa

[lolasue]

I am reading sensor data from a serial port through visa. I chop up the data, convert it from string to decimal and feed it directly into waveform (vi attached). In the waveform graph, however, there are spikes in the values where the values intermittently hit zero or close to it. This is evident in the attached screen shot. 

I had thought that it was down to voltage spikes in my sensor device but a colleague of mine has used the same vi for his data (slightly modified), and has the same problem. I now believe it is something in my vi which is the problem.

I would appreciate any assistance in troubleshooting this vi. I am relatively new to Labview.

[RavensFan]

Why are you using "Bytes at Port"?  YOur wait is only 10 msec, so my guess is that you are frequently getting short messages and when you can't parse out a particular value, you are getting the default of zero at Decimal string to number.

Does your device use a termination character such as carriage return or line feed?  Your VISA configure is set up by default to use a termination character of a line feed.  Take advantage of that.  Get rid of bytes at port and wire a number into VISA Read that is larger than the longest message you ever expect to get.

If you can provide what a typical message string lookes like, I get it would be possible to parse out the data using a Scan from String function and not need all the functions you have inside your loop.

[Wolleee]

Couple of questions;

1. is the data streaming?

2. does the data have a termination character?

3. do you know the protocal for the data?

One thing that could be a problem is that you are reading the bytes at port and then performing a read with that number of bytes at port. This could be bad if you were waiting for 20 bytes, but only 10 bytes were at the port when you performed that function. 

You should NEVER wire the bytes at port to the number of byte to read in the visa read.

[lolasue]

I have attached a screenshot of the data that comes in. The data is coming from a device which has numerous sensors, TR1 = thermistor 1, TR2 = thermistor 2, W = water sensor. The number between TR2 and TR2 is the value of interest, eg TR1  345  TR1, W  113  W etc. Once I activate the device I measure the data from all sensors continuously in real time.

You both mention 'Bytes at Port' and question why I am using it. The answer is that I dont know. Ive built this vi up from examples and tutorials etc. I don't know how/what to change this element to.... Do I just remove the wire from Bytes at Port?   Help/explanation would be much appreciated. Thanks

[lolasue]

Sorry, didnt attach the correct doc in previous reply.

[RavensFan]

That is an unusual terminal program and how they are displaying Nul, Cr, and LF has single characters in the stream.

I see some ASCII based data in there that is easy to read.  Also, it looks like some semi-binary data int there.  What is happening with all the 2 digit numbers separated by nulls?

It is also odd that sometimes the data has carriage returns separating lines, and sometimes is has carriage returns and line feeds.  What is this device and who makes it?  Did they give any kind of decent communications manual to help yo figure out what the jumble of data means?

Do the things you have circled in red have any relations ship to the digits and text that are displayed above it up to the previous line feed character?  Do you care about any of the things you don't have circled in red?

I would use a line feed character as the termination character.  Read 1000 bytes on every VISA Read.  At that point every time you read  you should have all the  data from what follows the previous red box, up to and including the next red box.

I would use scan from string to find the first TR  Determine whether the next digit is 2, 3, 4, 5, .... and also find the numeric value that follow it before the next TR.  Now use that first digit to drive a case structure that determines which indicator to put the numeric value into.

I would consider learning regular expressions, also know as Regex as it can be vary powerful to help you parse out complicated data streams.

[lolasue]

Hi RavensFan,

I see some ASCII based data in there that is easy to read.  Also, it looks like some semi-binary data int there.  What is happening with all the 2 digit numbers separated by nulls? I ignore everything except the data values (between sensor titles)  and the sensor titles. eg TR1 456 TR1. Using string subset I 'chop off' any data before TR1. Then I use match pattern to separate each sensor data to different waveforms. 

It is also odd that sometimes the data has carriage returns separating lines, and sometimes is has carriage returns and line feeds.  What is this device and who makes it?  Did they give any kind of decent communications manual to help yo figure out what the jumble of data means? I am a PhD student and another student made this device for me by combining some sensors on a pcb with a WICED microcontroller. The only manual is the SDK user manual.

Do the things you have circled in red have any relations ship to the digits and text that are displayed above it up to the previous line feed character?  No. Do you care about any of the things you don't have circled in red? No

I would use a line feed character as the termination character.  Read 1000 bytes on every VISA Read.  At that point every time you read  you should have all the  data from what follows the previous red box, up to and including the next red box. Which line feed character do I use?

I would use scan from string to find the first TR  Determine whether the next digit is 2, 3, 4, 5, .... and also find the numeric value that follow it before the next TR.  Now use that first digit to drive a case structure that determines which indicator to put the numeric value into. Similar enough to what I have done but i used Match pattern instead?

I would consider learning regular expressions, also know as Regex as it can be vary powerful to help you parse out complicated data streams. Ok, Thanks

[lolasue]

@ RavensFan,

Why are you using "Bytes at Port"?  YOur wait is only 10 msec, so my guess is that you are frequently getting short messages and when you can't parse out a particular value, you are getting the default of zero at Decimal string to number.  I'm pretty sure that this is whats happening. But the spikes dont always go to exactly zero. If so it would be quite easy to filter out. Sometimes they are arbitrary spikes whose values make no sense. 

[RTSLVU]

---

@lolasue wrote:

@ RavensFan,

Why are you using "Bytes at Port"?  YOur wait is only 10 msec, so my guess is that you are frequently getting short messages and when you can't parse out a particular value, you are getting the default of zero at Decimal string to number.  I'm pretty sure that this is whats happening. But the spikes dont always go to exactly zero. If so it would be quite easy to filter out. Sometimes they are arbitrary spikes whose values make no sense. 

---

Because you are using "bytes at port" you are often reading bad data and getting bad results. 

It's kind of pointless to argue about how bad the bad data is.

[lolasue]

I still dont know how to replace 'Bytes at port' with the alternative/correct solution? Looking up manuals and tutorials here but getting nowhere. I have deleted the wire from Bytes at port but my vi shows up as incomplete to run. Any suggestion?