06-01-2010 01:51 PM
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.
06-01-2010 02:47 PM
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
06-02-2010 08:59 AM
06-02-2010 10:11 AM
06-02-2010 10:24 AM
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.
06-02-2010 10:28 AM - edited 06-02-2010 10:30 AM
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. ![]()