Instrument Interface Speed Test

[cubnstyl]

Hi all,

I have a Tektronix 3054 Oscilliscope connected to a PXI chasis running Windows XP. I have the scope hooked up on both ethernet (with a eth switch) and GPIB. I am trying to design a VI that displays the time it takes to acquire a waveform through ethernet and then GPIB. I have created a very basic VI that has a ms timer at the start of data flow and another one at the end of the acquisition loop for the chosen interface. The logic of this makes sense to me except the GPIB timer reads about 150 ms and the Ethernet timer reads 1.0 s + . This is obviously not right being that Eth is supposed to be faster. I think my design may be too simplistic. CAN I GET SOME HELP PLEASE! I have experience in Java and other object orientated languages, but I am obviously a LABVIEW newbie.

HERE IS THE VI

Download File:post-5462-1151699165.vi

[LAVA 1.0 Content]

I downloaded the NI Plug and Play driver for your instrument an looked at your updated code.

I opended the driver vi called tktds3k Read Waveform.vi and saw that there are two sub-vis (functions) called inside. The first is called initiate, the second is fetch. The help for the initiate indicates this should only be used once in a sequence of calls to lower level vis.

I then opened and looked at the example vi in the top pallete for the driver and saw that the Dual Channel Waveform Acquire example uses one Initiate and two fetch calls in series rather than the Read Waveform vi as in your example.

Try following the example and see if this improves the performance. :thumbup:

Even though Ethernet is a faster interface, it does not have all of the handshaking and determinism of GPIB. It may be that driver implementation is written for compatability with RS232 AND GPIB AND Ethernet more than for performance over any one of these busses.

[cubnstyl]

Thank You very much. I made those changes according to the dual waveform sample but I still get 1.5 seconds for ETH and .1-.3 seconds for GPIB. I think you are right, the ETH functionability may not be designed for performance.

[peteski]

Thank You very much. I made those changes according to the dual waveform sample but I still get 1.5 seconds for ETH and .1-.3 seconds for GPIB. I think you are right, the ETH functionability may not be designed for performance.

cubnstyl,

An interesting aspect to ethernet transfer is something called the nagle algorithm and it might be finding its way into this problem. I encountered this a few years back while programming to control a LeCroy LSA1000 High Speed Digitizer, which was basically an oscilloscope with no screen or buttons, just BNC inputs/outputs and an ethernet interface. The short of it was that I found that if I added ~1450 bytes of blank space characters to whatever communications I sent to the LeCroy, I would increase the speed by at least an order of magnitude or so. It was a clear step function, where one to few characters wasn't enough, and any more then the needed amout did not provide anymore speed advantage, which makes sense considering how the nagle algorithm is designed to work.

There might have been a more "graceful" way of getting the same performance, but it wasn't obvious to me at the time and adding the extra characters allowed me to get what I wanted, performance-wise, so I stuck with the kludge.

There is no guarentee that this is the problem in your case, nor that somewhere arround 1450 charaters is going to work in your instance, but it might be worth trying by adding different lengths of blank charater blocks to all the commands you send to the scope to see if you get a sudden increase in performance.

Hope this helps,

-Pete Liiva