Prema 6048 / GPIB comms?... Or maybe general thread on GPIB readings harvesting

[Rax]

Every time I'm trying to hop on the train of "automated readings" with my current instrumentation, I'm hitting a wall where every single granular issue I need to sort out to make this work opens at least five other tracks of research. I'm not sure exactly what the math of that is, but definitely hyper divergent and non-conducive. I thought I'd start a thread, maybe others in my position may benefit from the input given here by others having walked this path.

Some of my limitations are below. Possibly many in this community have the same as I do.

• I'm not a coder. I can sweat and scratch my head until bleeding a little bit and that'd be OK, but heavy lifting in the coding world, if anything, may be too deep a rabbit hole to make it feasible with my hobbyist time allotment (for one).
• There are a few components involved. Ideally, I'd connect a GPIB adapter such as an NI interface (fairly affordable), and that would then hook up to my bench computer over USB. Then, there'd be some way to harvest, store/organize/compile/compound, then output in some sort of way this data. Both tabulated and plotted in graphs would be ideal.
• So the issue of some sort of software able to talk to the GPIB adapter is a must. Ideally, it'd be agnostic of the instrument itself, though I really have no idea if this is fantasy. For myself, a way to then just make the Prema talk to all the rest is essential.

Does this sound like a reasonable list? Have I at least enumerated most, if not all, of the parts of this conundrum?

All I've been able to accomplish along these lines is to make a 34401A work over RS232 with "Test Controller." A while back, I've used an 8903A with an Agilent 82357B adapter with some free code written by a guy.

What I have handy is a (few) "GPIBUSB" by xypro (?), likely access to some NI adapter, and not a whole lot of time to learn new things, including coding. Sure, maybe also the moon in the sky?...

I've spent most of my Sunday afternoon collecting readings (on a piece of paper, on a pad, etc.) from a 332D with the P6048, and it'd be great to take the sweatshop aspect out of it

[Rax]

I know branadic and dieter1 have great input on this. Maybe I should link their prior posts on here.

[Tony_G]

If you have a 34401A and an 82357B then you should take a look at IanJ's WinGPIB app here on the forum - It probably will do everything you're looking for right now.

https://www.eevblog.com/forum/metrology/3458a-logging-via-windows-app-revisited/msg1974833/#msg1974833

UPDATE:

Rereading what you wrote, it seems you might not have a GPIB adapter for personal use - I'd have to defer to others here on the forum w.r.t how those clone 82357B or NI adapters work (I'm lucky enough to have acquired real versions of them and a GPIB-ENET/1000). That said, if you don't want to do IT/SWDev work to get your stuff to work, then just paying the "tax" to get a VISA-supported adapter (by this I mean one that works with either the Keysight IO Libraries Suite or the NI VISA SW) is probably worth it.

TonyG

[thermistor-guy]

"

Every time I'm trying to hop on the train of "automated readings" with my current instrumentation, I'm hitting a wall where every single granular issue I need to sort out to make this work opens at least five other tracks of research....

If you are hopping on for the first time, then yes, that's how it is.

[Rax]

If you are hopping on for the first time, then yes, that's how it is.

It's probably the tenth, but I get to this point and get utterly discouraged every single time.

[bnz]

...
What I have handy is a (few) "GPIBUSB" by xypro (?), likely access to some NI adapter, and not a whole lot of time to learn new things, including coding. Sure, maybe also the moon in the sky?...

The GPIBUSB by xyphro does not work with "Test Controller"  as  "Test Controller" does not support USBTMC.

With "Test Controller" give the AR488 adapter a try. They work fine.
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/
https://github.com/Twilight-Logic/AR488

[alm]

For a beginner, if you can find an affordable one I'd say something by NI or Agilent / Keysight would be the easiest. Install the corresponding VISA package, and use the built-in tools (Measurement and Automation Explorer in NI-VISA) to test. Make sure you buy something still supported by the current drivers. Check the NI-VISA / Keysight IO suite documentation.

I don't personally have any experience with clones, but I've heard that for some people the clones (at list for NI GPIB-USB-HS) is more reliable than the original.

Another thing you'll need is GPIB cables as soon as you have more than one instrument. If you're patient, you might be able to find them for around $10 before shipping. There's a seller selling 0.5m cables (for instruments stacked right on top of each other for $8.50, though I find 1m cables the most versatile. 

[ch_scr]

I have tried the "knockoff 82357B", the AR488 and the Xyphro. It depends on what you want to do.
If you have pre-made software that dependend on it's drivers or already know LabView, the "knockoff 82357B" is the way to go. (It's shortcomings are described elsewhere, but the usual faults (too thin traces and wrong driver IC) can be relatively easily corrected with a bit of soldering). The drivers are mighty but bloated.

If one has to start fresh anyway, the Python + "diy adapter" is at least cheaper. Which brings us to the question: which one?
If one wants many all instruments on one pc... ask yourself again! For automated stuff, one mini pc "per setup" is IMHO way better (As they are quite small, low power (5-15W) and reasonably expensive (50€ and up) nowadays) : Like that, you can have one thing running without beeing disturbed by another.
The "compute demand" for an python acqusition script is quite small - e.g. an used "Dell Wyse 3040" thin client (the size of 2 pack of cigs) can run it perfectly fine on linux, and do other stuff as well at the same time. newer Intel Atom, Intel N100 - fine!
So I would say "a few" instruments for the home gamer, maybe 5 per experiment is the ballpark number.

With the xyphro, that means 5 usb's running to the one pc! With linux, there are no drivers to install (with windows, there is one) and (for both) they all show up neatly once turned on. In software, they can be addressed by name (if they answer to the IDN? command) automagically. No more fuss, call them by name and send your commands from script. But, one price - no coherent bus trigger as USB has unknown latency.

So what if you don't like to have 5 xyphro adapters and 5 usb cables: AR488 bus master! Even cheaper than "knockoff 82357B", and no drivers (maybe an USB-COM-port driver in windows, depending on the Arduino version used). It shows up as a com port, and there you go. You need GPIB cables, this time!  And you'll need to set individual addresses for each instrument as well. Then look at the AR488 documentation, there is a set of commands (all starting with ++) you send on the com port to tell the bus master which instrument you want to address, among other (initial) settings. That's how you can tell it to do e.g. the bus trigger, SRQ, etc. Once set up it knows which device you want to talk to, you send your stuff on the com port. In your script, you'll have to manage that in addition to device communication itself.

With the "knockoff 82357B", again bus addresses and GPIB cables. But the driver handles the address stuff, discovering bus devices for you, so the script should look a lot like xyphro variant.

Personally I found the xyphro on linux the least problematic, no drivers, no AR488 bus master setup, python and it's libraries installed easily and off to the races.

[branadic]

To me it sounds like Rax is stuck at the very first point, although the step-by-step instructions seem very clear to me.

https://github.com/xyphro/UsbGpib#flashing-the-microcontroller-first-time

...For initial programming an AVR ISP adapter is needed to program the "Bootloader.hex" file.

It is very important, that the Fuses of the AVR are programmed.
Here an example how to program the bootloader using avrdude (using usbasp programmer): avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m avrdude -c usbasp -p m32u4 -U flash:w:BootLoader.hex

After programming the file, disconnect and connect the device and a USB drive will show up. Copy the TestAndMeasurement.bin file to this USB drive - ideally using the command line. Example: copy TestAndMeasurement.bin F:\FLASH.BIN. On Linux, there is a bug with the LUFA mass storage that means it is required to use dd if=TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync.

When done, disconnect and connect USB again and you're ready to use it!

-branadic-

[alm]

I have tried the "knockoff 82357B", the AR488 and the Xyphro. It depends on what you want to do.
If you have pre-made software that dependend on it's drivers or already know LabView, the "knockoff 82357B" is the way to go. (It's shortcomings are described elsewhere, but the usual faults (too thin traces and wrong driver IC) can be relatively easily corrected with a bit of soldering). The drivers are mighty but bloated.
[...]
Personally I found the xyphro on linux the least problematic, no drivers, no AR488 bus master setup, python and it's libraries installed easily and off to the races.

I agree that the software for the "real" GPIB adapters is bloated, and Linux support is not great (note there's a link in my sig for Ubuntu drivers), but I still think getting them to work is easier than a DIY solution where you also have to second guess the hardware. Personally I prefer GPIB-LAN adapters, but finding them cheaply is a real challenge.

[rcjoy]

You first need to decide what software you are going to use, or if you are going to write your own.

If you are going to use software developed by others, then get the GPIB adapter and operating system that is known to work with that software.  Using unsupported or partially supported hardware will lead to endless frustration.

If you are going to develop your own software, then you have more options.  In reality, creating your own software is often pretty easy, using Python, C, or C++.
You don't need to make a fancy graphical interface; often just running a program from the command prompt is all that is needed for data collection and analysis.

If you do go the "write your own software" route, a LAN / GPIB gateway using VXI-11 is easier than USB since you don't need any operating system drivers, works on any operating system, and is fantasticlly convenient.  LAN / GPIB gateways can be expensive new, but keep an eye out on eBay for an Agilent/Keysight E5810 or HP E2050 or ICS 9065.  Bargains come up if you are patient.
 

[thermistor-guy]

If you are hopping on for the first time, then yes, that's how it is.

It's probably the tenth, but I get to this point and get utterly discouraged every single time.

I could write a mountain of material on how to start from nothing, but at the risk of overwhelming you.

Don't get demoralized. What you need is a plan: how to build your system in manageable steps, with each step
giving you something useful.

What helped me, with my particular situation, were some early decisions:

* connectivity: connect all instruments to a LAN; get ethernet-to-serial/GPIB adapters where necessary;
* time vs money: spend my money on test h/w; spend my time writing s/w;
* software: use freely available s/w like GNU tools, that will run on any platform I have available (Linux or Win+Cygwin PCs, rpis);
* track and manage: maintain a list of all the tasks as they come up: past, present, future;
* track and manage ALL the tasks: buying components, writing a piece of code, choosing a new test instrument, installing software on a new platform, whatever;
* track and manage EVERY task: maintain a directory with files that show: what's done so far, what's worked and what hasn't, what to do next, what the actual outcome was;
   this can be simple and brief, or involved and detailed, depending on the task; if it gets too complicated, break it down into sub-tasks and track them;

Start with something you want to do now. What is the simplest, easiest version of it that will give you something useful? As you get into it and make progress,
your ideas for the test system you ultimately want will take shape.

Track what you're doing. It's easy to get lost and overloaded by all the detail. You need a way of working that manages the detail, and avoids cognitive overload.
That way, you maintain your morale, keep making progress, and enjoy the results along the way.

[rcjoy]

Here's a concrete example using Python.

The instruments and interfaces are different from your particular case, but it gives an idea of what is involved.

Here we have a Keithley DMM6500 DMM measuring the voltage output of a Keithley 230 voltage source, for 100 voltage points, and the error between the expected and measured value is reported.

The Keithely DMM6500 is connected to the LAN via its Ethernet port.
The Keithley 230 GPIB port is connected to an Agilent E5810A LAN/GPIB gateway, and the E5810A is connected to the LAN.
The computer running this Python program is connected to the same LAN via Ethernet or WiFi.

Code: [Select]

# ***************************************************************************
# Characterize Keithley 230 voltage source with Keithley DMM6500 DMM
# ***************************************************************************

# python-vxi11
import vxi11
import time

# ***************************************************************************
# Connect to instruments
# ***************************************************************************

# Keithley 230 Programmable Voltage Source at GPIB address 22 via Agilent
# E5810A LAN/GPIB gateway at IP address 192.168.0.70
instr_vs = vxi11.Instrument ("192.168.0.70", "gpib0,22")
instr_vs.clear()                        # Reset

# Keithley DMM6500 multimeter at IP address 192.168.0.66
instr_dmm = vxi11.Instrument ("192.168.0.66", "inst0")
instr_dmm.clear()                       # Reset

# Print DMM6500 ID
print ("DMM ID: " + instr_dmm.ask("*IDN?"))

# ***************************************************************************
# Instrument setup
# ***************************************************************************

# Set up Keithley 230
instr_vs.write ("V0.0X")                # Set voltage to 0 v
instr_vs.write ("I1X")                  # Set current limit to 20 mA
instr_vs.write ("D0X")                  # Display voltage
instr_vs.write ("F1X")                  # Enable voltage output

# Set up Keithley DMM6500 instrument
instr_dmm.write (":disp:screen home_large_reading") # Show large digits
instr_dmm.write (":sens:func \"volt:dc\"")        # DC volts mode
instr_dmm.write (":sens:volt:dc:range:auto on")   # Autorange
instr_dmm.write (":sens:volt:dc:nplc 10")         # 10 NPLC filtering
instr_dmm.write (":sens:volt:dc:inp mohm10")      # 10 Mohm input Z

# ***************************************************************************
# Sweep the voltage source to characterize it
# ***************************************************************************

for i in range (0, 100):                # 100 Points
      # Set voltage source voltage
      v = i * 0.100                     # 0.0 v to 9.9 v
      instr_vs.write ('V{:f}X'.format(v))
      time.sleep (0.1)                  # Wait for voltage to settle
      # Measure with the DMM
      meas = float(instr_dmm.ask (":read?"))
      # Display results
      print ('set: {:7.3f}  meas: {:10.6f}  delta: {:10.6f}'.format(v,meas,meas-v))

# ***************************************************************************
# Clean up and exit
# ***************************************************************************

instr_vs.write ("F0X")                  # Disable voltage output
time.sleep (1.0)                        # Wait for last command to finish

# Close connection to instruments
instr_dmm.close()
instr_vs.close()

And here is an example of running it on the command prompt:

Code: [Select]

% python3 vxi11_test.py
DMM ID: KEITHLEY INSTRUMENTS,MODEL DMM6500,04440477,1.7.12b
set:   0.000  meas:  -0.000038  delta:  -0.000038
set:   0.100  meas:   0.099954  delta:  -0.000046
set:   0.200  meas:   0.199954  delta:  -0.000046
set:   0.300  meas:   0.299912  delta:  -0.000088
set:   0.400  meas:   0.399929  delta:  -0.000071
set:   0.500  meas:   0.499903  delta:  -0.000097
set:   0.600  meas:   0.599974  delta:  -0.000026
set:   0.700  meas:   0.699965  delta:  -0.000035
set:   0.800  meas:   0.799940  delta:  -0.000060
...
set:   9.700  meas:   9.699774  delta:  -0.000226
set:   9.800  meas:   9.799752  delta:  -0.000248
set:   9.900  meas:   9.899662  delta:  -0.000338


[dietert1]

As far as i understand RAX already got a xyphro usb interface and the flasher for it. That GPIB adapter is a bit special. It isn't meant to control a bus but only a single device. It doesn't use bus driver ICs. The software enumerates the usb device only when the instrument responds. So there will be a USB device representing the instrument and not the GPIB interface.
The Prema 6048 doesn't support the *IDN? query. There is optional firmware for the xyphro adapter that doesn't try the instrument ID query.

Regards, Dieter

[ch_scr]

These settings can be written without re-flashing the device. It will show up with a generic name either way, but the Prema might complain about receiving a wrong command (when the Auto IDN? / ID?-interrogate is active). The information how to set is at the bottom of the github page.

[Rax]

As far as i understand RAX already got a xyphro usb interface and the flasher for it.
Regards, Dieter

Yes, I do, and I will be attempting to do this over the weekend. I don't yet have a clear idea how to flash it, but I think I should at least have the hardware I need.

One thing I don't quite know is how to connect the flasher to the ISP header (there's no keying and can go in two ways), though maybe it's just a matter of taking a closer look.

[Rax]

I enclose some pics below. I think my keying of the ISP header connector is by pin 6 as shown on the GPIB PCB image on github and GND on the connector.

[Rax]

The terrible soldering work with no cleaning afterwards - not my handiwork! This is how they sell this stuff on AMZ.

[Rax]

I think I'm in pretty good shape with the ISP dongle. I downloaded AVRDUDE, but I'm not quite sure how to run it. Guaranteed dumb question - I tried running the "command line tool" AVRDUDE from my Windows cmd prompt, and it's not recognizing it: "'avrdude' is not recognized as an internal or external command"

What I tried shooting through the cmd prompt is "avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m avrdude -c usbasp -p m32u4 -U flash:w:BootLoader.hex" as per github instructions.

All this is so cryptic to me. Apologies to the superior humans who have this kinda thing for breakfast.

[dietert1]

On Github one can download a 32-bit and a 64-bit windows version. Unless the PC is old you want the 64-bit version. To install the application you unpack the zip archive to some directory of your choice. Best make a new one. In order to simplify things you can make a copy of the binary file you want to flash in the very same installation directory.
Before you submit the avrdude command, you need to point windows to the installation directory using its path, something like "cd c:\dir1\dir2  ". To do this (navigate first and then invoke) one can use the interactive command prompt (under Start->Programs->Utilities).

Regards, Dieter

[Rax]

Going back for a second to the option of using an Agilent or NI interface - I'm given the opportunity to get a brand new Agilent 82357B or a used NI for probably about $100 (USD). I am pretty confident both genuine, as the source has access to local labs and their retired equipment etc.

What's my best call for universal compatibility and overall ease of use? For instance, it sounds like the used NIs, depending on how old - I'm still looking for find out details on this particular one - may not even function with newer versions of the software.

The Keysight vs. NI software is a whole other topic. I've played with them before, and I recall they're both just massive and really bloated. I'm assuming the learning curve will be steep and long.

[alligatorblues]

-
Rereading what you wrote, it seems you might not have a GPIB adapter for personal use - I'd have to defer to others here on the forum w.r.t how those clone 82357B or NI adapters work (I'm lucky enough to have acquired real versions of them and a GPIB-ENET/1000). That said, if you don't want to do IT/SWDev work to get your stuff to work, then just paying the "tax" to get a VISA-supported adapter (by this I mean one that works with either the Keysight IO Libraries Suite or the NI VISA SW) is probably worth it.

TonyG

VISA is a hardware abstraction layer between software and hardware. It was coordinated by Agilent/Keysight, Keithley, Tektronix, Rhode and Schwartz, NI, Anritsu and Bustec. But any T&M instrument company can use the VISA common components pqckage from IVI Foundation, which presently develops and maintains VISA, and the 3 IVI drivers, IVI-.NET, Which is compatible with Windows .NET framework, Visual Studio, and programmiing  languages C#, Visual Basic, and Visual C++.

The IVI-COM driver that uses Microsoft's C0M platform, and is compatible with software that uses the CompOnentObjectModel

IVI-C, which is nearly universally compatible. Manufacturers use the VISA COMMON COMPONENTS packages, and add functionality, or restrictions, and release it as their VISA implementation. IVI (Instrument Virtual Interface) has a model to which vendors must adhere to in the final development phase of VISA and IVI drivers, in order to use the name VISA, IVI driver, IVI-.NET, IVI-COM and IVI-C.

The set of 3 IVI drivers are available for specific instrument groups, because a DC PSU doesn't require most of the commands available to DMMs. Similarly, signal and waveform generators don't require the same commands as oscilloscopes and network analyzers.

SCPI is a common ASCII-based language that will work with all instruments that have remote connectivity ports. So, the IVI website has a list of every supp9rted instrument. And if you get a package like MatLab, you can get all the hardware drivers too.

[rcjoy]

I'm assuming the learning curve will be steep and long.

If you use Python, you'll be up and running in no time.  Once you have either the NI or Keysight drivers installed, you install PyVISA and you have a simple Python interface to those drivers.

See the examples at https://pyvisa.readthedocs.io/en/latest/introduction/communication.html

[Rax]

If you use Python, you'll be up and running in no time.  Once you have either the NI or Keysight drivers installed, you install PyVISA and you have a simple Python interface to those drivers.

See the examples at https://pyvisa.readthedocs.io/en/latest/introduction/communication.html

I'm slowly getting there. ch_scr has been very helpful and helped getting me started with this. I am at this point able to talk to the P6048 via pyvisa-shell, stroll a bit through the commands available in the Prema software, plus basic Python commands. The xyphro GPIBUSB seems to work without hesitation with the P6048.

I am now trying to figure what would a script putting together the operations I want look like - I'd call it "grasping" at this point.

[Rax]

I think I have a Python script that's currently able to log readings from the P6048... Mind blown.

All credit goes to ch_scr for closely guiding me through this, and dieter1 for giving us some valuable pointers on how to do it (as this particular meter wants it). All I've done is groundwork well below the level of where these two hover.

The Prema 6048 definitely has some peculiarities that needed to be accounted for (or the script simply won't work).