LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed Loop/GPIB Query

I am attempting to query a Tektronix TDS3054B oscilloscope at a rate of 10Hz through GPIB.  I have a piece of code that performs the query and returns the relevant value (pk-to-pk measurement).  This code runs in about 3-5ms according to the "Profile Performance & Memory" tool.  When I place this code inside a 'timed loop structure', the loop is very sporadic and usually doesn't finish in under 100ms. I can see this from the "Finished Late [i-1]" and "Iteration Duration" nodes of the timed loop.  It seems that if the only things inside the timed loop take less than 5ms, why should the timed loop be taking so long? 

 

 My ultimate goal is to synchronize three device queries (GPIB scope, Oceanoptics Spectrometer, Firewire Camera) and process this data, all in under 100ms.  I am almost certain that this should be possible, since the processing algorithm that I need to run should run in under 30ms.  In an attempt to figure out where the bottleneck in the code is, I created a barebones VI that just contains the timed loop and GPIB query.  This VI is attached.  I am somewhat new to LABVIEW development, but have been playing around with it for some time now. Any help or insight into this problem would be much appreciated.

 

-Attachment 1: GPIB_Read_Scope.vi    - Runs very quickly by itself, and works fine.

-Attachment 2: GPIB_Read_withTimedloop.vi   - Same as attachment 1, but with timed loop.

Download All
0 Kudos
Message 1 of 6
(3,318 Views)

hi,

i don t have much experience with the timed loop but I saw that it takes more ressource than a while loop.

if this 10 Hz speed is not criticval you may want to switch to a while loop by using wait next ..  ms function; 

synchronizing gpib may be done with the GET function

n

0 Kudos
Message 2 of 6
(3,305 Views)
Unfortunately, the 10hz timing is absolutely critical.  The devices measure characteristics of a laser beam that pulses at 10Hz.  I need to be able to trigger each of the devices (to a relatively high degree of precision) at 10hz.
0 Kudos
Message 3 of 6
(3,285 Views)
I have read in certain places that it is not advisable to place certain structures inside of a timed loop, for they degrade performance of the timed loop....does anyone know which types of VI's inside a timed loop can cause problems?  Also - is it even possible to get this loop running and acquire these signals in time using Labview 8.6 withOUT the Labview RT devices, etc.?  The timing is mission critical, but using external trigger signals, I would assume this can be achieved without purchasing the RT functionality.....
0 Kudos
Message 4 of 6
(3,274 Views)

Try the attached. There is a better benchmark for the write/read and a timed loop example without that silly while loop. There is no way that the query is going to return more than 4096 bytes. They also use the recomended VISA api.

 

I would not be surprised if the benchmark returns an average greater than 3-5 msec. You are working with GPIB and all of it's limitations and moving to RT is not going to affect that at all.

Download All
0 Kudos
Message 5 of 6
(3,268 Views)

I suspect in this case you may wish to use some form of hardware synchronization.  A trigger from the laser could provide a trigger to the rest of the instruments to start their cycles.  Failing a stable laser trigger,  triggering of the o-scope on a input level and edge would give you a reasonable trigger out from the scope for hardware signalling to the other instruments.  Windows timing is probably too non-deterministic for this application.  That being said, you may see some improvement by changing the vi Properties>execution>priority and/or disabling debugging. 

 

I have a sneeking suspicion that debug enabled timed loops might take a performance hit for every input and output node that is visable whether or not they are wired. Smiley Wink

Message Edited by Jeff Bohrer on 06-02-2010 10:30 AM

"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 6
(3,266 Views)