AD007 GPIB-Ethernet Interface Java etc

[ralphrmartin]

Just got myself an Ad007 GPIB-Ethernet Interface for £20. I'd like to try programming it in Java, and I have found some examples which rely on libraries IEEE488.jar and RemoteTea.jar. Does anyone one here have those libraries they might be able to send to me?

Failing that, I suppose I could use python instead. Has anyone got some good suggestions where to start if I go down the python route?

Thanks!

[digi]

The pyvisa library works well if you're going to use python: https://github.com/hgrecco/pyvisa

[alm]

As far as I know NI or other VISA vendors do not offer an official Java API. So you either need a way to interface with gpib32.dll (direct GPIB interface) or VISA. I imagine this is possible through JNI, but I am not aware of any popular implementations. There are some obscure ones like this one, but I have no idea about quality or support.

Based on this, I would argue that Java is not the ideal language for this. Does not mean you can not make it work, but it will likely take more time and effort than either using a language that can use the official APIs (Labview or C) or that offers well supported bindings developed by third parties. I believe PyVisa is quite popular, so I would expect it to be reasonably functional and well documented.

[ralphrmartin]

As far as I know NI or other VISA vendors do not offer an official Java API. So you either need a way to interface with gpib32.dll (direct GPIB interface) or VISA. I imagine this is possible through JNI, but I am not aware of any popular implementations. There are some obscure ones like this one, but I have no idea about quality or support.

Based on this, I would argue that Java is not the ideal language for this. Does not mean you can not make it work, but it will likely take more time and effort than either using a language that can use the official APIs (Labview or C) or that offers well supported bindings developed by third parties. I believe PyVisa is quite popular, so I would expect it to be reasonably functional and well documented.

The whole point of using Java (or Python) is to try avoiding use of DLLs (I'm using a Mac) or VISA. The Jvisa driver you linked to doesn't support ethernet devices, unfortunately. By using an Ethernet device, rather than a USB one, this surely should avoid the issue of needing a USB driver, and instead it should be just a matter of  UDP messages, hopefully. PyVisa does sound more hopeful, though. I'll check it out.

[BloodyCactus]

i have both somewhere. remotetea is on gihub, just download + build it. the ieee488 source is around too. i know I have it at home.

[alm]

The whole point of using Java (or Python) is to try avoiding use of DLLs (I'm using a Mac) or VISA

Is it? So how do you call any functionality from software (e.g. the OS) that is not written in Java? If you are using a fruity computer, just substitute libvisa.so.X for visa.dll. VISA is the industry standard for any sort of instrument communication. The advantage is that the API is the same, regardless of the method of connecting to the instrument. So changing from a PCI GPIB card to a GPIB-ethernet bridge, or a USBTMC connection, or RS-232, or LXI is just a matter of changing the connection string. NI-VISA is a popular implementation, but there are others.

PyVisa is just another wrapper that calls a VISA implementation (either NI-VISA or PyVisa-py). PyVisa-py has fairly limited device support, but I believe you can use VXI-11 devices (which likely includes the AD007) without NI-VISA that you seem to want to avoid for some reason.

i have both somewhere. remotetea is on gihub, just download + build it. the ieee488 source is around too. i know I have it at home.

I like software be maintained, so I personally would not be happy with dependencies that seem to have disappeared from the Internet.

[ralphrmartin]

The whole point of using Java (or Python) is to try avoiding use of DLLs (I'm using a Mac) or VISA

Is it? So how do you call any functionality from software (e.g. the OS) that is not written in Java?

Java has a standard networking stack, so should be able to talk to any TCP/IP connected device. And I know GPIB is pretty simple, as about 35 years ago, I wrote some BASIC programs on a Commodore PET to control some GPIB instruments - without needing a VISA dll...

If you are using a fruity computer, just substitute libvisa.so.X for visa.dll. VISA is the industry standard for any sort of instrument communication. The advantage is that the API is the same, regardless of the method of connecting to the instrument. So changing from a PCI GPIB card to a GPIB-ethernet bridge, or a USBTMC connection, or RS-232, or LXI is just a matter of changing the connection string. NI-VISA is a popular implementation, but there are others.

OK, I see your point, and I can see the advantage of this high level of abstraction, if you are going to write something complex which must interact with many instruments in a device independent way. However, it comes at a price. I just want to control an old GPIB bench meter.

PyVisa is just another wrapper that calls a VISA implementation (either NI-VISA or PyVisa-py). PyVisa-py has fairly limited device support, but I believe you can use VXI-11 devices (which likely includes the AD007) without NI-VISA that you seem to want to avoid for some reason.

i have both somewhere. remotetea is on gihub, just download + build it. the ieee488 source is around too. i know I have it at home.

I like software be maintained, so I personally would not be happy with dependencies that seem to have disappeared from the Internet.

Agreed. I shall look at PyVisa - and will load the NI implementation of VISA for the Mac. But without wanting to start a programming language war, Python is not my favorite language...

(And yes, I do teach an MSc course comparing programming paradigms and languages as my day job...)

[ralphrmartin]

i have both somewhere. remotetea is on gihub, just download + build it. the ieee488 source is around too. i know I have it at home.

Thanks. I'll PM you my email address if you could send them along please.

[alm]

Java has a standard networking stack, so should be able to talk to any TCP/IP connected device.

The Java networking stack is a wrapper around the OS native socket functions that live in libc.so. So in the end you are still calling native code, just with a nice Java API wrapper around it. The jvisa stuff is likely an (incomplete) version of the same for libvisa.so.

I am not trying to steer you to any particular programming language, which is why I also suggested C and Labview in my first post (these are the languages NI supports, although I am not 100% sure if the AD007 is still supported by modern NI-VISA releases). But if you have a CS background, then you are not likely to like G (the Labview programming language) either. Any other language that can easily call native code, like Objective C or Pascal, should also work fine.

For many problems there is no compelling reason why languages with similar paradigms are superior to each other. Static typing versus duck typing is not going to save you hours in controlling your DMM. You could easily write this software in C#, or Perl, or LISP. You could grab the VXI-11 specification and implement it on top of basic sockets. But having the correct libraries can save a lot of work. And that is were either the official NI stuff, or well-maintained third-party stuff, have an advantage. Python seems quite popular for instrument control at the moment, and hence has a decent number of third-party packages (e.g. PyVisa, PyVisa-py, python-vxi11, python-ivi).

Not sure what the state of Jython is these days, but it might even be possible to call the pure Python code running in Jython from Java .

[ralphrmartin]

Well, so far I have found 2 reasons not to like NI-VISA (on a Mac, at least)
- there isn't a version for the current version of MacOS (which has already been out for 6 months or so)
- their examples fail to build after installation - the linker fails to find the NI-VISA libraries.

While I agree that using unsupported / not recently updated java libraries may not be the best plan, neither is using not recently updated, incompletely tested software from a major vendor.

[alm]

So I guess that leaves the Python stuff . At least for the Ethernet stuff there should be no problems running them on any platform supported by CPython.