04-03-2007 03:28 AM
04-04-2007 12:42 PM
Hi Vishal,
Did you also upgrade your version of VISA or MAX during your upgrade to LabVIEW 8.2? It is possible that something changed in the VISA driver during the upgrade which now results in this issue. Also, what version of the TekVISA driver are you using? Thanks!
04-04-2007 07:44 PM
04-06-2007 09:01 AM
Hi Vishal,
I found this link to download TekVISA 3.02: http://www2.tek.com/cmswpt/swdetails.lotr?ct=SW&cs=Utility&ci=5738&lc=EN&from=rss
So I can try switching between the VISA versions to see if I can reproduce what you are seeing on one of our test machines here. I'll let you know what I find!
04-16-2007 06:26 PM
04-17-2007 01:03 AM
Installing the TekVISA did not solve the problem 😞
But I got some other solution. 🙂
Are you using any Tek Application(Open Choice, TLA Application or some other)? If no then you can uninstall TekVISA and it will work fine.
If you want to use Tek Application and you want to use the system with LabVIEW and/or TestStand (Without using NI MAX) then install LabVIEW and TestStand first then install Tek Application. This will make the VISA32.dll file of TEK. Then go to InstrumentManager of TekVISA. Go to Search Criteria, select require interfaces. Press Done.
Then Update the list once. This will work for you in LabVIEW and TestStand.
Regards,
Vishal
04-17-2007 01:05 AM
Hi Did you find anything?
Regards,
vishal
04-17-2007 10:16 PM
04-18-2007 10:18 PM
I was also using this, but if you are not using NI MAX then you can use TekVISA and it will work fine. LabVIEW and TestStand can work fine with TekVISA as I mentioned earlier.
Only if you want to check / verify something using NI MAX then you need to switch back to NI VISA.
Regards,
Vishal
08-22-2007 11:39 AM - edited 08-22-2007 11:39 AM
I haven't read the entire thread, so I'm not certain as to the original question. But I will describe my most recent experience.
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:39 AM
Message Edited by Ed Christy on 08-22-2007 11:40 AM