07-10-2014 02:33 AM
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.
This the serial read vi
This is the Serial Port Setup
07-10-2014 02:41 AM
07-10-2014 02:45 AM
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.
07-10-2014 01:36 PM
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.
07-10-2014 01:46 PM
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.
07-10-2014 02:01 PM
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.
07-10-2014 02:37 PM
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.
07-10-2014 03:38 PM
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.
07-10-2014 04:39 PM
I would try a real COM port and see if you have the same issue. I've heard of issues with the FTDI drivers.
07-10-2014 04:55 PM
FTDI can have troubles but are usually not that bad. Prolific hower .....!!!!!