I created an executable from LabVIEW 8.2 to run on a Tektronix 7254 scope. Among other things, this application essentially acts as a server for a remote client on a standard PC. The client sends high-level commands to the server which then manipulates the scope as needed, i.e. setting it up and retrieving waveforms for the client. This requires using the LabVIEW VISA read and write VIs and the VISA device GPIB8::1::INSTR. Building and debugging the system was done on a PC. Communicating with the scope was done over TCP/IP through the VXI-11 server on the scope. I just did a standard installation of tekvisa on the PC and didn't touch the scopes.
After getting the application to run correctly on the PC, I compiled it and ran it on the scope. This caused all sorts of problems. The most notable of which was that my application seemed to be chewing up a LOT of processor time, even slowing mouse movement. When the scope was armed in fastframe mode, a thread was monitoring the trigger/acquisition state with a 500ms loop time.
I created a very simple application which I ran on both the scope and the PC. It was just a simple user interface that allowed me to post commands from the keyboard. I still saw a difference in execution. I sat down with Chris Burak from Rio Scientific in Albuquerque. By using the Open Choice call monitor on the scope, we were able to analyze the visa function call sequence created by a simple *idn write and read. We discovered that executing the command on the scope produced a different sequence than when run on the PC. Most notably when run on the PC, a synchronous read was executed. The same command on the scope executed an asynchronous read. We found that the LabVIEW VISA VI's can be set for synchronous or asynchronous mode. They default to asynchronous mode. Right-click on the VI and the mode can be changed. When we recompiled the original application with the VIs set for synchronous operation, it ran on the scope as it did on the PC.
I was told by a Tektronix applications engineer that the GPIB8::1::INSTR call is also routed through the VXI-11 server. If this is true, it certainly treats it differently than a TCP/IP call. VXI-11 must alias the commands to always do a synchronous read when accessed through TCP/IP. I hope this helps.
Message Edited by Ed Christy on 08-22-2007 11:53 AM
