LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Resistance Bridges

Has any one used Labview to talk to an Automatic Systems Laboratories (ASL
Ltd) F26 AC Resistance Bridge using IEEE488. Some of the instruments I have
are late 80's vintage and seem a bit touchy at reliable comms. Anyone else
had success?

PK
0 Kudos
Message 1 of 3
(2,409 Views)
I haven't used that specific device but given it's age I can give a couple general hints that might come in handy.

First, go through the documentation and identify whether there is any special I/O protocol built on top of the GPIB interface. For example, one instrument I worked with required a very specific set of steps to be performed each time you accessed the instrument:
1. Poll instrument state
2. If "Idle" write conmmand.
3. Poll instrument for state.
4. If "ready to respond", go to step 6.
5. If "busy", go back to step 3.
6. Read response.
7. Poll instrument to return any error states.

Second, it is very common for old instruments to have response-time problems. For example the instrument cited above had a problem that I would sometimes send a command and when I checked the instrument state the device still showed that it was idle. The problem was that LabVIEW could send the command and poll for the state change faster than the instrument could change state--and this was with LV 1 running on a 2-MHz MacII! The solution was to insert a fixed 100 msec wait inbetween steps 2 and 3 to insure that the instrument had enough time for that initial state change.

Third, another common class of errors for old instruments were violations to the IEEE-488 specification. These problems can take a variety of forms and are a pain to track down. In my experience the most common problems were instruments that left the bus in an inproper state. In those cases I had to explicitly untalk and unlisten the instrument.

Finally, if you get into a really hinky situation, you might have to revert to standard GPIB calls as I don't know if the VISA version of the drivers give very low-level access to the bus.

Your first job should be to create a command driver that allows you to type in any command the instrument knows. The routine should send the command and read any response from the instrument. With that VI in hand you can start going through the instrument's command set and verifying that all the command do what the documentation sayes they do (...and they probibly won't).

Hope this doesn't scare you. Hollar if you need advice of specific issues that might come up.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 3
(2,409 Views)
Thanks for the info. I shall have a detailed look tomorrow when I get back
to work.

Regards

Per
"mikeporter" wrote in message
news:506500000005000000A87C0000-1021771306000@exchange.ni.com...
> I haven't used that specific device but given it's age I can give a
> couple general hints that might come in handy.
>
> First, go through the documentation and identify whether there is any
> special I/O protocol built on top of the GPIB interface. For example,
> one instrument I worked with required a very specific set of steps to
> be performed each time you accessed the instrument:
> 1. Poll instrument state
> 2. If "Idle" write conmmand.
> 3. Poll instrument for state.
> 4. If "ready to respond", go to step 6.
> 5. If "busy", go back to step 3.
> 6. Read response.
> 7. Poll instrument to return any error states.
>
> Second, it is very common for old instruments to have response-time
> problems. For example the instrument cited above had a problem that I
> would sometimes send a command and when I checked the instrument state
> the device still showed that it was idle. The problem was that LabVIEW
> could send the command and poll for the state change faster than the
> instrument could change state--and this was with LV 1 running on a
> 2-MHz MacII! The solution was to insert a fixed 100 msec wait
> inbetween steps 2 and 3 to insure that the instrument had enough time
> for that initial state change.
>
> Third, another common class of errors for old instruments were
> violations to the IEEE-488 specification. These problems can take a
> variety of forms and are a pain to track down. In my experience the
> most common problems were instruments that left the bus in an inproper
> state. In those cases I had to explicitly untalk and unlisten the
> instrument.
>
> Finally, if you get into a really hinky situation, you might have to
> revert to standard GPIB calls as I don't know if the VISA version of
> the drivers give very low-level access to the bus.
>
> Your first job should be to create a command driver that allows you to
> type in any command the instrument knows. The routine should send the
> command and read any response from the instrument. With that VI in
> hand you can start going through the instrument's command set and
> verifying that all the command do what the documentation sayes they do
> (...and they probibly won't).
>
> Hope this doesn't scare you. Hollar if you need advice of specific
> issues that might come up.
>
> Mike...
0 Kudos
Message 3 of 3
(2,409 Views)