Getting timeout checking AcquisitionStatus using tkdpo4k driver for DPO4034 scope

D_T · ‎12-12-2008

I'm interfacing through TCP/IP with multiple oscopes and Keithley multimeters (using GPIB extender) with C#. Each scope is controlled in a separate thread class, and is using the tkdpo4k ivi driver and Measurement Studio generated .NET wrapper (PInvoke). The goal for the scope to capture single waveform pulses, so I'm using the InitiateAcquisition(), then polling with AcquisitionStatus() until the status flag goes from 0 to 1, indicating that the acquisition is complete. Then I use FetchWaveformMeasurement() to retrieve the waveform(s).

This software has been running for weeks at a time without issue, until recently. Now I'm getting periodic Timeouts (0xBFFF0015) on the AcquisitionStatus call, which is happening only on 1 scope (out of 4). I replaced the oscope, thinking it was going bad, but then a different scope began exhibiting the same problem (maybe they're all going bad... but I'm not convinced of that yet).

I'm looking for suggestions on similar experiences and/or how to handle these errors. I'm not sure if it is network traffic or that I'm polling the scope too fast or something else.

My software disconnects and reconnects to the scope when this error occurs, which works, but seems unnecessary if this timeout is to be expected. I've just changed my code to look for the timeout error and ignore (retry), so I'm testing this approach. But then I got a 0xBFFF003E error, indicating I/O Error the next time I issued the InitiateAcquisition() call. I had to issue a Reset command (on my GUI) to clear this up.

So for a second question... what is the best way to clear the 0xBFFF003E error without resetting and reconfiguring my scope settings? Let me know what other info I can provide on the problems.

Thanks in advance for any help or ideas.

Sincerely,

Dave T.

Albert.Geven · ‎12-13-2008

Two suggestions:

What about timing conflicts on the bus with the keitley calls? You need something like gpibspy to find out, but it influences the process.

And second, how good is your cabling?

greetings from the Netherlands

D_T · ‎12-16-2008

Thanks very much for the reply and suggestions.

I've disabled all Keithley calls as well as control of the other oscopes. I'm now controlling only the oscope that is giving occasional timeouts. All cabling has been changed out as well.

Same results. Things work for a few minutes then I get a Timeout (0xBFFF0015). Following the timeout, I get IO Error (0xBFFF003E) and Invalid Protocol (0xBFFF0079). I am using NI Spy to capture the calls, which I attached. The timeout happens at line 3013.

I'm still wondering if it's the scope or if some errors such as these should be expected and there's a way to clear it and continue. If so, please let me know.

I'm using tkdpo4k version 1.1 and NI-VISA 4.1.

Thanks very much,

-Dave

D_T · ‎12-16-2008

I switched the interface to USB and I'm not getting the problems.

-Dave

D_T · ‎12-17-2008

I would be very interested in knowing if others have had similar problems using ethernet, but not having the problems on USB, which is the case for me. I'm checking with Tektronix on whether they believe it is a problem with the ethernet module on this particular scope.

I would also like to get some ideas on what commands to send that will clear or recover from the IO Error (0xBFFF003E) and Invalid Protocol (0xBFFF0079) based off of the NI-Spy capture I attached earlier.

Thanks very much,

-Dave

Ryan_F · ‎12-18-2008

Hey Dave,

The BFFF003E error comes from the VISA Write IRP_MJ_FLUSH_BUFFER request causing an INVALID DEVICE REQUEST response from the device. By default, each VISA Read and Write is followed by a VISA Flush call. You can change the VISA Buffer setting to keep VISA from executing the flush call to avoid this error.

If you call the VISA Set I/O Buffer function at the beginning of your application (after the VISA Open, before any reads or writes) and set the mask to 48 (16 + 32, where 16 is the mask for receive buffer and 32 is the mask for transmit buffer) and the size to some value between 4k and the largest amount of data you ever expect to read or write, that will cause the flush command to not be executed.
However, if you do not call this function, VISA will segment all writes into 500 millisecond chunks and call flush after every write. By telling VISA that you will never use more than 4k or the value to which you set the size, VISA in turn will not call the flush.

I will look into why an error would be generated when using ethernet and not USB.

Thank you,

Ryan

National Instruments
Applications Engineer

D_T · ‎12-18-2008

Ryan,

Thanks very much for the reply and for looking into the problem.

In looking at the C code for the tkdpo4k driver, it appears that the driver is setting the I/O buffers to 4k and the modes to VI_FLUSH_ON_ACCESS. I see this in the first few lines of the Ni Spy capture output that I posted earlier. These values seem to be hard-coded in the driver and not exported. Please let me know if these are settings that I can change using the driver. Again, I'm accessing using C# (.NET).

I exported the first 10 lines of the NI-Spy capture that shows how my scope session was started (I think the first 6 are the ones I am interested in):

1. viOpenDefaultRM (0x0520D1A0)