GPIB Error 6 with ITC55100

[Beri]

Hello to all LabVIEW-Gurus out there

I am faced with an problem I actually can't solve by myself, so I decided to ask for some ideas in this forum.

Currently I am developing an avalanche measurement station, using an ITC55100 Unclamped inductive load and a TEKTRONIX TDS7104, which are both controlled from a PC via GPIB. The software itself seems to be quite ok (I have to use an old version and bring it up to the new hardware). But every now and then I get an GPIB-Error 6 when communicating with the ITC-device (to be mor precise, when I try to get the status of the tester). As far as I know this error is related to an timeout issue. I used simple GPIB read and write, but problem stays even when switching to VISA.

The first attempt was to implement an wait-time between the start of the test and checking the error. This brought an slightly improvement, bu the error still comes up. The next step was to start the NI Spy to get information what is going on on the bus. Then I made a set of screenshots to compare the bus activities in the two cases (time-out and no time-out). But unfortunately I can't see the breaking point. Has anybody a hint for me?

Many thanks in advance

P.S.: LabVIEW7.0 and Windows2000prof

no time-out:

timout:

[Mellroth]

The first attempt was to implement an wait-time between the start of the test and checking the error. This brought an slightly improvement, bu the error still comes up. The next step was to start the NI Spy to get information what is going on on the bus. Then I made a set of screenshots to compare the bus activities in the two cases (time-out and no time-out). But unfortunately I can't see the breaking point. Has anybody a hint for me?

I have seen something similar with a GPIB controlled Power supply.

In this particular case the problem was that the PS could not handle commands at a rate higher than 25Hz. The solution was to limit the instrument access to this rate, i.e. make a check that at least 40ms has passed since last call.

We also had problems with LabVIEW RT (7.1.1.) and VISA. When VISA write was performed asynchroneously, it caused the RT application to crash after a while.

I don't know whether this applies to you, but...

/J

[peteski]

We also had problems with LabVIEW RT (7.1.1.) and VISA. When VISA write was performed asynchroneously, it caused the RT application to crash after a while.

/J

JFM,

What version of VISA were you running with the 7.1.1 RT? I've recently run into similar issues with VISA serial reads/writes that seemed to be solved by updating the NI-Serial, NI-VISA, and NI-DAQmx. Sorry, in my haste I tried the old "shotgun" approach and it appears to have worked, but I couldn't tell you for sure which did the final trick. My intuition is that it was NI-VISA, but that is just a hunch, "unimpeded" by actual knowledge or hard data.

-Pete Liiva

[Beri]

Finally I get my problem solved (hopefully).

I switched to VISA sessions and made some changes in my application. I think the main issue was timing, looks like my application was too slow for catching the response of the ITC-device.

The final rereliability test will follow tomorrow *hope the best*

[Mellroth]

What version of VISA were you running with the 7.1.1 RT?

I actually don't remember, but I know we upgraded to the latest versions (as of September -05 Februari-06) of DAQmx, VISA etc...

We were able to reproduce the crash with a very simple program, and this was sent to NI in a bug report.

I'll see tomorrow, if I still have the bug reference/test program lying around.

Since there was an easy workaround we have moved on, and the system is running as it should.

Edit:

I found my bug report, but not the test program.

I'm writing commands to a GPIB instrument using VISA write in a timecritical loop (running at 1kHz).

The GPIB commands is sent at 25Hz.

If the VISA write method is configured as Asynchronous the RT target crashes after a while (time to crash varies).

Reconfiguring the VISA write node to synchronous mode solves the issue.

The command written in the TC loop is "VOLT\s%d FREQ\s%d\n" with values inserted instead of %d.

There is no error coming out of the VISA method, the RT target just crashes.

I've verified that it is a VISA problem by removing all other I/O from the RT application.

NI-VISA 3.4.1

/J