scobe drivers

[Toronto Transit]

Hello,

Unfortunately I could not solve the problems with the Instrument drivers provided by NI for Tektronix 3034B scope.

It is very frustrating for me, since I suggested NI related products for our test bench project, but at the very early stage of the work, we failed with these instrument drivers. It works sometimes with simple waveforms, but most of the time it reports time-out errors and stops.

The sub VI tktds3k fetch waveform.vi does not finish the process, I am new to LabView and I could not figure out why it waits, I believe I also should not try to trouble-shoot your VI, I could use it simply.

My observation with these drivers is they were written on the desk and they never tested on actual scopes with actual signals, lots of mails on the user groups with similar descriptions.

Please help me to contact one of the application engineers to have a tested version of the Tektronix drivers or to have more support on this issue.

Regards,

Hasan Cildir

[Dennis_Knutson]

Of course they've been tested with actual instruments. Your driver was actually tested with the 3054, 3054B, and 3064B per the download page. I'ts certainly possible that your model of scope works slightly differently. It's next to impossible to test every model scope. NI has to get a scope from a customer who wants a driver, from the instrument manufacturer who wants NI to create a driver, or they have to go out and buy or rent the instrument themselves. The last option would get pretty expensive and you wouldn't be getting free drivers anymore. Is it possible that there's a bug in the driver? Of course. No one can possibly test a driver in every possible way that someone might use an instrument. In general, I have found the majority of drivers pretty good and I've been using them for many years. I've also found many that I have need to tweak in some small ways or add some features that I needed that were omitted originally.

If you want support, it would help if you explained exactly how you are using the scope. Include some sample code.

[Toronto Transit]

Hello Dennis,

Here a suggestion posted before for the same problem.

If possible can you explain why it needed to update this VI from binary to ASCII ?

Can NI spy logs be helpfull to understand why it stops and reports time-out?

hcildir

[Dennis_Knutson]

In my experience, data transfers are typically done only as binary. This is because ASCII transfers take much, much longer. With each ASCII character being 1 single byte versus a the complete value in binary mode might be 2 bytes at most, it's much more effecient to do the conversion to floating point values, locally, on the pc, instead of on the scope. When doing an ASCII transfer, since the total byte count will go way up, it is possible to exceed the timeout value for a complete transfer. Whoever modified the VI felt the need for ASCII transfer capability but I don't know why anyone would do that on a regular basis and I would never include that mode in any driver I wrote.

The spy log would be helpful because someone can look at all of the commands sent to the scope, see how it is setup, and try to determine why the timeout occurs. If you are doing an ASCII transfer, then switching to binary mode will probably eliminate the error. If you are requesting an extremely large amount of data, that could also cause a timeout. What VISA Read does is keep reading until the number of bytes requested is input, the GPIB EOI termination is detected (which means there is no more data to transfer), or the timeout value is reached. The timeout value is something that can be set in your program so a modifiction of that may also fix it. The VISA timeout is a property node and is on the Instrument I/O>VISA>VISA Advanced palette.