AR488 Arduino-based GPIB adapter

[james_s]

It does indeed work very well, and I appreciate this being created and released to the public. I can manually coerce the TDS410 into spitting out the HPGL which I can then save into a text file and load it up in the plotter emulator and it renders perfectly so the problem is just getting the emulator to convince the scope to start sending the data.

[KE5FX]

Well I'm happy to do some regression testing on a build, I have a HP 8594E and a handful of Tek scopes, TDS300, TDS400, TDS700 and TDS3000, all with GPIB. Pretty sure the 3000 only supports printers but I know for sure the 400 supports plotters and the 8594E works perfectly to plot with the current software.

Have at it

[WaveyDipole]

I don't know if it's relevant with the 8593A, but all this talk of "printer addresses" makes me wonder if it's set up for plotter output or printer output.  You need to make sure it's set up for plotter output, if there's a choice.  There is some support for a couple of printer formats in 7470 but it's not well-tested (at least by me) and may not behave as expected.

Thanks for pointing this out. I have updated my post #396...

The code always sets up ++auto 0 or ++auto 1 based on whether the application calls for device mode or controller mode, but it sends a ++auto query in both cases, as observed above.  Arguably I shouldn't be doing that if the adapter is being used in device mode.  I'll tweak the GPIB_connect() code to set up auto-read mode only if device_address is valid (i.e., if we're using controller mode).  Will also enable ++lon transmission for the listen-only case in device mode, on adapters where the firmware supports it.  The only problem is that I'm perilously short on time for regression testing right now...

Thanks for being willing to do this.

[WaveyDipole]

James, just wondering whether you have been able to try my suggestion in post #389, i.e. placing the interface in LON mode manually prior to launching and using the 7470 program? You can do this with the following commands:

++mode 0
++lon 1

I would be interested to know whether that allows the TDS420 to communicate with the interface. If you first connect to the interface with a terminal, then you should see some output without having to enter a ++read command. If that works, then try and connect with the 7470 program with the 'No assigned plotter address'  option. There is a possibility that it may take a while or time out as entering commands while in LON mode is a bit slow, but I would be interested in whether it works in principle.

[tom_iphi]

Hi,

I have repeated the tests with the HP8593E and found that I previously made a stupid mistake. The plotter address was set to 5 but the instrument was configured for printer out. Now, having changed the instrument to plotter out I get encouraging results:

1. Original Prologix adapter + 7470.exe:
Instrument initiated plots work flawlessly now.

2. AR488 USB version 0.48.08 + 7470.exe:
Data is coming in in chunks, the plot builds up, but at the end of plotting 7470.exe crashes with error message "GPIB error, Read Error: 0x2 (communications error)".
On closing the error message window, 7470.exe closes also.
After this, the AR488 is no longer responding, it has to be power-cycled. So, the firmware seems to hang at the end of the received data.

[tom_iphi]

Have tried Debug5 on the AR488 side.
See attachnment. With a terminal this works repeatedly, no hang.
Hang only occurs with the 7470.exe.

[WaveyDipole]

Hi,

I have repeated the tests with the HP8593E and found that I previously made a stupid mistake. The plotter address was set to 5 but the instrument was configured for printer out. Now, having changed the instrument to plotter out I get encouraging results:

1. Original Prologix adapter + 7470.exe:
Instrument initiated plots work flawlessly now.

2. AR488 USB version 0.48.08 + 7470.exe:
Data is coming in in chunks, the plot builds up, but at the end of plotting 7470.exe crashes with error message "GPIB error, Read Error: 0x2 (communications error)".
On closing the error message window, 7470.exe closes also.
After this, the AR488 is no longer responding, it has to be power-cycled. So, the firmware seems to hang at the end of the received data.

Thanks for the report and additional dump data which I will have a look at.

[james_s]

James, just wondering whether you have been able to try my suggestion in post #389, i.e. placing the interface in LON mode manually prior to launching and using the 7470 program? You can do this with the following commands:

++mode 0
++lon 1

I would be interested to know whether that allows the TDS420 to communicate with the interface. If you first connect to the interface with a terminal, then you should see some output without having to enter a ++read command. If that works, then try and connect with the 7470 program with the 'No assigned plotter address'  option. There is a possibility that it may take a while or time out as entering commands while in LON mode is a bit slow, but I would be interested in whether it works in principle.

I have not, I've been busy with work this week but I should have a chance to do that this weekend.

[KE5FX]

I have repeated the tests with the HP8593E and found that I previously made a stupid mistake. The plotter address was set to 5 but the instrument was configured for printer out. Now, having changed the instrument to plotter out I get encouraging results:

Not stupid at all, very common and easy to overlook (which is why I mentioned it!)  Been there, done that...

1. Original Prologix adapter + 7470.exe:
Instrument initiated plots work flawlessly now.

Host-requested plots should work as well, with the analyzer in addressable or talk/listen mode (typically at address 18).

Running the analyzer in addressable mode has the substantial advantage that you can use SSM as well as 7470.  In general, you want to use device-initiated plots only on instruments that don't have support for host-requested plots (or if your adapter supports only device mode.)

[tom_iphi]

Hi John,
I have done host requested plots with 7470.exe for years. That's what I bought the Prologix for. This also works flawlessly with the AR488, except for the Bluetooth delay issue that we had discussed before. This thread just made me curious if device initiated plots work, too. And, yes, if you do it right it works. Prologix + 7470.exe works fine, but the AR488 crashes on that.
Best regards,
Tom

[WaveyDipole]

I have been working on setting up a test fixture to emulate a device sending a plot over GPIB. I have one interface on the GPIB bus in controller mode to act as the 'device' and a second in device mode to act as the receiver.  I have written a python script to read one of the plot files supplied with KE5FX GPIB tools and to send its data via the controller interface over GPIB to the one acting as receiver in device mode. The idea is to emulate an instrument initiated plot, presently using addressed mode as per the HP8519. Since we are sending binary data via serial, the python script takes care of escaping the necessary characters as well.  For now, I am observing the output on the receiving end with a terminal program rather then the 7470 program, but a couple of problems have come to light. Having first overcome some difficulty with the python script due to the way that Arduino resets itself when a connection is made to its serial port, I am now working on them and making some progress. I am therefore hopeful that the problem with the HP8591 device initiated plot will be resolved fairly soon.

[WaveyDipole]

It seems that at the receiving end, these there are least these two issues:

1. The HP plot file contains CRLF sequences which are being interpreted as line terminators
2. In device mode there is currently no way of reading with EOI signal as terminator

Both of these factors mean that the plot data is being broken up by unexpected "terminators".  I have uploaded a test release which is an attempt to fix these tow issues here:

https://github.com/Twilight-Logic/AR488/blob/master/src/test/AR488.test.20200226.zip

There also seems to be a problem in using an Arduino as a test fixture to send the plot data which I suspect is related to the fact that there is no handshake control on boards with the CH340 chip. From the GPIB trace it would appear that chunks of data are missing when "large" volumes of data (presumably exceeding the 128 byte buffer size) are sent consecutively without pause, although what is actually getting sent over GPIB is being received on the receiving interface in device mode. This makes it rather difficult to test the transmission of the plot properly. Sending a plot directly from an instrument would avoid this particular problem so I am hoping that the linked version will now work for HP8591.

It would be appreciated if someone could test it for me.
I need to  get myself an instrument that can display plots! Its a shame that my PM3094 does not have GPIB.

[kc9qvl]

Got it working with a Fluke 8840a 

[tom_iphi]

Hi,
I have just tested the new version 0.48.10, unfortunately no improvement, rather the opposite.
I have used the HP8593E to send instrument initiated plots to the adapter configured as plotter on address 5 by 7470.exe.
While 0.48.08 does receive plot data which 7470.exe does display (but the adapter stalls at the end and no longer responds to commands), 0.48.10 does not receive any data from the instrument.
For reference I have logged com port traffic of 0.48.08 and a real Prologix on this test, see attachment.
This is all the traffic going on with 0.48.10:

Code: [Select]

++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Best regards.

[WaveyDipole]

Tom, thanks for trying. I was rather puzzled that you got no data at all when using version 0.48.10 as in my tests I was able to receive data with both versions but 0.48.10 did not crash. However, there is a possibility that I messed up and left the AR488_Config file in a state where pin 6 is being used by the SN7516 chipset support which will be a problem since, if I recall, you have a 32U4 board? If that is the case then I apologise. Have a look at the AR488_Config.h file and if necessary change the line:

#define SN7516X

to this:

//#define SN7516X

I also noticed realised that I hadn't set the Mega2560 layout option back to default, but that should not affect the 32U4. I have updated the AR488_Config.h and uploaded the ZIP archive again.

It is also possible (and probably likely) that my setup does not accurately replicate the operating conditions with a real instrument and that therefore some aspect of the transmission process has been overlooked. Its a bit tricky working "blind" like this so in that case, please bear with me. I did see a TDS420A on eBay for around 200GBP, but it looked rather battered. I can't afford or justify the HP8591 at this time but I will do my best to get this working if possible.

[grizewald]

Can someone help me to keep the remaining hair that I have? I'm having a problem with an Agilent 34401A which is rapidly leading to me tearing my remaining hair out.

I've been using my AR488 to great effect running logging from my Solartron 7061. Having recently acquired an Agilent branded 34401A, I wanted to experiment with logging voltage readings from that.

I have a shell script which I use to handle the communication to and from the AR488 and also fetch data about temperature and humidity to combine with the readings from the meter. This script has been working perfectly with the 7061. So, I read through the 34401A's manual and set the meter to read voltage via the SCPI commands. I issue the following commands:

"++addr 7"
"*RST"
"*CLS"
"CONF:VOLT:DC 10, MAX"
"VOLT:DC:NPLC 10"
"INP:IMP:AUTO ON"
"++auto 2"

I can then enter a loop and issue "READ?" commands and receive a result back for each READ?

So far, so good.

Then I change just one tiny thing:
"VOLT:DC:NPLC 10" -> "VOLT:DC:NPLC 100"

With 100 NPLC, READ? returns me nothing at all.

I'm obviously missing something about how the 34401A works, but I can't for the life of me figure out what it is. Has anyone else managed to get readings at 100 NPLC over the GPIB interface?

[grizewald]

Answering my own problem here, just in case someone else bumps into it.

Adding "++read_tmo_ms 25000" gives enough time for the read to complete without timing out.

 

[T3sl4co1l]

Heh, I noticed that with my TDS460 in plot (HPGL) mode -- it seems to take a few seconds to think, from time to time, and at first I had to issue repeated +read's to get everything.  Duh, it was just timing out.

Tim

[tom_iphi]

Hi John,

there is a possibility that I messed up and left the AR488_Config file in a state where pin 6 is being used by the SN7516 chipset

Indeed, you were spot-on.
I have commented out as instructed and now 7470.exe does receive plot data again. But the AR488 firmware still stalls at the end causing 7470.exe to crash, see attached screenshot. After the stall the 32u4 USB CDC port is still present, but no longer answers to commands like ++ver.
I have also attached logged com port traffic. The last ++ver command not being answered seems to cause 7470.exe to fire the error message and abort.

I know it is close to impossible to track this problem down without more detailled information, something I might be able to help with.
I do have a Saleae Logic 16 logic analyzer here, which I can hook up to the GPIB port and I can record a whole sequence. It seems I can also save a measured sequence to a file. The Saleae software appear to be available to the public for free. If you can install the software and import my measurement data, then you could have a direct look at what's going on on my GPIB bus.

Best regards, Tom

[tom_iphi]

Hi John,
I have played with my logic analyzer and indeed, you should be able to look at the traces.
I am running the Saleae Software "Logic 1.2.18", see here: https://www.saleae.com/de/downloads/.
Attached two traces for comparison, one with the original Prologix adapter, the other with the AR488 v0.48.10.
Both show an instrument initiated plot sequence.
This is what I did:
1. I put 7470.exe to listen to address 5.
2. I started capturing (no triggers used)
3. About 1 second after start of capture I pressed the copy button on my HP8593E.
So, both traces should include this communication between PC and adapter, but of course only show the GPIB bus side of it:

Code: [Select]

OP;
  250,279,10250,7479
PU;SP1;LT;;PU;PA80,7096;PD...
  ++auto 0
  ++loc
  ++ver
Prologix ...
Indented traffic is from PC to adapter.

Interesting first observation: After 7470 sends the OP-coordinates, the Prologix answers a lot quicker (few seconds) than the AR488 (about 10s) with the plot data. May there be a timeout in play?
Pin assignment is shown in the logged traces. Hope you can learn something from my data.
Best regards, Tom

[WaveyDipole]

Answering my own problem here, just in case someone else bumps into it.

Adding "++read_tmo_ms 25000" gives enough time for the read to complete without timing out.

 

Glad you figured it out, although I am a little puzzled that it requires a delay quite that long. 100 AC power cycles at 50Hz would take 2 seconds to complete so no more than 2500 - 3000 milliseconds to allow a bit of headroom but I am not familiar with the meter and am not aware as whether there are other factors at play.

Hi John,

there is a possibility that I messed up and left the AR488_Config file in a state where pin 6 is being used by the SN7516 chipset

Indeed, you were spot-on.
I have commented out as instructed and now 7470.exe does receive plot data again. But the AR488 firmware still stalls at the end causing 7470.exe to crash, see attached screenshot. After the stall the 32u4 USB CDC port is still present, but no longer answers to commands like ++ver.
I have also attached logged com port traffic. The last ++ver command not being answered seems to cause 7470.exe to fire the error message and abort.

I know it is close to impossible to track this problem down without more detailled information, something I might be able to help with.
I do have a Saleae Logic 16 logic analyzer here, which I can hook up to the GPIB port and I can record a whole sequence. It seems I can also save a measured sequence to a file. The Saleae software appear to be available to the public for free. If you can install the software and import my measurement data, then you could have a direct look at what's going on on my GPIB bus.

Best regards, Tom

Tom, thanks. I do have the Saleae software installed, but I generally use the Sigrok GPIB Analyser to analyse traffic on the GPIB bus as it can display the decoded data with the trace.

Last night I had the idea to encode the plot data into the sketch and send it on demand with a ++ command. I now have this working and it avoids the problems I was having due to a lack of serial handshaking at the sending end while trying to use a python script to send data over a serial connection. I have been able to confirm that all plot data is now being correctly sent over the GPIB bus to its destination and received correctly by the receiving interface.

However, I then ran into further problems when I switched to Windows to try the 7470 program. After confirming that data is still being transmitted correctly by using the PuTTy terminal, I discovered that although the GPIB Configurator functions fine and identifies the interface and I updated my config.ini, the 7470 program will not communicate with my Uno. I had to defeat the Arduino reset on serial connection with a 10uF capacitor between RESET and GND which resolved this problem. The 7470 program now communicated with the interface and after selecting 'Plotter addressable at 5' from the GPIB menu and selecting 'Wait for device-initiated plot' now shows a red message stating that it is waiting for a plot. So far - so good.

As an aside, I had noticed this phenomenon when I was writing my python script to communicate with the Arduino interface. A two second delay is required to allow the Arduino to reset and reboot, otherwise the script ends up interrogating the bootloader instead and gets no response. I imagine that this does not affect the 32u4 in the same way since the 32u4 does not reset the MCU when a serial connection is made as it does the Uno, Nano and Mega2560.

Next comes the weird part. When I sent the plot and not getting anything in the 7470 program window, I could see in the serial monitor that the received data was now getting garbled. To cut a long story short, after numerous re-boots of the Arduinos and my PC and the problem persisting, I eventually discovered that the problem occurred after connecting the capacitor and seems to happen only while one of my USB hubs is connected. Removing the USB hub from the loop got things back to a sane state and I was then rewarded with my embedded plot appearing in the 7470 program. I repeated the process two or three times just to be sure.
 
Incidentally, I notice that the 7470 program sends a ++loc after the plot has been received? The ++loc command is not supported in device mode. When operating as a device, the interface cannot exert remote control over an instrument so in this context the ++loc command appears to be superfluous and the 'Unrecognized command' can be safely ignored.

I will have a look at your Saleae log data to see what I can learn. Regarding the delay, I'm not sure about the reason for this at present, but in my test I counted approximately 3 seconds to the red "Reading data..." banner and then 4 seconds after hitting <return> at the terminal for the plot to appear in the 7470 program. My next step is to repeat the process with the 32u4 using the Uno as the sender in case the problem specific to the way that the 32u4 handles serial ports. I will let you know how I get on.

[grizewald]

Answering my own problem here, just in case someone else bumps into it.

Adding "++read_tmo_ms 25000" gives enough time for the read to complete without timing out.

 

Glad you figured it out, although I am a little puzzled that it requires a delay quite that long. 100 AC power cycles at 50Hz would take 2 seconds to complete so no more than 2500 - 3000 milliseconds to allow a bit of headroom but I am not familiar with the meter and am not aware as whether there are other factors at play.

Yeah, I'm a little puzzled by that as well.

I think I need to experiment with the ++eor command as I suspect that readings are being delayed until the ++read_tmo_ms timeout expires. My initial problem was caused by the default timeout being shorter than the reading time, so I set it very high to allow plenty of time for the result to arrive, hoping that when the reply arrived, it would be sent back immediately.

The meter's documentation says nothing about what characters it uses to signify the end of a transmission or whether it uses the EOI line for this.

[WaveyDipole]

I think I need to experiment with the ++eor command as I suspect that readings are being delayed until the ++read_tmo_ms timeout expires. My initial problem was caused by the default timeout being shorter than the reading time, so I set it very high to allow plenty of time for the result to arrive, hoping that when the reply arrived, it would be sent back immediately.

The read_tmo_ms parameter specifies how long to wait for data to arrive so it its timing out then nothing is arriving, but your suspicion could be correct if it is waiting for the preceding command to finish. Out of curiosity, have you allowed for a delay after "*rst" to allow time for the instrument to reboot?

The meter's documentation says nothing about what characters it uses to signify the end of a transmission or whether it uses the EOI line for this.

Having had a look through the manual myself I tend to agree. I also found very little information regarding this subject and no actual mention of EOI with reference to the signal line. I did find a section called "Output data formats" at the bottom of page 159 which seems to suggest that a combination of CR and NL are used depending on whether single or multiple results are returned but that was about all. Perhaps it is not neccessary with SCIP sequences so is not implemented? Maybe someone on the Keysight forum will be able to provide that answer.

[WaveyDipole]

Interesting first observation: After 7470 sends the OP-coordinates, the Prologix answers a lot quicker (few seconds) than the AR488 (about 10s) with the plot data. May there be a timeout in play?
Pin assignment is shown in the logged traces. Hope you can learn something from my data.
Best regards, Tom

Tom, I had a look at the traces this morning and thank you for providing them. As you point out, it is evident that the Prologix trace shows the plot data being sent within a couple of seconds whereas with the AR488 there is a gap of about 8 seconds. I did also note a couple of small differences, for example the Prologix trace has an additional EOI pulse just before the plot data begins. I'm not sure as to the reason for this at the moment nor can I be sure whether its being generated by the Prologix or the instrument, but I suspect the latter.

I noticed this response from Tim:

Heh, I noticed that with my TDS460 in plot (HPGL) mode -- it seems to take a few seconds to think, from time to time, and at first I had to issue repeated +read's to get everything.  Duh, it was just timing out.

Tim

Could I therefore ask whether that delay is consistent or just occasional?

I also did a test with the 32u4 and found that it worked fine. After setting an appropriate version string, there were no issues with the 7470 program being able to recognize the interface as I encountered with the Uno. Once the version string is set to something appropriate, the 7470 program recognizes it without a problem. The steps I used are as follows:

• File => clear all visible plots
• GPIB => Plotter addressable at 5
• Acquire => Wait for device-initiated plot
• wait for the RED "Reading data from instrument..." banner to appear
• send the plot
• wait for the plot to appear

Finally, if the red banner appears again, press "Press any key to return to display mode". It times out after a while anyway.

Could I confirm that you are using the same procedure?

It could be that the instrument is doing something different to my test method which is not being accounted for so I plan to study the traces further and well as capture some traces from my test fixture for comparison.

[grizewald]

The read_tmo_ms parameter specifies how long to wait for data to arrive so it its timing out then nothing is arriving, but your suspicion could be correct if it is waiting for the preceding command to finish. Out of curiosity, have you allowed for a delay after "*rst" to allow time for the instrument to reboot?

Yes, there's a two second delay after sending the *RST command.

When the AR488 code is waiting for a reply, I assume it is looking for the character(s) or signal specified by ++eor to decide when to send the contents of the buffer back through the serial port. Is that correct? If so, then I'm assuming that the result is already received on the Arduino, but because the terminator hasn't been detected yet, the buffer won't be sent until either the terminator arrives, or the timeout expires.

I'm basing this guess on the fact that my readings appear to be spaced out in read_tmo_ms increments. If my guess is wrong, please let me know!

Finding anything specific about how the meter uses GPIB is virtually impossible as any search string with "34401A" in it returns acres of irrelevant results from vendor sites and online copies of the manuals.  Your suggestion of going to the Keysight forum and asking there is probably the best idea.