LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need help understanding VISA VI's buffering.

Solved!
Go to solution

Hello Reader,

 

I have a 3rd party FPGA board that is sending data over UART and I am reading the data using VISA VIs. As of now, I just have a simple test VI that seems to receive data without any issues at 2M Baud.

UART_VISA.png

 

In the final application, FPGA is collecting packets of 25 bytes every 133.75 micro seconds. Total number of samples will be 25 Bytes x 4096 = 102,400 Bytes, so required data should be collected by FPGA every 0.54784 seconds.

As of now, there is no buffering on the FPGA side, FPGA is sending data out every 133.75 micro seconds over UART. Now, I know that PC cannot deterministically operate at this fast speed, but the option of 2M Baud with buffering gives me a hope that there is something working the background which can support this high speed transfer with a buffer on PC side, similar to DMA FIFOs.

 

EDIT: I am imagining that VISA will collect these 25 byte packets, buffer them (I should use 2x or 4x buffer of 102400 as buffer size) and then I will use "byte count" option and set it to 102400 to read them all at once in about every ~.6 seconds.

Xonmyth_0-1734970845516.png

 

 

Xonmyth_1-1734966348486.png

1) Is my understanding correct or close? I would really want to avoid buffering of 102400 bytes on FPGA side due to resource limitation, I do have double buffering of 25 bytes packets.
2) Can I rely on VISA's buffering and except a lossless communication?
3) Any cautions, warnings, suggestions or recommendations for my application?

Thanking you for your time.

X

0 Kudos
Message 1 of 7
(280 Views)
Solution
Accepted by topic author Xonmyth

I'm not sure if there is a limit to how large of a buffer VISA will allow you to have. That is something I would need to dig around to see if I can find anything on it. Personally, I would have a loop that did nothing but read from that port and send the data through a queue to a processing loop. The queue size, something that is a lot easier to understand, would then be your limiting factor. There should be no wait at all in that loop as it will be trying to keep up with the data stream.


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
(204 Views)

Hello crossrulz,

 

Thank you so much for your reply.

As you pointed out about the buffer size, I did some looking around myself but did not find any clear information.

Source_LV_Forum_From_2002Says "Windows does not specify a maximum size but I've seen requests for buffers greater than 32KB fail." If I go by this, I should be fine with 1x or even 2x buffer. That would at least keep reading data loop time around ~.6 seconds. I will also experiment and share my findings here once I am at that point.

 

I will take your suggestions for designated read loop and queuing implementation.

Any other word of caution?

0 Kudos
Message 3 of 7
(182 Views)

The only thing I can think of is to make sure your baud rates match.  That's the main thing.  Everything else is taken care of under the hood.  Setting it up as  suggests should make things quite easy - provided you set it up properly, which I think , you have something to say about that, right?  Or something to show?

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.
Message 4 of 7
(171 Views)

Hello billko,

 

Thank you for the reply. Okay, understood, I will make sure that the buad matches. Good thing is, I control baud on both the sides (maybe it is a scary thing haha).

I will wait to see if crossrulz has anything to add.

 

Best

X

0 Kudos
Message 5 of 7
(167 Views)

@billko wrote:

...which I think , you have something to say about that, right?  Or something to show?


What are you trying to imply? You think I might have a video on proper serial communications or something?

 

The main thing for the OP to worry about is the messaging protocol being used. It sounds like a streaming protocol, most likely binary due to the heavy amount of data being passed. So the OP needs to make sure there is a clear synchronization before the stream starts or have framing messages to ensure data is being interpreted correctly.


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 7
(97 Views)

I did it!! ヾ(⌐■_■)/

 

Thank you crossrulz and billko.

I am reading 26*4096 (106,496) bytes every ~ second. VISA node supported a buffer size of 4x 106,496 (425984) Bytes. Implemented a state machine. Everything is working just as needed.

Message 7 of 7
(44 Views)