LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Intermittent Extra Serial Byte in Visa Read

Hello All,

 

I'm hoping you can help me with a problem that I've been having. The background:

 

Using a microcontroller to to gather data from various sources and sending all the data back to Labview via an FTDI virtual COM port. The different types of data sent back in one chunk has a three byte header that tells me (in an abstract way) how many bytes are following for that type of data. This repeats until all the data sources are exhausted and all the data is received. However, occasionally, there is an extra byte in the buffer, which then pushes the headers out of whack and has me looking for bytes that aren't there. I'm attaching screen shots of the serial port config and of the serial port read vi's. I've tried flushing the buffer before I do a data acquisition and ask for data, but sometimes the extra byte happens inside data stream, so again it pushes the headers out of place.

 

I have a secondary COM port output on the microcontroller that echoes the data being sent to Labview and is connected to a second PC that is capturing the data. The data is in binary format. I have disabled the termination character requirement from the receive buffer, but enabled it for the transmit (as you should see from the setup). When I review the logs of the captured data on the second PC, the microcontroller is not sending the extra byte. It appears that even though Labview reads the byte from the buffer, it remains there SOMEHOW or I could be way off and it's a bug in my code. I'm hoping that you can help with perhaps seeing something that I'm not seeing.

 

As for my serial buffer read, I do recognize that I don't have a timeout in the event that the number of bytes to read exceeds the total bytes in the buffer, this has actually been beneficial in helping with capturing the error as it happens. I didn't use the Bytes at the Port property because speed is important and this property is notoriously slow. Also, that really wouldn't solve the extra byte problem.

get data.png

This the serial read vi

 

Serial Port Setup.png

This is the Serial Port Setup

Download All
0 Kudos
Message 1 of 11
(4,195 Views)

Hi teeji,

 

do you mind to attach unscaled images?

 

Well, don't initialize the port in each iteration…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 11
(4,188 Views)

Hey GerdW,

 

The attachments are not scaled. The ones inline are.

 

The initialization only happens once when the program starts. There is of course a close VISA session vi used later, when I'm done with the test.

0 Kudos
Message 3 of 11
(4,182 Views)

teejimenez wrote:

 

The initialization only happens once when the program starts. There is of course a close VISA session vi used later, when I'm done with the test.


No! The Initialize Serial Port is inside the loop and executeded on every loop iteration.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 11
(4,126 Views)

Hey Rolf,

 

Yes, I see what you're saying. However, what I'm doing in that block is trying to find which port the device is connected. So, I read through the registry to find out the possible ports the ucontroller could be on, setup the port, then try connecting to the ucontroller. We have several ucontrollers around and since they are on virtual COM ports, the ports tend to change. It's an easy way of determining which port the micro is on. Do you see any errors in the setup of the port though?

 

And thanks for the tip.

0 Kudos
Message 5 of 11
(4,117 Views)

Virtual COM ports! Check the driver! Issues like what you see are most likely caused by the Virtual COM port driver for your hardware. Generally Virtual COM port drivers are of poor quality and less than suitable for industrial quality applications.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 6 of 11
(4,109 Views)

Well you could certainly simplify things by using a Termination Character. I see you are enabling it in your serial setup. But I do not see where you define what the character is. Define one and make sure you put one at the end of the data your device is isending if it is not already.

 

Then when you read, set the byte count higher than the number of bytes you expect to read and read until you receive the term char or timeout.

 

Then parse the data. 

 

You might also try clearing the buffer befor you request data.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 7 of 11
(4,091 Views)

RTSLVU,

 

That would be ideal, except that that nature of the data means that literally any 2 byte character combination could come back as data and therefore be a false terminating character. I tried changing the Enable Term Char value to false in my above diagram and will start running now. Unfortunately, the issue is VERY intermittent.

 

Thanks again for the help.

0 Kudos
Message 8 of 11
(4,081 Views)

I would try a real COM port and see if you have the same issue.  I've heard of issues with the FTDI drivers.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 11
(4,068 Views)

FTDI can have troubles but are usually not that bad. Prolific hower .....!!!!!

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 10 of 11
(4,062 Views)