Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Missed bytes in VISA communication

Solved!
Go to solution

Hi,

 

I created two programs with labview which communicate together using virtual COM ports that are connected properly.

The first program sends a paquet containing an integer n to the second program which would return n paquets containing 9 bytes, between every two consecutive paquets there is a pause.

When I set the baudrate to 500 or 700 for both programs and for n=360 , they work properly and no byte is missed. 

The problem is when I change the baudrate to 1000 and higher , for both programs, and n is still equal to 360 , there are some seperated bytes missed ( between 0 and 3 bytes in general).

So what do you think the source of problem is ?

It can't be the buffer size because it's set to 64399599 ( no kidding , it is the maximum size allowed). Besides , I used the both programs for another purpose where the first one received from the second 1000 * 9 bytes for n times ( there are a period of pause between two consecutive times of sending of 9000 bytes).

 

On the other hand , I checked what the second program sends by looking at the return count output of the VISA write, and by trying to send these paquets to hyperTerminal. And there are no lost paquet ( even for a baudrate of 9600).

 

So I suppose the problem is in the read part.

 

If somebody would help me I would be very grateful.

0 Kudos
Message 1 of 7
(4,866 Views)

My very first thought is that you are using the Bytes At Port to tell the VISA Read how many bytes to read.  This can lead to some interesting race conditions like what you are describing.  Instead, you should tell the VISA Read to actually read the number of bytes you expect in a packet of data.

 

But without seeing code, all we can do is guess.


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 2 of 7
(4,858 Views)

I see , ok I'll try this, by the way this is the code.

0 Kudos
Message 3 of 7
(4,853 Views)

Yep, the Bytes At Port will be your problem.

 

By the way, there is no need for the Value property nodes or the sequence structure.  Use actual data flow instead.


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 7
(4,839 Views)

Also, your code is looking too complicated.  You might want to set something up like this

NOTE: the "0" case has a wait in it to keep the CPU from burning up.

 

This code was based on having a termination character.  Since it sounds like you do not have a termination character in your protocol, just change that 50 to be the number of bytes you expect in a packet.


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 5 of 7
(4,836 Views)

The problem is solved, actually I tried to read bytes like you suggested but I found my data with redundant paquets.

I found also that in both methods , the number of bytes read is exactly how many bytes I need to read, so the problem is not about the method of reading.

So I put the reception of bytes in a flat sequence structure , and I added a frame after it containing the extraction of data, and the calculations. And the result was good and was exactly what I wanted.

So to conclude , the problem was inexplicable for me since the reading was good , but the result of extraction of data isn't predictable or logic , the problem was about the parallelism of reading and treatement of data. sometimes it wroks right , sometimes it doesn't. And for sure the problem wasn't about the method of extraction of data because it waits until the table of read bytes contains at least 9 bytes , and it extracts those bytes and delete them from that table.

Perhaps because the two thread are working on the same table. I'm beginner on Labview so any suggestion about thread examples in Labview is welcome. ( I guess mutual exclusion is needed here )

0 Kudos
Message 6 of 7
(4,776 Views)
Solution
Accepted by topic author EL91

I tried with semaphores and it is working properly , thank you  crossrulz ! 

0 Kudos
Message 7 of 7
(4,766 Views)