I've been meaning to comment on this.
Just as Agilent VEE users have preferred to use Direct I/O to send SCPI commands, our (LabVIEW) customers have preferred to use native LabVIEW source code instrument drivers to send SCPI commands to instruments. While SCPI isn't perfect, once you figure it out, it's pretty easy to sit down with an instrument manual and figure out how to get it to do what you want.
VXI-11, the protocol that Agilent pushed forward ten or more years ago for Ethernet-based instruments, lets you use SCPI over Ethernet easily using Agilent or NI-VISA. VXI-11 went beyond straight TCP sockets to address things like resource locking, aborting asynchronous operations (e.g., "INITiate"), and sending service requests from the instrument. I'm confused by Agilent's push to a straight TCP socket interface for doing SCPI. What's wrong with VXI-11? Are we losing anything with this approach?
I also find it a little sad if the target audience for controlling new instruments is COM programmers. I think there are a lot of test engineers out there who aren't programmers at all, but know how to get VEE (or LabVIEW, or Rocky Mountain Basic) to send a SCPI command to an instrument and get a response back.
While LabVIEW (and VEE) can deal with IVI-C, IVI-COM, pure sockets, etc., I think there's something to be said for the simple SCPI approach.
I'm admittedly biased, and Agilent would probably prefer to do the opposite of what I think.
What do the rest of you think?
Brian Powell
LabVIEW R&D
""DUNSMORE,JOEL (A-Sonoma,ex1)"" <joel_dunsmore@agilent.com> wrote...
>
> In the latest version of the PNA, on the road to being LXI
>compliant, we just add a sockets server so that you can telnet to the
>PNA over lan, and use your favorite SCPI commands. In vee, it is just
>like Reiner says: set up the Visa and use the to-sockets instead of
>the direct I/O. Of course, you can also use the direct I/O by using
>the PNA computer name as the remote host. Or, if you want to make the
>plunge, you can use the Com/Dcom, and leave that nasty old SCPI behind
>(but we do provide the COM function
> SCPI-parser("command") for the cases where someone wants to use a COM
>connection, but "just wants to send the same old SCPI command").
>Sockets and VISA are handy as you don't need to deal with Com security
>protocals, but once you figure it out, most our our real programmers
>(read that as "microsoft programmers") seem to prefer COM.
>Joel
>
> > -----Original Message-----
> > From: Schlieker, Reiner [mailto:reiner.schlieker@siemens.com]
> > Sent: Thursday, July 06, 2006 6:07 AM
> > To: VRF
> > Subject: RE: [vrf] LXI and SCPI command ?
> > > Yes, we can still use our beloved Direct I/O with the LXI
> instruments > - I wrote a driver for an Agilent 'scope using direct
> I/O after > becoming frustrated trying to figure out the IVI-COM
> driver and having > little time to do it(I thought the newer drivers
> would be EASIER to > use). Once the VISA address is set up, it's the
> same as GPIB.
> > > Reiner
> >
> > > -----Original Message-----
> > From: martin.papproth@nokia.com [mailto:martin.papproth@nokia.com]
> > Sent: Thursday, July 06, 2006 7:49 AM
> > To: VRF
> > Subject: [vrf] LXI and SCPI command ?
> > > Hi all,
> > > LXI (LAN eXtensions for Instrumentation) somehow shows up on
> the > horizon of all (big) test equipment manufacturers.
> > Indeed the setup concept seems quite smart to me; but I still
> wonder > what it means when using existing SW in such a new LXI based
> test > setup.
> > > Specifically: If you have implemented most of your instrument >
> communication upon VEE's DirectI/O objects (talking raw SCPI commands
> > to the device), will there be a possibility to do this with a LXI >
> device as well ? Or do I really have to use some IVI-COM drivers ?
> > > The LXI standard itself only requires an IVI driver, leaving
> the > implementation (either COM or something else) open. So will
> there be a > device vendor specific solution to talk low-level
> commands to the > device ?
> > > Until now in GPIB we loved the simplicity and flexibility of
> the > devices' ASCII commands (SCPI). (It also saved us from buggy
> driver > SW.) We don't even had to bother around synchronizing driver
> versions > across multiple test setups.
> > If we loose this freedom I would really consider it as a downside.
> > > If anyone has some experience or expertise on this topic I'd
> like to > hear from him
> > > thx & br
> > Martin
> > > ---
> > You are currently subscribed to vrf as: >
> reiner.schlieker@siemens.com To subscribe please send an email
> to: > "vrf-request@lists.it.agilent.com"
> > with the word subscribe in the message body.
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email "vrf@agilent.com".
> > If you need help with the mailing list send a message to >
> "owner-vrf@it.lists.it.agilent.com".
> > Search the "unofficial vrf archive" at > "www.oswegosw.com/vrf_archive/".
> > > ---
> > You are currently subscribed to vrf as: >
> joel_dunsmore@agilent.com To subscribe please send an email
> > to: "vrf-request@lists.it.agilent.com" with the word subscribe in
> the > message body.
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email "vrf@agilent.com".
> > If you need help with the mailing list send a message to >
> "owner-vrf@it.lists.it.agilent.com".
> > Search the "unofficial vrf archive" at > "www.oswegosw.com/vrf_archive/".
> >
>---
>You are currently subscribed to vrf as: hpvee-list@ni.com To subscribe
>please send an email to:
>"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
>To send messages to this mailing list, email "vrf@agilent.com".
>If you need help with the mailing list send a message to
>"owner-vrf@it.lists.it.agilent.com".
>Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Just as Agilent VEE users have preferred to use Direct I/O to send SCPI commands, our (LabVIEW) customers have preferred to use native LabVIEW source code instrument drivers to send SCPI commands to instruments. While SCPI isn't perfect, once you figure it out, it's pretty easy to sit down with an instrument manual and figure out how to get it to do what you want.
VXI-11, the protocol that Agilent pushed forward ten or more years ago for Ethernet-based instruments, lets you use SCPI over Ethernet easily using Agilent or NI-VISA. VXI-11 went beyond straight TCP sockets to address things like resource locking, aborting asynchronous operations (e.g., "INITiate"), and sending service requests from the instrument. I'm confused by Agilent's push to a straight TCP socket interface for doing SCPI. What's wrong with VXI-11? Are we losing anything with this approach?
I also find it a little sad if the target audience for controlling new instruments is COM programmers. I think there are a lot of test engineers out there who aren't programmers at all, but know how to get VEE (or LabVIEW, or Rocky Mountain Basic) to send a SCPI command to an instrument and get a response back.
While LabVIEW (and VEE) can deal with IVI-C, IVI-COM, pure sockets, etc., I think there's something to be said for the simple SCPI approach.
I'm admittedly biased, and Agilent would probably prefer to do the opposite of what I think.
What do the rest of you think?
Brian Powell
LabVIEW R&D
""DUNSMORE,JOEL (A-Sonoma,ex1)"" <joel_dunsmore@agilent.com> wrote...
>
> In the latest version of the PNA, on the road to being LXI
>compliant, we just add a sockets server so that you can telnet to the
>PNA over lan, and use your favorite SCPI commands. In vee, it is just
>like Reiner says: set up the Visa and use the to-sockets instead of
>the direct I/O. Of course, you can also use the direct I/O by using
>the PNA computer name as the remote host. Or, if you want to make the
>plunge, you can use the Com/Dcom, and leave that nasty old SCPI behind
>(but we do provide the COM function
> SCPI-parser("command") for the cases where someone wants to use a COM
>connection, but "just wants to send the same old SCPI command").
>Sockets and VISA are handy as you don't need to deal with Com security
>protocals, but once you figure it out, most our our real programmers
>(read that as "microsoft programmers") seem to prefer COM.
>Joel
>
> > -----Original Message-----
> > From: Schlieker, Reiner [mailto:reiner.schlieker@siemens.com]
> > Sent: Thursday, July 06, 2006 6:07 AM
> > To: VRF
> > Subject: RE: [vrf] LXI and SCPI command ?
> > > Yes, we can still use our beloved Direct I/O with the LXI
> instruments > - I wrote a driver for an Agilent 'scope using direct
> I/O after > becoming frustrated trying to figure out the IVI-COM
> driver and having > little time to do it(I thought the newer drivers
> would be EASIER to > use). Once the VISA address is set up, it's the
> same as GPIB.
> > > Reiner
> >
> > > -----Original Message-----
> > From: martin.papproth@nokia.com [mailto:martin.papproth@nokia.com]
> > Sent: Thursday, July 06, 2006 7:49 AM
> > To: VRF
> > Subject: [vrf] LXI and SCPI command ?
> > > Hi all,
> > > LXI (LAN eXtensions for Instrumentation) somehow shows up on
> the > horizon of all (big) test equipment manufacturers.
> > Indeed the setup concept seems quite smart to me; but I still
> wonder > what it means when using existing SW in such a new LXI based
> test > setup.
> > > Specifically: If you have implemented most of your instrument >
> communication upon VEE's DirectI/O objects (talking raw SCPI commands
> > to the device), will there be a possibility to do this with a LXI >
> device as well ? Or do I really have to use some IVI-COM drivers ?
> > > The LXI standard itself only requires an IVI driver, leaving
> the > implementation (either COM or something else) open. So will
> there be a > device vendor specific solution to talk low-level
> commands to the > device ?
> > > Until now in GPIB we loved the simplicity and flexibility of
> the > devices' ASCII commands (SCPI). (It also saved us from buggy
> driver > SW.) We don't even had to bother around synchronizing driver
> versions > across multiple test setups.
> > If we loose this freedom I would really consider it as a downside.
> > > If anyone has some experience or expertise on this topic I'd
> like to > hear from him
> > > thx & br
> > Martin
> > > ---
> > You are currently subscribed to vrf as: >
> reiner.schlieker@siemens.com To subscribe please send an email
> to: > "vrf-request@lists.it.agilent.com"
> > with the word subscribe in the message body.
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email "vrf@agilent.com".
> > If you need help with the mailing list send a message to >
> "owner-vrf@it.lists.it.agilent.com".
> > Search the "unofficial vrf archive" at > "www.oswegosw.com/vrf_archive/".
> > > ---
> > You are currently subscribed to vrf as: >
> joel_dunsmore@agilent.com To subscribe please send an email
> > to: "vrf-request@lists.it.agilent.com" with the word subscribe in
> the > message body.
> > To unsubscribe send a blank email to
> > "leave-vrf@it.lists.it.agilent.com".
> > To send messages to this mailing list, email "vrf@agilent.com".
> > If you need help with the mailing list send a message to >
> "owner-vrf@it.lists.it.agilent.com".
> > Search the "unofficial vrf archive" at > "www.oswegosw.com/vrf_archive/".
> >
>---
>You are currently subscribed to vrf as: hpvee-list@ni.com To subscribe
>please send an email to:
>"vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
>To send messages to this mailing list, email "vrf@agilent.com".
>If you need help with the mailing list send a message to
>"owner-vrf@it.lists.it.agilent.com".
>Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
> or we're about to see a plethora of obscure control languages. I don't
> know which is the more likely.
>
I don't know either. Back when I wrote SCPI, the intent was to provide maintenance through an independent organization (Bode Enterprises). There were supposed to be regular meetings and updates, i.e. it was to be a living document. However, the standard has not been touched since 2000 and people have moved on to the standardized driver instead. Kind of unfortunate, because if SCPI had developed compliance teeth, there would be little need for drivers.
I believe new designers will continue to use SCPI when it is more convenient that doing something themselves. That means some definition of a similar instrument they can easily borrow from. The bigger companies will continue to use SCPI because they invested in parsers and language tools back when it was first introduced.
In retrospect, I wish I had pushed the format sections of SCPI into an IEEE standard. I now believe that was the real contribution and not the standard dictionary that is the bulk of the SCPI standard.
Jay Nemeth-Johannes
Smart Sensor Systems
720 SW 14th Street
Loveland, Colorado 80537
(970) 663-0006
www.SmartSensorSystems.com
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".