Why is Labview 7 VISA so slow?

[SteveD6722]

I have been using the "old" serial read/writes with no trouble but with Labview 7 they don'r work. When I rewrite them to visa style VI's it takes 2 to 3 times as much time to exicute. Is there anyway to still get the "old" style read writes to work or speed up the "new improved VISA" so it isn't so slow?

[Dan_Mondrik]

Steve:

Although our benchmarking didn't show a very significant slowdown in VISA Serial, we are working to improve the performance of that component in the next release.

Can you provide more specific benchmark data? Is the bottleneck with writes, reads, or both? What size data transfers are you doing - small, large, or both? Are you using synchronous or asynchronous transfers? (This last one should not make a difference, but I just want to know.)

Thanks,
Dan Mondrik
National Instruments

[SteveD6722]

Thank you for your response.

My specfic applications uses a whileloop to get Data from both; a JC Controls Model model 520 or Model 620 ,and a Molytek chart recorder used as a temperature input.

The program has a 20 step sequence inside the while loop that completes in 6 seconds with no problem using the "old" serial read/write vi.

When I convert the programs to the VISA serial read/write they do not complete reliably in 9 seconds.

The "old" vi's need a 250mS delay in the write sequence to all the data.

The newer VISA version needs 2 to 3 times the delay and then I still get data reads showing up from the last request. I have tried using both syn and asyn in the vi with no apparent diference. The data transfers range from 6 to 26 bytes. (
The 26 bytes VISA vi takes 3 seconds to get all the data. The old vi does it in 250 mS)

I have not tried to benchmark the modules. I will try to do so in the future and post the results. For now I have hade to dump the Labview 7 and go back to the 6.1 version so I can maintain the programs I have running.

Thanks again for your interest. If it would help I could post or E-mail both VI's.

[Dan_Mondrik]

Are you reading the number of bytes you expect, or are you asking for more than that? If you ask for more, VISA will read what's there, then wait for the duration of the timeout to try to finish fulfilling your request. Sounds simple, but I've seen it happen when people don't realize how VISA is trying to work. But NI-VISA doing serial I/O isn't slow in and of itself. It doesn't add *that* much overhead.

If you know how many bytes you're going to get, request that number. If it's arbitrary but terminated with a given byte, enable the termchar support and use that byte value as the thing to look for. If you're getting an arbitrary number of binary bytes without a known terminating byte, then you may just need to lower your I/O timeo
ut and incorporate some of that logic yourself.

I hope this helps. If not, try posting a simple VI and/or the resulting NI Spy log.

Dan Mondrik
National Instruments

[SteveD6722]

I am using the get bytes call.

I am attaching the file that is giving me heart burn. The time delay has to be set to 3 seconds to get the entire string on one call. The exact string lenght varies depending on the the data available but it my test case it was 26 digits.

Would putting the time delay between the send and recievd block be better?

Any ideas?

On another note I learned yesterday that most of my machine on the floor are to slow ( 500 Mhz or slower) for Labview 7.

Steve Dobbs

[Dan_Mondrik]

Steve:

Assuming that the entire amount of data arrives roughly all at once, there is a better way. The attached VI shows how to do this. First, just read a single byte. VISA will block until the data arrives. Then, see how many more bytes have arrived, read them, and concatenate the responses.

I hope this helps.

Dan Mondrik

[thefalk]

Thanks Dan,

That looks like a good way to make the read less "time rigid". I will try it when I reload Labview 7. Thank you again for your help.

Steve