LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TDS5034

Hello,

 

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

 

Regards,

 

Kaspar

Regards,


Kaspar
0 Kudos
Message 21 of 48
(1,908 Views)
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
Regards,


Kaspar
0 Kudos
Message 22 of 48
(1,920 Views)

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.

Message 23 of 48
(1,914 Views)

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

 

Regards,


Kaspar
0 Kudos
Message 24 of 48
(1,907 Views)

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

 

Regards,


Kaspar
0 Kudos
Message 25 of 48
(1,906 Views)

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

 

Regards,


Kaspar
0 Kudos
Message 26 of 48
(1,895 Views)
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 
Regards,


Kaspar
0 Kudos
Message 27 of 48
(1,871 Views)

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

 

 

 

 

Regards,


Kaspar
Message 28 of 48
(1,862 Views)
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.
Regards,

Jared Boothe
Staff Hardware Engineer
National Instruments
Message 29 of 48
(1,856 Views)
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?
Message 30 of 48
(1,845 Views)