LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA USB RAW Buffering

Solved!
Go to solution

Greetings,

 

I have a USB device I need to communicate with using Labview. There are no drivers for this device so I've set it up as a VISA USB RAW device. I'm able to communicate with it fine, for the most part, but I'm having issues with lost data.

 

This device streams data to the host at a relatively high rate (~1MByte/sec) and I've got 3 of them that I need to get data from continuously. Data is sent in 512 bytes packets. When calling VISA Read I specify the amount of data I want to read from the device (e.g. 512,000 bytes for about 0.5 seconds of data) and that data is received without a problem from all 3 devices.

 

My problem is that it takes a short bit of time to do anything with the data that I've just read and the next time I do another VISA Read I've lost the data that should have appeared while I was handling the data from the previous read. I've streamlined my Labview code so that all it does with the data is parse a few bytes and stick the rest in a queue to be processed in a separate while loop, but even this little bit of processing takes a few milliseconds. That few milliseconds of data is lost when I do the next VISA Read.

 

I think the problem is that USB transfers have to be initiated by the host, meaning any buffering needs to be done in the device itself, and that this device doesn't do any buffering. Is this correct? Are there any tricks I can use to do "continuous reads" from a VISA USB device?

 

I might be able to shorten the processing time a bit more by not doing ANY analysis on the data, just read it and stick it in the queue, but even doing that is probably going to take long enough that I'll miss a few data packets (each packet is less than 500us of data).

 

Thanks for any suggestions.

 

Dave

 

0 Kudos
Message 1 of 8
(3,057 Views)
Solution
Accepted by topic author Jabson

You can have multiple USB reads working in parallel feeding the data into a notifier.  Then handle the notifier data later in your code.

 

I have done this with HID calls before so that no HID updates were missed.

 

Shane.

Message 2 of 8
(3,034 Views)

@Intaris wrote:

You can have multiple USB reads working in parallel feeding the data into a notifier.  Then handle the notifier data later in your code.

 

I have done this with HID calls before so that no HID updates were missed.

 

Shane.


Hi Shane,

 

I'm intrigued, but I don't think I fully understand. Are you saying I can have two VISA Reads running in parallel loops reading from the same device, using a notifier to ping-pong between them so that one is reading while the other loop is processing/waiting?

 

Do you have a code snippet you wouldn't mind sharing?

 

Thanks,

 

Dave

 

 

0 Kudos
Message 3 of 8
(3,025 Views)

Yes, two (or even more) reads in parallel, in independent loops using the same VISA reference writing to the same notifier.

 

Use this notifier in a different independent loop to do your processing.  Bear in mind that if your processing takes longer than the 500us, you will have a backlog and not all of your data will be processed (Your notifier will end up overwriting old data).

 

I'm currently not at a LV-enabled PC....

 

Shane.

0 Kudos
Message 4 of 8
(3,023 Views)

@Intaris wrote:

Yes, two (or even more) reads in parallel, in independent loops using the same VISA reference writing to the same notifier.

 

Use this notifier in a different independent loop to do your processing.  Bear in mind that if your processing takes longer than the 500us, you will have a backlog and not all of your data will be processed (Your notifier will end up overwriting old data).

 

I'm currently not at a LV-enabled PC....

 

Shane.


I think the part I'm not quite getting is how the independent loops reading the data are synchronized with each other. They can't both be calling VISA Read simultaneously, can they? Doesn't one loop have to wait until the other is done before it calls VISA Read? Is that synchronization done using the same notifier?

 

Dave

 

0 Kudos
Message 5 of 8
(3,019 Views)

Just leave them run.  A USB packet is normally sent atomically.  Only one of the reads can return the packet which means they'll simply take turns.

 

No extra synchronisation required AFAIK.

 

Try it.

 

Shane.

0 Kudos
Message 6 of 8
(3,016 Views)

@Intaris wrote:

Just leave them run.  A USB packet is normally sent atomically.  Only one of the reads can return the packet which means they'll simply take turns.

 

No extra synchronisation required AFAIK.

 

Try it.

 

Shane.


Thanks for the tips. I won't be able to try it until next week but it sounds like it should work.

 

Follow-up question: I normally don't read 1 packet at a time, I set the size parameter to VISA Read to about 1000 packets worth of data. Any idea whether I can still use the parallel VISA Reads and get a series of consecutive packets from each?

 

0 Kudos
Message 7 of 8
(2,998 Views)

Just wanted to close this thread out. I finally got around to trying your suggestion and it works like a charm. Thanks again!

 

0 Kudos
Message 8 of 8
(2,945 Views)