GPIB device produces conflicts with others

[G.Bartsch]

Hello!

 
I have fundamental problems with our GPIB devices. Everything startet with two older devices I included in the GPIB setup. For the new "old" devices I have older COM drivers as well as ActiveX control based VIs. On their own the devices work ok, but they interfere with other devices
with different GPIB adresses. Manufacturers of the critical devices asked me to install the latest NI 488 drivers and
to try the activex VIs I mentioned but I get the same errors.  NI spy shows errors for one of the critical devices, even when it operates alone on the GPIB bus but it works ok. Could this be related to the conflicts together with other devices? The conflicts I am talking about appear as a freezing labview.This happens when the most critical device is talking and another device is asked to talk at the same time. For example one could just run a GPIBread.vi with a totally different GPIB adress and the critical device makes labview crash. Terminating parameters are set
as requested by the manufacturer. Right now I am using a quite old NI 488 version (July 2000) as another device doesnt work with later ones.The GPIB controller is a PCI 488.2 controller from NI. The problematic devices are Jobin Yvon Monochromator Triax550 and a CCD 3500. Both are approximately 10 years old. Labview version is 7.1.

So what could make devices with different adresses interfere? I am open for any suggestion as some slight hints of desperation had been rising within the last days ;P.

Bests

Gregor

[Albert.Geven]

Hi

When they use the same bus at the same time they interfere.

Try to set the busspeed to 2 microseconds (necessary for the olderinstruments, no problem for the newer)

Make use of error in/out to synchronise calls to all devices

Have higher level vi's for an instrument that handle all calls for that specific instrument. and keep a log of the errors with timestamp.

good luck

[JÞB]

Gregor,

Without the specific device driver documentation I can only point you towards some possible conflict areas.  The number one area I would be looking into is GPIB bus handshaking. Take a good look at the drivers to see if they are unaddressing after each operation and readdressing at the begining of the next.  Without this you have a direct connection from PC to the instrument addressed and no other instruments can be addressed.

Also, It sounds like you are using straight NI 488 (GPIB calls) from LabVIEW.  If your subroutines are running in seperate threads you can get some fairly nasty problems when both threads attempt to access the same bus (addressing conflicts).  The solution for this is VISA and updated VISA / 488.2 drivers.  While you stated that one of your devices doesn't work with the new drivers I believe, from experience, that you could overcome the problem by setting the VISA properties to match what the instrument expects.  It is evident that your instruments are not 488 compliant nor 488.2 compliant.  (nothing really unusual, many instruments are not)  The trick is to inspect the instrument programmers guide and avoid the offensive VISA calls.

As an example- I once had an instrument that interperated a GPIB interface clear (*IFC) as a quit command (very non-compliant operation) therefore I had to open every other VISA session FIRST or, alternatly, test the instrument's condition and re-enable operation. 

Good Luck!

Jeff

[JÞB]

Alternately, (for brute force solution) Hang a second GPIB controller for the non-compliant instrument!

[G.Bartsch]

Thanks so much for your help!

You put the idea in my head to implement some synchronization by semaphores which seems to overcome the problems.This is far away from a perfect solution but for the first approximation it is ok.

Best regards

Gregor

[JÞB]

Gregor-

Glad to help!