I have an old Agilent VISA/SCPI device I want to talk to. I don’t know the name of the device and want to display a list of connected devices/instruments to the user to select from. After the user selects an instrument, I want to connect to it and start sending out VISA/SCPI commands to it.
Ideally, I would like to use PyVisa; however, an attempt to import this resulted in an error about unicode_literals not being available from the future module. I tried updating this future module to include unicode_literals, using the latest version of future from the latest version of jython, but no luck.
Does anyone know how to get PyVisa working?
If no one knows how to get PyVisa working in Jython, what about sockets?
There is an example of someone using sockets here.
…but they already know the name of the device and I need to find a list of connected devices for the user to pick from.
If there are any other options, please suggest them.
In general, python libraries that access native libraries (.DLL, .so) will not (ever) work in jython. However, it is often possible to find java bindings for such native libraries, which can be used in jython. One would use the java examples for such bindings instead of the python examples.
There is a SourceForge project call jvisa that appears to offer what you need if you pursue this approach. If your jython is only going to run in the gateway, you could simply add the files to your gateway’s lib folder with all of the other common jars. Otherwise, you’ll need to package jvisa into a module so its parts get distributed properly to each client.
After looking around a bit, I found that PyVisa has its own implementation of the VISA protocol. This means that it doesn’t need drivers and can operate without them, making PyVisa a viable option since it is pure python code; however, it uses C code - as you mentioned (DLL) - so it won’t work in Jython.
I did try getting JVisa into Ignition, but it didn’t work. Here were my steps:
Go to folder: JVisa_and_JVisaOscilloscope _2.0\JVisa\lib\64bit
Open command prompt in this directory and run: pack200 --gzip -E9 JnaVisa64.jar.pack.gz JnaVisa64.jar to create the jar.pack.gz file needed for Ignition
Go to folder: C:\Program Files\Inductive Automation\Ignition\lib\core\common and paste both the JnaVisa64 jar and jar.pack.gz files
Close any open designers.
Restart Ignition Service: Go to services, right-click, restart. Wait for restart to finish.
Open new designer, go to script console, and try: import jvisa. It says the library doesn’t exist.
By the way, the statements “since it is pure python code” and “it uses C code” are contradictory. Pure python code does not call out to any C code. Whether the DLLs in question are “drivers” or “libraries” doesn’t matter.
You’re absolutely right…python is built on C though, so I kinda think of python that wraps C code as still pure python. This isn’t really right, though.
No, I am still getting no module named jvisa. I tried adding the JnaVisa64_13 and JVisaOneJar as well - with their jar.pack.gz compressed versions as well - but Ignition gave an error for JVisaOneJar, so I removed it and I still could not import the library.
“python” is a language: syntax definition and standard library specification. CPython (the one typically installed as command line “python”), Jython, IronPython, and PyPy (not to be confused with PyPI) are implementations, each with their own native code (.DLL, .so) plug-in requirements. Pure python, as meant in the python community, runs on any of them, invoking just the standard library or other pure python libraries. There are more implementations for special cases, like MicroPython, some of which are not fully compliant with the spec.
Your thoughts on pure python contradict the community, cause confusion in public fora, and create unrealistic expectations (at least for you) of what works where.
I have written a full usable SCPI interface using the SCPI ACSII commands send directly to a raw TCP/IP socket on Aglent/Keysight devices, it’s all run out of the gateway script, and does not use any VISA library, the only down side to all this is it’s slower then native compiled VISA drives, but if you do not need high speed then this approach works very well. If interested this approach I can post some sample code.
Timing is somewhat important. What kind of lag are you seeing relative to using VISA? Average time for running a few commands using one method over the other?
EDIT:
Also, VISA is extremely well-supported by virtually every manufacturer of these devices, but TCP/IP is fairly new and may not be supported. There is always a chance that my company pulls a very old machine and wants to start using it. I would have to go back to using VISA and that would require an external program again that runs Python 3, so I can use PyVisa.
Because I run this on a raw device socket, I’m not sure how fast I could push it, the main item determining speed is how fast you run the scan class for the SCPI tags, right now, using SCPI commands against 34980 Data Acquisition unit I have the scan class set to try a new command every 1/2 second. But you will always get the slower of the scan class or the SCPI device. I read 4 thermocouples at this speed, and when reading 9 it takes just over .6 seconds. But thermocouples are have a lot of overhead in the Data Acquisition, it has to auto range and auto zero the voltmeter, then after taking the reading it has to do a Ohms reading against the Thermocouple to verify there not open. Attached is a screen shot of my debugger screen, where I read 40 T/C’s in, this data is send right to tags. sh
Thanks @ghuck. Since you already have the code setup for TCP, could you try a standard command that should have nothing to do really with your device, like *IDN?
Using this command, maybe 100 times, to benchmark speed would give a clear picture of how TCP and VISA speeds compare.
I wish I could, but all of my SCPI instruments are in production, and since my instance of this is ran all thought the OPC tag system, where I have that scan class set to .5 seconds that would be the maximum speed I would get on my current systems, and since there in production I cannot play with the scan class to turn it up fast enough to make this a throughput test, with out the risk of affecting something in production.
The way I have my systems set up, all commands are templated in a gateway tag change script, I just submit a template number(s) to tag sequencer and it runs all of the templates as fast as it can, but is limited to the scan class tag interval. So if I submitted my template number for this 100 times in the sequencer in my current systems, it would be paced at my scan class rate of .5 seconds right now, which is a design limit of are projects and is no way would be represented on the maximum speed one could get.
TCP/IP worked pretty well…I just tested it. I am using ASCII commands, not binary, so there might be a way to speed it up more. FYI - I am actually using the TelNet server on the analyzer. Anyway, how long commands take varies a great deal when I am working with an E5071C network analyzer using SCPI commands. Send commands, not queries, can be somewhere around 15 ms. Batching of commands is extremely critical…if you combine commands with a semicolon ( and send them all off at once the analyzer can process them really quickly and your average processing time per command drops dramatically. Queries take a long time, unfortunately. A query, regardless of the number of commands almost always takes 400-500 ms before getting a response back from the analyzer. I would avoid running queries, like “:system:error?” or “*opc?”, until you have sent all your setup commands.
Scratch that…telnet works great, but we are switching to another device that is cheaper and purely USB.
Now my solution is to wrap a socket server program around pyvisa, make an exe out of that, download the exe to the host computers from a shared drive, and then just use a socket to talk to it in Ignition…FYI, had to use the java socket lib, because when trying to use the python socket library in Ignition, it took 4.5 seconds to open…brutally slow.
I tried just creating the exe and using python’s subprocess module with command line args to get and send data, but it took a minimum of 400 ms just to spawn the process…even when I was sending a command and not a query, which took ~15 ms when using telnet.
We just the use the Ignition TCP Driver found at the bottom of the add devices page. It’s a persistent connection. Just set the driver Message Delimter type to ASCII, the Message Delimiter, and writeback delimeter to \n
Also to keep SCPI running as fast as possible, use the four letter SCPI commands, and save any return data into the instrument memory and read it back from there. HP use to have a white paper in this subject but I have been unable to locate it, but I will keep looking.
and send them all off at once the analyzer can process them really quickly and your average processing time per command drops dramatically. Queries take a long time, unfortunately. A query, regardless of the number of commands almost always takes 400-500 ms before getting a response back from the analyzer. I would avoid running queries, like “:system:error?” or “*opc?”, until you have sent all your setup commands.