LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Losing data using VISA Read

So I'm newbie in LabView and I'm trying to get some measurements data from ADC. I made simple VI which demonstrates my problems. I lowered Baudrate to 800 to catch the problem. So i have meander signal, ADC simply send me "0\n" on LOW and "5\n" on HIGH - 2 bytes each. So 800 Baud it's 800 bit/sec = 100 byte/sec = 50 messages "0\n" or "5\n".

I make 2 test signals:

1. 25 Hz. All was fine. Look at first pic. U can see 25 periods in 1 sec (50 time points)

2. 1 Hz. Here i'm loosing about 20% of data. I can't understand why and how. On the second pic you can see than we have 20% more than 1 period in 1 sec (50 time points). I tried save data and i had 41 data point in 1 period! 20% lost. Frequecy exactly 1Hz. Even if i count on Waveform Chart during 60-100 seconds i got right frequency! But some data is lost.

 

I tested it with different cases. And when Signal frequensy much lower than Baud rate (messages rate) i have almost exactly 20% lost data. 1 Hz, 10Hz or 1kHz. Always about 20% lost.

 

So why this happens? It's problem with Baud rate? Or it's because i made some mistake? But i simplify my program to just VISA read example. What's the problem?

Download All
0 Kudos
Message 1 of 10
(3,820 Views)

Its possible that youre reading during a write from the device or just missing data because you have it setup to read no matter what at the timeout if there is no data.  I see you have a CR for termination char so set the port up to read until the termination character and maybe have a shorter timeout.  I placed the bytes at port node in the example, ive heard mixed reviews about using it, but ive never really had a problem with it.  let me know if this helps.



-Matt
0 Kudos
Message 2 of 10
(3,801 Views)

Same problem. 1st of all "\n" - 10, it's not "\r" - 13. Case structure didn't help. I'm not writing on port.

I look at 25Hz test signal and can't understand. It's perfect. But it's 20% shorter too! Where I'm loosing 20% data? May be it's math problem? 800 Baud -> 50 2byte-messages? What's wrong?

0 Kudos
Message 3 of 10
(3,781 Views)

@Iluso wrote:

So 800 Baud it's 800 bit/sec = 100 byte/sec = 50 messages "0\n" or "5\n".


1. 800 buad is extremely slow.  I'm used to seeing more like 9600 baud minimum (12x faster than you are doing).

2. Do not forget that there are Start and Stop bits as well.  So each byte is actually 10 bits.  So it is really 40 messages/second assuming no gap between the messages.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 10
(3,777 Views)

Don't use "bytes at port" as Matt suggests.  For 95% of real applications, it isn't helpful and causes more problems.  Use the termination character, and set it to read more bytes than you ever expect to get in a message.

 

Are you sure your sending device is sending the data at a fast enough rate?

Try adding some clock tick function to your loop and monitor how fast your loop is actually iterating.

0 Kudos
Message 5 of 10
(3,767 Views)

@RavensFan wrote:

Don't use "bytes at port" as Matt suggests.  For 95% of real applications, it isn't helpful and causes more problems.


Let me thow out some more specifics here.  When connected to an instrument/device that streams data (constantly sending it at a specific rate), the Bytes At Port helps none at all.  The only time I actually find the Bytes At Port useful is with instruments/devices that send data intermittently (send data when something happens or whenever it decides to send something).  Since we are dealing with a streaming device, the Bytes At Port should not be used.  Let the timeout detect that data is no longer coming and let the termination character end the valid read.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 10
(3,755 Views)

Hi Crossrulz,

 

I actually just started another thread so i could get that answered Smiley Very Happy but you already did that. Thats also why i almost never see any problems with it.  Most the time im reading from hardware that spits out informaiton infrequently. 

 

Also your math seems pretty sound regarding the baud rate.  If you dont account for start and stop bits you get 50 messages per second, but with start and stop bits it will only be 40.

 

Appreciate the response



-Matt
0 Kudos
Message 7 of 10
(3,747 Views)

The problem with streaming data that comes infrequently is that the bytes at port may not reflect the entire message.

 

Let's say your device is sending 30 bytes, but only 20 have arrived at the instant your program checks the bytes at port.  You'll get 20,  read 20, and don't have the remaining 10.  They'll arrive after your read, or maybe in the time between the bytes at port check and the VISA read, but either way those remaining 10 bytes will be sitting in your serial port buffer until you get around to checking the bytes at port and reading again.

0 Kudos
Message 8 of 10
(3,744 Views)

These are "Standard" Baud rates:

 

300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 38400, 57600, or 115200

 

800 isn't one of them. Can you switch to either 600 or 1200?  It could be that the actual hardware can't do 800 and needs to use a standard one.

0 Kudos
Message 9 of 10
(3,735 Views)

Ravensfan,

 

In regards to the question in this thread i agree that the bytes at port would be redundent, because the data is streaming and has a termination character. Without a termination character or a determined protocol there would be lost data when using the bytes at port.

 

Thank you.

 

 

 



-Matt
0 Kudos
Message 10 of 10
(3,732 Views)