TDS5034

[Kaspar]

Hello,

  I was not aware of the File---> save as---" older version".........sorry.......

Regards,

Kaspar

[Kaspar]

Hello,

   thanks again for the previous reply about the drivers for the TDS5034B. I looked at the init vi and the vi sends the "*IDN?" command to the scope to get the id and if the scope if one of the "chosen few". life it glorious. I am just curious as to why the Id of the scope has to be a member of the :chosen few". I s there a DLL and/or other vi that only works on a limited model of scopes?

Regards

Kaspar

[Dennis_Knutson]

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.

[Kaspar]

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

[Kaspar]

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

[Kaspar]

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

[Kaspar]

Hello,

   I am getting closer towards a better understanding of why I am getting random com errors with the scope. I have added a delay into the screen capture vi to allow the scope more processing time before I try to read the data from the scope, so be aware that there will be a update soon. I have also observed that when someone operates one of the front panel controls on the front of the scope while PC is talking to the scope , the random com errors appear. So right now a summer intern is creating setup files for the test station and is paying close attention to the correlation between GPIB com errors with the scope and operating the front panel controls. If the theory proves to be true it may mean that I will have to disable the front panel controls during the automated test. I will also be calling Tektronix to see if there are any issues with GPIB com errors and front panel control adjustments. 

  Stay tuned for further details.

Regards,

Kaspar 

[Kaspar]

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

[Jared_B]

Kaspar,

Keep up the good work!  Be sure to read through all the documentation on your device that you are communicating to, there can be some little "aha!" moments when you stumble upon things like this.

[fabb]

I am also running into these errors. I tried even a 5 second delay without any luck. I am using a 3034B scope instead of the 5034. Anyone see any problems with this?  Any other ideas?