AR488 Arduino-based GPIB adapter

[WaveyDipole]

The hardcopy format is correct, the scope sends HPGL and the plotter emulator renders it just fine. The problem is that the line that tells the scope to start sending does not assert when the plotter emulator is set to listen on all addresses. The TDS400 series only support hardcopy in talk-only mode and do not address a plotter at a specific address.

Thanks for confirming that. If you are using talk-only mode, then the receiving interface would need to be in listen-only mode (++mode 0, ++lon 1)? In which case the interface will sit in listening mode with NRFD and NDAC asserted indicating that it is ready to receive data. When characters are transmitted from the instrument in talk-only mode via the GPIB bus it will receive them using the usual three-way handshake process. There is no signal as such to tell the instrument to start sending.

I had a look at what the KE5FX 7470A program is sending to the serial port:

Plotter addressable at 5:

++ver
AT488 GPIB-USB version 4.99

++auto
Unrecognized command

++eos 0
++mode 0
++addr 5
++eoi 1

No assigned plotter address:

++ver
AT488 GPIB-USB version 4.99

++auto
0

++auto 1
++eos 0
++mode 0
++eoi 1

What is interesting is that, in neither case does the software request a '++read'. In the 'Plotter addressable at 5' instance, the instrument gets addressed (++addr 5) so it is possible that it might automatically send data back to the controller address.

However, in the 'No assigned plotter address' instance, since the instrument is in talk-only mode so cannot be addressed, but the interface is not being set into listen-only (++lon) mode. It is being set into device mode (++mode 0) with ++auto 1 and there appears to be nothing here to trigger the sending of data from the instrument. In device mode without ++lon, the interface will sit idle until addressed by the controller. It does not expect to be communicated with by another device. Maybe the Prologix implementation is different in this respect and receives data from an instrument even when the interface is placed in device mode in a similar fashion to ++lon mode, but then why have a ++lon mode?

I am not sure whether my implementation needs to be adjusted, or whether the HP7470A plotter program needs to handle this differently, but I am willing to work with the author of the KE5FX suite of programs to resolve this.

Incidentally, I noted also that I seem to be randomly getting an 'Unrecognized command' after the '++auto' command is sent. I am not sure why at present but probably down to timing. I will need to investigate this further.

[tom_iphi]

@WaveyDipole

Hi,

I have noticed that you have uploaded new AR488 ESP8266 firmwares.
I have played with them today but was having problems.
The last firmware that works for me is 0.04.06 which is the one that I tested and reported about in February.
I have found a version 0.04.10 packed within a recently downloaded AR488 package.
I have also found 0.04.11 indicated here https://github.com/Twilight-Logic/AR488/blob/master/src/AR488-ESP8266-addon/AR488-ESP8266-addon.ino, but the source code says it is version 0.04.10!?
Anyway, I could neither connect to 0.04.10 nor 0.04.11 in AP mode until I un-commented the line

Code: [Select]

#define DISABLE_SSL.
Then I could connect but I couldn't switch to client mode, it wouldn't connect.
Any idea what I am doing wrong?

Btw, meanwhile I got some pcbs made, see attachment. And one more strange find. Remember the odd upload error which I always saw when uploading to my ESP-01? When uploading to my new homemade ESP12F board, the error won't occur. This is absolutely repeatable.

Best regards

[WaveyDipole]

I have also found 0.04.11 indicated here https://github.com/Twilight-Logic/AR488/blob/master/src/AR488-ESP8266-addon/AR488-ESP8266-addon.ino, but the source code says it is version 0.04.10!?

My apologies, it was an omission on my part with the upload which I have now corrected. Version 0.04.11 is now available.

Anyway, I could neither connect to 0.04.10 nor 0.04.11 in AP mode until I un-commented the line

Code: [Select]

#define DISABLE_SSL.
Then I could connect but I couldn't switch to client mode, it wouldn't connect.
Any idea what I am doing wrong?

Apologies if this seems a silly question, but are you using the https:// prefix rather than http:// to connect? The sketch will use SSL (https) by default unless '#define DISABLE_SSL' is uncommented. Please note that when using SSL, the browser will show a security warning because the included SSL certificate is not CA approved. It is necessary to click the 'Ok to proceed at own risk' link at which point the browser should allow you to connect. One further point to note is that after adding SSL, I found that occasionally Firefox would block the CSS formatting and JavaScript and you end up with a plain text on a plain white page. I'm not sure why this occurred, but Chromium rendered the pages with no issues. I have not had the opportunity to test with Internet Explorer/Edge yet.

I am not sure why there is a problem switching to client mode when '#define DISABLE_SSL' is uncommented as this only disables the SSL layer so that the pages are presented in plain text. Disabling SSL should not affect the underlying functionality. Please let me know whether this also happens with version 0.04.11. In the meantime I will also test it again myself in case I had missed something or adding https has somehow broken something.

Btw, meanwhile I got some pcbs made, see attachment.

Thanks for the photo. That's an interesting setup with the ESP8266 "piggy backed" onto Artag's Pro Micro arrangement.

My next step in the WiFi side of things will be to migrate the code to the ESP32. This module appears to have sufficient GPIO pins to drive the GPIB bus directly so theoretically a separate Arduino board would not be required. Migration of code and testing is needed to confirm that though.

And one more strange find. Remember the odd upload error which I always saw when uploading to my ESP-01? When uploading to my new homemade ESP12F board, the error won't occur. This is absolutely repeatable.

Best regards

Strange. Mine has been working OK since I deleted and did a fresh install of the ESP8266 library, but I only have the one ESP8266 board.

[tom_iphi]

Many thanks for your feedback.
I will download and play with 0.04.11 this weekend.

Apologies if this seems a silly question, but are you using the https:// prefix rather than http:// to connect?

Hmmm, I always enter the plain IP address into the browser like 192.168.4.88. Should it read https://192.168.4.88 for SSL?
I always thought the browser would automatically detect SSL sites and switch to SSL.

Best regards.

[WaveyDipole]

Yes, as per your example, you would need to enter https://192.168.4.88, otherwise it will go to http://192.168.4.88. By default, HTTPS connects to TCP port 443 and HTTP connects to TCP port 80.  If you were to change the port to a custom one, for example to 8443, then you would have to append the port number as well, for example, https://192.168.4.88:8443, or without SSL, it would be http://192.168.4.88:8080, which would connect without SSL to TCP port 8080.

There are mechanisms that websites use to either re-direct from http to https, or to cause the browser to "remember" the last used port and protocol for a given site. The latter is something I might experiment with, but in any case the browser would need to be instructed to go to the correct port with the appropriate protocol (http or https) at least once.

[tom_iphi]

Many thanks for the explanation!
Ok, I have understood how to use SSL with a web browser.
Will SSL also affect pass-through traffic? Will I need special encryption software for my TCP client?

Best regards.

[WaveyDipole]

No. I have not implemented SSL on the pass-through port, only on the web admin port. I imagine that SSL could optionally be added to the pass-through port and connecting to the port would then require the use of an Secure Shell (SSH) enabled client. However, the ESP8266 does not have sufficient resources to handle more than one encrypted session so I have no plans at this time to enable SSL to the pass-through port. Besides, it might make things difficult for those using Python scripts or other programs without such support.

[tom_iphi]

Hi, I have tested ESP firmware 0.04.11 now successfully, many thanks for the update!

A few finds:
-Pass through works fine, indeed unencrypted, which is fine with me.
-When changing the http port number only, the apply button remains greyed out.
-The admin functions appear not to be implemented yet, right?
-web traffic is always encrypted. There is no online means to switch encryption off right? Only by setting the firmware switch and recompiling can this be done.
-My impression is that with encryption in place switching between tabs on the web page takes noticibly longer, am I just imagining this?

And maybe you can help me on a problem with my new adapter boards:
-I can program my Arduino Pro Micro directly via CDC Serial with the Arduino IDE just fine.
-I can also program the ESP8266 using a CH340C USB to Serial converter with the Arduino IDE.
Now, I would like to program the ESP8266 inside the application, i.e. use the ProMicro as a USB to serial converter and thus replace the CH340 board. I have a simple bridge code for the ProMicro which connects the CDC to the hardware serial, and the ESP does talk to the ProMicro, but the Arduino IDE won't upload the ESP through the ProMicro. Any idea why this doesn't work? Does programming the ESP involve switching baud rates? Of course, the ProMicro hardware serial is on a fixed baud rate. Do you know of any ProMicro code that lets it emulate a CH340 or FTDI USB to serial converter?

Best regards.

P.S.
Regarding my latter problem there appears to be a problem of the Arduino IDE talking through the CDC port of the ProMicro to the ESP. I have just written a com port redirector software which on one end connects to the ProMicro, while at the other end connects to a com0com virtual port pair. If I now connect the Arduino IDE, it DOES program the ESP. The data now is routed the following way:
Arduino IDE => COM0COM pair => my port redirector software => ProMicro => ESP8266.
Funny, that the long way works but the direct way connecting the IDE to the ProMicro does not.
It seems to be linked to the CDC handshake emulation.

[DefinitelyNotLarryEllison]

WaveyDipole - is the ESP32 code available anywhere? I searched through the AR488 github repo but I can't find it. I understand if you feel it's too early to put that out there; OTOH, if it was available as a fork via github you might get other people collaborating on the code side of things. However, I also see that the repo has ~130 contributors, and I'm not even sure if you're the ultimate owner of that project.

I may be in the minority, but I'd much rather have a few network cables going to my instruments than using wifi, so I'm wondering if you have any thoughts on using an ethernet shield rather than wifi. It seems like this wouldn't work with an Uno because the ethernet shields use so many pins -- I'm assuming one would need to use a Mega and move all the "GPIB Stuff" to the higher-numbered pins that it supports. It's something I've thought about trying to do, but I was wondering if you had already had any thoughts on this.

Oh, and by the way... thank you for all your time making this awesome project! It's amazing to me that you've put so much effort into it.

[WaveyDipole]

Hi, I have tested ESP firmware 0.04.11 now successfully, many thanks for the update!

Was hoping to have done that today but I ran out of time so thanks for posting your observations.

-The admin functions appear not to be implemented yet, right?

Correct. The password function is, for the present, superfluous, but the reboot function should work. Factory reset should also work, but with all the recent changes I will have to check this. It was my intent to go back to this page one the authentication functions were added.

-web traffic is always encrypted. There is no online means to switch encryption off right? Only by setting the firmware switch and recompiling can this be done.

Also correct. By default the sketch will use SSL and there is no way to turn this off at runtime, but it can be disabled by adding (or un-comenting) the #define DISABLE_SSL switch. I have so far been unable to find a convenient way to switch between SSL and cleartext mode at runtime (as originally envisaged) and from what I have been given to understand, this is not likely to be achievable with the currently available WiFi libraries.

-My impression is that with encryption in place switching between tabs on the web page takes noticibly longer, am I just imagining this?

No, you are not imagining things. The fact that one can run a webserver with encryption in just a few 10's of kb's of memory is quite amazing, but it does impose an substantial overhead on the MCU with the result that loading of web pages is slower.

And maybe you can help me on a problem with my new adapter boards:
-I can program my Arduino Pro Micro directly via CDC Serial with the Arduino IDE just fine.
-I can also program the ESP8266 using a CH340C USB to Serial converter with the Arduino IDE.
Now, I would like to program the ESP8266 inside the application, i.e. use the ProMicro as a USB to serial converter and thus replace the CH340 board. I have a simple bridge code for the ProMicro which connects the CDC to the hardware serial, and the ESP does talk to the ProMicro, but the Arduino IDE won't upload the ESP through the ProMicro.

Taking your questions one by one:

Any idea why this doesn't work?

Well, you don't state what steps you are taking to upload or any upload error messages, so its difficult to advise. If you are using the standard USB upload method then I could perhaps hazard a guess that when you upload from the IDE, the process checks the identity of the board (e.g. by checking how the fuses are set as well as other factors) and whether it matches the target that the bytecode is compiled for, so it "sees" an Arduino board rather than an ESP and so refuses to upload. However, this is only speculation.

The data now is routed the following way:
Arduino IDE => COM0COM pair => my port redirector software => ProMicro => ESP8266.
Funny, that the long way works but the direct way connecting the IDE to the ProMicro does not.
It seems to be linked to the CDC handshake emulation.

Again, you don't provide any code or indication of how your port re-director works, but my speculation would be that due to the extra layers (i.e. com0com and port redirector software) the IDE now has no idea that it is still connected to an Arduino and just "sees" the final piece of hardware, that is the ESP8266. This is only guesswork though.

[WaveyDipole]

WaveyDipole - is the ESP32 code available anywhere? I searched through the AR488 github repo but I can't find it. I understand if you feel it's too early to put that out there; OTOH, if it was available as a fork via github you might get other people collaborating on the code side of things. However, I also see that the repo has ~130 contributors, and I'm not even sure if you're the ultimate owner of that project.

I am the owner of the AR488 project. It was derived from (with permission) from an original work by Emmanuelle Girlando. I haven't started work on the ESP32 conversion yet so nothing available at present. At present, health issues and other family matters have to take priority, but I do want to get around to it in due course.

I may be in the minority, but I'd much rather have a few network cables going to my instruments than using wifi, so I'm wondering if you have any thoughts on using an ethernet shield rather than wifi. It seems like this wouldn't work with an Uno because the ethernet shields use so many pins -- I'm assuming one would need to use a Mega and move all the "GPIB Stuff" to the higher-numbered pins that it supports. It's something I've thought about trying to do, but I was wondering if you had already had any thoughts on this.

Someone did previously express the thought that they did not like the idea of WiFi floating around sensitive instruments so this has come up before. I have considered the possibility of adding Ethernet, but as you say, it will have to work with a Mega. I don't have an Ethernet shield yet, but I do intend to get one and have a play with it.

[tom_iphi]

Well, you don't state what steps you are taking to upload or any upload error messages, so its difficult to advise.

I upload the same way as with a USB-to-serial converter. The error message is "no such port or nothing connected".
With the logic analyzer on the ESP side, I see that the IDE does send data and that the ESP answers, but the answer apparently doesn't make it through the ProMicro back to the IDE.

Interesting find: If I use a terminal program like YAT, it cannot read data from the CDC port if flow control NONE is selected. I have to select some RTS/CTS flow control to read data. I believe this is the problem inside the Arduino IDE.

Again, you don't provide any code or indication of how your port re-director works

Quite simple. The program opens two com ports and passes any character that comes from one port directly to the other.
As described above, I do use hardware flow control setting on the ProMicro side and NONE on the IDE side. I belive that this is why it works this way but not the simple way.

[james_s]

The hardcopy format is correct, the scope sends HPGL and the plotter emulator renders it just fine. The problem is that the line that tells the scope to start sending does not assert when the plotter emulator is set to listen on all addresses. The TDS400 series only support hardcopy in talk-only mode and do not address a plotter at a specific address.

Thanks for confirming that. If you are using talk-only mode, then the receiving interface would need to be in listen-only mode (++mode 0, ++lon 1)? In which case the interface will sit in listening mode with NRFD and NDAC asserted indicating that it is ready to receive data. When characters are transmitted from the instrument in talk-only mode via the GPIB bus it will receive them using the usual three-way handshake process. There is no signal as such to tell the instrument to start sending.

I had a look at what the KE5FX 7470A program is sending to the serial port:

Plotter addressable at 5:

++ver
AT488 GPIB-USB version 4.99

++auto
Unrecognized command

++eos 0
++mode 0
++addr 5
++eoi 1

No assigned plotter address:

++ver
AT488 GPIB-USB version 4.99

++auto
0

++auto 1
++eos 0
++mode 0
++eoi 1

What is interesting is that, in neither case does the software request a '++read'. In the 'Plotter addressable at 5' instance, the instrument gets addressed (++addr 5) so it is possible that it might automatically send data back to the controller address.

However, in the 'No assigned plotter address' instance, since the instrument is in talk-only mode so cannot be addressed, but the interface is not being set into listen-only (++lon) mode. It is being set into device mode (++mode 0) with ++auto 1 and there appears to be nothing here to trigger the sending of data from the instrument. In device mode without ++lon, the interface will sit idle until addressed by the controller. It does not expect to be communicated with by another device. Maybe the Prologix implementation is different in this respect and receives data from an instrument even when the interface is placed in device mode in a similar fashion to ++lon mode, but then why have a ++lon mode?

I am not sure whether my implementation needs to be adjusted, or whether the HP7470A plotter program needs to handle this differently, but I am willing to work with the author of the KE5FX suite of programs to resolve this.

Incidentally, I noted also that I seem to be randomly getting an 'Unrecognized command' after the '++auto' command is sent. I am not sure why at present but probably down to timing. I will need to investigate this further.

I wish I knew more but unfortunately I'm fairly new to GPIB and I've never used a real Prologix interface. Does *anyone* actually have one of those? Maybe the lon mode is a legacy thing or something that is used by some software or by the old style ISA/PCI interface cards? I have no idea.

Do you want to try contacting the author of the plotter emulator or would you like me to? I'm more than happy to assist in any way I can, I can test whatever you need with my TDS410A. If we can find anyone who has a real Prologix interface that would make it possible to determine exactly how that works. I suppose another option is to try to pool together several people to buy one for testing purposes, I don't think they're hugely expensive, with 5-10 people it would be a small investment to make the open source interface top notch.

[tom_iphi]

I do have a Prologix interface, but I do not have a Tektronix scope to test it with.
I have found that the Prologix behaves exactly as described in the manual.
I can do simple tests if you tell me what.
Best regards.

[WaveyDipole]

Do you want to try contacting the author of the plotter emulator or would you like me to? I'm more than happy to assist in any way I can, I can test whatever you need with my TDS410A. If we can find anyone who has a real Prologix interface that would make it possible to determine exactly how that works. I suppose another option is to try to pool together several people to buy one for testing purposes, I don't think they're hugely expensive, with 5-10 people it would be a small investment to make the open source interface top notch.

Thank you for your willingness to assist and make this "open source interface top notch"! I have sent the John Miles an e-mail with a couple of questions and inviting him to pop by this thread. A comparison with a real Prologix interface to understand its behavior under these circumstances might be useful, but it still doesn't get around the fact that the Tek scope, expecting the plotter to be connected directly to the back of the scope, puts the instrument into talk-only mode which is not an addressed mode. By contrast, the HP8594 expects you to configure a plotter GPIB address and I presume that you can just select 'Plotter addressable at' in the 7470 program and select the GPIB address that matches that configured on the instrument and then Acquire to receive the plot.

From the software side, the 7470A program puts the interface into device mode, which is still an addressed mode. When using "Plotter addressable at.." this would also set the interface address to correspond to the selected GPIB address by sending a ++addr command, which it does. However, since the TDS420 does not have the option to address the interface and is communicating using a non-addressed mode, the interface address becomes irrelevant. In the case of the TDS420, no plot can be sent because the interface, not having been addressed, is not ready to listen. I would be surprised if this were to work even on a real Prologix but I would be interested to hear whether it does or not.

I did expect that when I selected "No assigned plotter address (listen-only)" that this would put the interface into device mode and then select listen-only (LON) mode which would place the interface into non-addressed active listening mode. However, from the serial output capture, that does not seem to be the case. I am hoping that the 7470 program author can shed some light on this.

You could try placing the interface in LON mode manually with:

++mode 0
++lon 1

prior to launching and using the 7470A program. There is a possibility it may time out, but I would be interested to know what happens.

I do have a Prologix interface, but I do not have a Tektronix scope to test it with.
I have found that the Prologix behaves exactly as described in the manual.
I can do simple tests if you tell me what.
Best regards.

Tom, do you have another instrument that can be placed into talk-only mode to send plots?

[KE5FX]

I have sent the John Miles an e-mail with a couple of questions and inviting him to pop by this thread.

I replied, but will cc: below as well since others have expressed some interest.  TL,DR: unfortunately I have no insight into either of the questions that have come up (LON mode or the TDS 4xx series). 

Hi, John --

I won't be able to check it out for a week or two, the way things are looking as of today (Monday).   I'm also unable to put much time into support for third-party adapters (meaning other than Prologix/NI488.2 devices), just because there are so many of them.  However, that being said, the truth is that I know very little about the GPIB physical and signaling layers since I've never had to deal with them.  Abdul at Prologix would be better-positioned to address a question like that, but then he probably doesn't want to encourage the competition.  

I will say that yes, that's exactly how device mode works in my understanding -- the instrument takes on the role of bus master/controller.  In some cases, the instrument needs to know the adapter's address in order to talk to the emulated 'plotter', and will not work with the adapter configured for listen-only mode.  In other cases, the instrument requires that the adapter is in listen-only mode, without an address of its own.  This has never made any sense to me either, but empirically that's how it seems to work. 

Re: the TDS400 series, sorry, no knowledge of those at all.

(Don't forget that the full source code is there in your installation directory, no need to pore over serial dumps to see what it's doing.)

-- john, KE5FX

[james_s]

I won't be able to check it out for a week or two, the way things are looking as of today (Monday).   I'm also unable to put much time into support for third-party adapters (meaning other than Prologix/NI488.2 devices), just because there are so many of them.  However, that being said, the truth is that I know very little about the GPIB physical and signaling layers since I've never had to deal with them.  Abdul at Prologix would be better-positioned to address a question like that, but then he probably doesn't want to encourage the competition.  

I will say that yes, that's exactly how device mode works in my understanding -- the instrument takes on the role of bus master/controller.  In some cases, the instrument needs to know the adapter's address in order to talk to the emulated 'plotter', and will not work with the adapter configured for listen-only mode.  In other cases, the instrument requires that the adapter is in listen-only mode, without an address of its own.  This has never made any sense to me either, but empirically that's how it seems to work. 

Re: the TDS400 series, sorry, no knowledge of those at all.

(Don't forget that the full source code is there in your installation directory, no need to pore over serial dumps to see what it's doing.)

-- john, KE5FX

Well not being much of a software developer the code is a bit hard for me to follow though I did at least take a look. Now that we've got everyone in the same (virtual) place including someone with a real Prologix adapter it seems there is at least hope of figuring this out. What I know at this point is this: If you press Hardcopy on the TDS420 scope and then execute a ++read on the interface the scope spits out a hardcopy in HPGL that can be rendered in the plotter.

I wonder if the best place to start is to connect a real Prologix interface to the plotter emulator and set it to listen for a plot and see if it asserts the line(s) necessary to tell the scope to start sending.

[tom_iphi]

Hi,

I wonder if the best place to start is to connect a real Prologix interface to the plotter emulator and set it to listen for a plot and see if it asserts the line(s) necessary to tell the scope to start sending.

I have an HP8593E SA here, that can send device initiated plots.
I have just hooked up my original Prologix adapter, fired up the 7470.exe, set it up to be a plotter at address 5, told the SA that the plotter address is 5, pressed the w-key in 7470.exe to let it wait for device initiated plots, finally pressed the COPY key on the SA. Doesn't work. The SA brings up an error message "Invalid HPIB Adrs/Operation" and "SQR 140".
This is what's going on at the Prologix com port:

Code: [Select]

++ver
Prologix GPIB-USB Controller version 6.101
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1

Best regards.

[KE5FX]

Code: [Select]

++ver
Prologix GPIB-USB Controller version 6.101
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1

Best regards.
[/quote]

Hard to say what's up with that.  ++auto isn't an 'unrecognized command'.   Looks like the firmware is out of date (and not even mentioned in the release notes), so I'd try updating it first.

[tom_iphi]

I don't think the "Unrecognized command" is due to an outdated firmware.
When I manually enter ++auto in the GPIB configurator software I do get an answer.
The command does exist in the firmware.
My firmware is 6.101, the latest is 6.107 of 2013.
I'll try the update tonight but I doubt that this will make a difference.

[tom_iphi]

I have updated my Prologix to firmware 6.107, see attached report.
Screencopy experiments at the end of the report. The successful screencopy was initiated by the7470.exe with Prologix in controller mode.
Have I done anything wrong?
Best regards.

P.S. Just found out that the Prologix answers ++auto with "unrecognized command" when in mode 0 = device mode. Still the same after firmware update.

[WaveyDipole]

I have updated my Prologix to firmware 6.107, see attached report.
Screencopy experiments at the end of the report. The successful screencopy was initiated by the7470.exe with Prologix in controller mode.
Have I done anything wrong?

Tom, thank you for taking the time to post a detailed report of the steps you took. Can I ask whether the printer address on the HP8593 was still set to to 5 (Print Plot Config -> Prn Port Config Plot Port Config: HPIB;  PRINTER PLOTTER ADDRESS: 5; COPY: PLT) ? By default it is apparently set to 1. Just wondering whether it got reset after a power cycle or something?

Regarding the 'No assigned plotter address' mode, I wouldn't expect this to work, but if the interface happens to have been left in device mode with its address set to whatever is configured as the printer address on the 8593 (e.g. 5) , then it just might... In this mode ideally, the instrument needs to be placed into talk-only mode, but I don't see such an option in the manual.

If the printer address on the 8593 was definitely set to 5 and still no result, then there is another test we could do. Connect either the Prologix or Arduino interface to the 8593. Set the 8593 with printer address 5, and set the GPIB controller to address 5. Connect to the GPIB interface with a terminal and issue the following commands:

++mode 0
++addr 5

Now try pressing the Screencopy button. Do you get any data come through? Test the other interface to see whether you get the same response.

Next, (you will need to use the Arduino interface for this) enable DEBUG5 in AR488_Config.h and compile and upload the firmware. Do the same test as above, but capture the result. This should show some additional numeric information. If you could then upload the result in a file here, it will give us some idea what commands the instrument is sending.

P.S. Just found out that the Prologix answers ++auto with "unrecognized command" when in mode 0 = device mode. Still the same after firmware update.

Tom, that's a good spot and explains why the same was happening with my firmware. The Prologix manual confirms that the ++auto command is valid only in controller mode. If the adapter gets left in mode 0 after the previous operation, then we can expect such a response from the ++auto command. I think we can safely ignore this error as not relevant to the issue.

[KE5FX]

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.

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...

[james_s]

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.

[texaspyro]

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.

I wrote the code that 7470 currently uses for drawing.   The HPGL renderer works rather well.   I have compared its' abiilty to render HPGL drawings against around a dozen different HPGL renderers, most of which are rather crappy.  Only 7470 and the HPGLVIEW renderer from CERN seem to be at least mostly OK.  HPGL is not all that well defined and almost every HPGL device outputs stuff that does not meet the spec.  The 7470 code has a lot of special case tweaks for getting around the quirks generated by a lot of test equipment. 

There is also code for drawing PCL format printer output, but it is rather limited.  The PCL spec defines several different encoding/compression formats.   The 7470 PCL code only uses a couple of the more common / simple formats.  I have only really tested it with HP-165xx logic analyzers.