smh123

You are correct - I missed the point of your question

1) I have no idea - I'm not a marketing guru, although I do see many instruments these days that ship w/USB/ethernet and no RS232/GPIB

Knowing that others are designing without RS232/GPIB is the data I was looking for. Thanks.

2) I have no personal experience, but I think it will require you to do some specific programming to interface with the GPIB driver. Just as you'll have to implement some sort of listener/server for TCP/IP and some sort of serial port listener, you'll need implement some sort of GPIB listener. You may be able to do all of this with VISA, but I've never tried . If you can do it with VISA much of the work will already be done.

At this point I'm feeling fairly confident that I won't have to concern myself with any GPIB protocols or even VISA. I think by using one of the adapters I've since run across will take care of all of that - and I sure hope that really does hold true. I will just write my driver to deal with sending / receiving over Ethernet or USB.

3) Don't know of a Java SCPI parser - SCPI shouldn't be that hard to parse and if your command set isn't too extensive you could roll your own. I expect that SCPI parsers are most often embedded in the instrument's firmware so that may be why there aren't many for PC platforms.

Yeah. There aren't too many SCPI commands I need to interpret so it shouldn't be too bad. I thought that all devices HAD to implement ALL the 488.2 commands, but as I look at more devices I see that many actually don't seem to implement the entire 488.2 protocol but rather just what they need. I will take the same approach and just implement what I neeed of the 488.2 protocol. Certainly makes my life easier!

Thanks again for taking the time to respond to my post!

-Scott

As long as you are using VISA as the abstraction layer, this should work. For an instrument that accepts SCPI commands and supports TCP/IP over ethernet, serial, USB, or GPIB, it should be almost as simple as setting the VISA resource name to the correct communication protocol when you add the GPIB interface. For example, the TCP/IP connection string is

TCPIP[board]::host address[::LAN device name][::INSTR]

and the GPIB is

GPIB[board]::primary address[::GPIB secondary address][::INSTR]

just open the VISA session with the correct type and you should be using that communication channel - everything else (you hope) remains the same. The SCPI instruction set you use should not change. Look at the Agilent 34401 instrument driver that ships w/LabVIEW - once you define the VISA session resource, everything downstream is pretty much the same.

Mark

Mark,

Thank you for your reply. I think I wasn't quite clear here. My PC is the device, not the controller. Being the actual device I want to concentrate on device functionality and not on learning any more communication protocols than I have to. I know I will have to implement a SCPI parser at a minimum. With that said, my questions really are:

1) Do I need to implement anything other than SCPI over (TCP/IP) ethernet or USB to be a viable product in the marketplace?

2) Could I just use a GPIB -to-Ethernet or GPIB-to-USB adapter to connect my device to an existing cluster of devices that are connected via GPIB?

3) Another question: Are you aware of an availableJava language SCPI parser?

I'm just now trying to get up to speed on instrumentation products / protocols, etc. , so if my questions aren't precise forgive me.

Scott

Hi,

I'm posting this question here because I don't know where else to post it.

I want to implement a new device on my PC to take some measurements. Remote control will be via SCPI so it can play in connected environments. From my research it appears to me that I can just send SCPI text out over the USB comm port or Ethernet. If the device needed to play in a GPIB connected environment then all I would have to do is purchase either a USB - to - GPIB, or Ethernet -to- GPIB connector. Is this a correct assumption on my part? I want to make sure there is not another layer of software that needs to be implemented.

-Scott