GPIB PCIe card communication with Keithley DMMs and SMUs occasionally freezes also in NI-Max/ No problem with USB-HS+

[grazvi]

Hello, while trying to read the buffer of a Keithley DMMs or SMUs (2450 e.g.) many times fast enough the in NI-Max freezes,  no response and needs to be killed in task-manager.  Same happens using .NET in Visual studio. After changing to the USB-HS+ this issue is gone. Is there a solution for that problem to be able to use PCIe-GPIB card? 

NI-MAX 18.5, also latest firmware at Keithleys

Thanks

[cstorey]

Its really hard to provide a solution without seeing your code or a description of your measurement setup.

But I suspect the problem lies in the fact that a Keithley 24xx SMU isn't really equipped for high speed data transfer.  I suspect the USB-GPI-HS+ limits the number of commands the instrument received to a manageable number, whereas the GPIB PCIe is just flooding the instrument with requests it can't keep up with.  I suggest a 50-100ms delay in your loop between requests to the instrument to ensure it has time to source/measure/transmit data.

While the Keithley 24xx series can be used to capture a lot of data at once its not recommended to try to constantly poll the instrument for the data.  Rather you buffer measurements to the internal memory and read it back in a chunk.  There are lots of examples of how to do this in the manual or the LabVIEW driver examples.

Craig

[grazvi]

Thanks for such fast and good answer. We buffer data on the device but some other commands are sent in one write command, probably this cause the issues. Can you provide more info on the timing? 50ms seems to be a lot? Consumed time is very important for us since the same program runs thousands times. 

One clarification: especially the NI max freezes not only Keithley SMUs NI max. Ni-Max states that it is reading though no time-out ever occurs. While in visual Studio compiled program completely freezes and whole pc needs to be restarted. Not seen such behavior since xp : ). I saw some clues on interupts on the web. But timing seems to be most probable cause. 

Thanks again for valuable info

[cstorey]

I can do a lot of guessing, but to get good answers provide better details! 😉 What are you measuring?  What commands do you send?    Do you check errors?  What error message on the device when it freezes?

Measuresement can happen fast all the time it takes is to format the data and put it on bus, depends on measurements and #digits, format used.  About 16ms/read is fastest you can get, but it makes sense to slow that down to something reasonable like 50/100ms.

You aren't using NI-Max and your software at the same time are you?   That's a no-no, there will be conflicts and unpredictable behaviour.

You should use NI-SPY (NI-IO trace) to capture all the traffic on GPIB bus and see what the last comman is before it freezes.  Log data to file, use verbose mode.

Craig