Unlock Equipment - viclean

[DarinM]

Hello forum,

I had quick question. We have an older test rack that is running off a Sun server (sparc), with the equipment connected via GPIB (SCPI compliant). With that equipment, we're able to run viclean should one of the pieces of equipment become "locked".  Running viclean will usually put the device into an unlocked state where we can start sending it commands again.

Now we recently just built a new test rack that is running off Linux server (x86), with the equipment connected via GPIB (also SCPI compliant). For some reason, if we get a lockup with this equipment, running viclean seems to have no effect in unlocking the equipment.  We're forced to walk out to the lab and reboot the piece of equipment in order to get it to start accepting commands again.

Other than rebooting the piece of equipment, any idea on what an alternative method to get the equipment to respond to commands might be?  Or perhaps why viclean no longer works?

Thanks,

- Darin

[Michael-B]

Hello Darin,

What distribution/version of Linux are you using?  What kind of equipment are you trying to communicate with?

[DarinM]

Hello Michael,

We are using Red Hat Enterprise Linux 5.6, and the instrument is a Rohde & Schwarz FSUP26.

Regards,

- Darin

[DarinM]

Just to clarify, I mispoke in my original post.  We're having to reboot the actual server with the GPIB controller card in it, not the piece of equipment.

Also, we have an Agilent PNA-X (N5241A) that we started testing and we're experiecing the same problem.  Our test script crashed and left the equipment/GPIB card in a locked state.

I tried going through NIvisaic and doing a viUnlock, and the return code is BFFF009C.  I tried doing a viLock just to see if it would work, and it returned BFFF0015.

Regards,

- Darin

[Michael-B]

Hello Darin,

How long does it take for these lock-ups to occur?  If it's a relatively short time, have you tried using I/O Trace?  Also, what GPIB hardware are you using?  Are you using the latest version of 488.2?

[DarinM]

Hello Michael,

These lockups occur immediately if our test script crashes.  Since our script obtains a lock on the hardware, if the script crashes, the hardware is left in a hanging state of being locked.

Right now we are using the 488.2 beta 2.5 1b1 drivers, and we're on Linux kernel 2.6.18-194.  I see that there is a new version, 2.9 that came out in August, I will try installing that and see if it corrects our problem.  If not, I'll go the I/O trace route.

The GPIB Controller Card that we're using is the NI PCIe-GPIB.

Thanks for the advice Michael.

Regards,

- Darin

[DarinM]

Hello Michael,

We installed the NI-488.2 v2.9 drivers and it fixed the 'lock' issue!!  Now when we run the the unit test that was crashing and locking up the device, it still crashes, but when we run it again the driver is able to successfully reobtain a lock on the device.  I verified this through the NI I/O Trace program.

Thank you very much for your guidance!  I will pass this info along to some of our other teams that have this issue and have just been doing the STE reboot method.

Thanks,

- Darin