06-17-2008 01:28 PM
Hello,
I was not aware of the File---> save as---" older version".........sorry.......
Regards,
Kaspar
06-17-2008 01:54 PM
06-17-2008 02:27 PM
The use of the *IDN? in the initialize function is there to verify that the correct instrument is in place. In environments where there are a number of different test sets and instruments, it's nice to know that the right one got placed back in the right place after being sent out for cal, for example. Different instruments from different vendors will have completely different command sets and often instruments from the same vendor will have completely different command sets so when you use a LabVIEW driver, you have to check for compatability.
Other problems arose when one instrument was made obsolete and the replacement used different commands. When this happened, you had to rewrite your program. To solve this issue, about 10 years ago, the IVI Foundation was created. IVI stands for Interchangeable Virtual Instruments. What IVI does is establish a set of common functions for a type of instrument (DMM, Scope, Power Supply, etc.) and then place a wrapper around an instrument specific driver. So, if you write a program with an IVI Scope class driver, you will have gneric functions like setting the vertical, time base, triggering, etc. If you use nothing but IVI calls, then in theory, a scope from vendor A could be replaced with a scope from vendor B with no change required in the program.
If however, the instrument from vendor A provided some unique feature that you had to use in a program, then you called into the instrument specific driver and that sort of negated the reason for using IVI in the first place. There is no IVI function for the screen capture, by the way.
Another possible problem with IVI is that none of the low level drivers are written in LabVIEW. Initially, all IVI drivers were written with LabWindows/CVI so if you needed a quick bug fix, you needed CVI to make the change. Then, a few years ago, some of the member companies of the IVI Foudnation decided to make things more complicated and decided to add a new type of IVI driver called IVI-COM. These are ActiveX based and much different.
Sorry about the rants and the history lesson. You can find much more information about IVI by doing a search of NI site. You can also check the instrument driver network to see if IVI drivers exist for the scope's you use.
06-17-2008 03:57 PM
Hello,
Thank you for your commetns about the IVI drivers, etc. Any guidance from one of the wizards will always be appreciated! At the very least it will be good reading while drinking Mountain Dew!
Regards,
Kaspar
06-17-2008 03:58 PM
Hello,
Thank you for your comments about the IVI drivers, etc. Any guidance from one of the wizards will always be appreciated! At the very least it will be good reading while drinking Mountain Dew!
Regards,
Kaspar
06-17-2008 04:02 PM
Hello,
Has anyone experienced random GPIB read issues (hangs of failures) when communicating to the Tektronix TDS5034B scope? I have been getting the following random errors when communcating with the scope, they are -1073807339 and/or -107380265. When ever I get these errors I would highlight execution on the block diagram and it would occur during a VISA read, which was after a valid command issued with a VISA write.
Any ideas what could be causing this?
Regards,
Kaspar
06-18-2008 08:40 AM
06-18-2008 09:45 AM
Hello,
So far the summer intern has confirmed the theory that if you do not touch the front panel controls of the scope the random com errors do not happen. So I decided to call up tektronix tech support and they confirmed my suspicion, the scope processor cannot react to front panels control adjustments and support GPIB com activity at the same time. it is one or the other, in fact the front panel controls take priority.. So I will have to update the test station software to put the scope into remote mode (the LOCk command on page 399 of the 917 page programmers guide of the scope) to disable the front panel controls during the automated test. I have also found out that there is a whole section of "scope synchronization" starting on page 856 of the programmers guide to properly control the scope. The scope does not always immediately complete the task(s) that it is commanded to perform via GPIB commands, time is required . So if you command the scope to do something, it takes time, so you will have to wait for the task to be complete BEFORE you can expect the results to be available. The BUSY? query is a good way to figure out if the scope is processing a command, etc.
So I will be obviuoly updating my code to reflect what I have learned and also creating vi's enabling and disabling front panel controls of the scope if the drivers from NI currently have it.
Regards,
Kaspar
06-18-2008 09:58 AM
06-18-2008 12:34 PM