AR488 Arduino-based GPIB adapter

[tom_iphi]

Hi,

I have wired up an Arduino ProMicro and flashed firmware "AR488 GPIB controller, ver. 0.47.60, 05/12/2019".
I can basically talk to my GPIB instruments but I'm having a problem with acquiring screen copies from my HP8593E.

I use the following control sequence to make the HP send back the plot data:

++auto 1
++eos 0
++mode 1
++addr 21
++eoi 1
PLOT 550,279,9750,7479;

I also have an original recent Prologix adapter and the sequence works well with that.
The Prologix receives about 3000 bytes of plot data and sends it to the COM port in a single string.

With the AR488 only about 1100bytes of data are sent back after the PLOT command.
I can get the reminder of the data by firing several ++read commands, but that shouldn't be necessary as I'm in auto-read mode.
Also increasing the read timeout ofthe AR488 to 30s doesn't change anything.

Could this be a buffer overrun problem inside the AR488 firmware or am I doing something wrong?

Best regards,
Tom

[tom_iphi]

In case it is of interest to anyone:

I have solved the problem. The HPGL string sent back by the HP8593E contains a linefeed character in the middle.
The AR488 firmware stops reading as soon as it detects a linefeed.
I have changed the break-criterion in the firmware to look for CR+LF and now it works flawlessly.

Do the code authors read this thread?

Best regards,
Tom

[rhb]

Yes, WaveyDipole is a regular.

[artag]

Thanks for debugging this. I don't think WaveyDipole has an instrument that transfers data in large pages making it difficult to test (though he does seem to be acquiring additional stuff).

I guess this needs an additional option in the eoi/eot area ? Does the prologix always look for CRLF or is it switchable ?

Is the LF in the returned string there just because it's binary ? Could a CRLF occur under some circumstances ?

If it's a binary transfer you should probably be looking to terminate it with EOI rather than some data pattern, if that's possible.

[tom_iphi]

The transfer from the HP8593 is pure ASCII, just HPGL commands. So, it is quite a surprise that there is a LF in the middle of the string.
I will check if it issues an EOI at the end of transmission. I'll hook up a logic analyzer in the next few days.

Btw, has anybody considered transfering the code to an ESP8266 like a NodeMCU? The wifi interface would come for free.

[WaveyDipole]

That's an interesting one. The ++eos command sets the termination characters for data being sent from the interface over the GPIB bus, but there is no equivalent command to set termination for data being sent from the instrument back to the interface. Section "7.1 Binary Data Transmission" of the Prologix manual suggests that "No special action is necessary to receive binary data from instruments. Any binary data received from the instrument is transmitted over USB to PC unmodified, just as with ASCII data.", but also goes on to say that "...binary data from instruments is not usually terminated by CR or LF characters...". In this case it seems that we do have a LF (0x10) character in the returned data. Theoretically 'data' can include any character from 0 to 255. Since the data is not being read with '++read eoi', but is returned automatically in response to the PLOT command, it seems that there is no means to ignore the termination character and rely on the EOI signal to indicate the end of the data. If 0x10 is returned within the data, then, as artag points out, might it be possible for the sequence 0x13, 0x10 (CR LF) to be randomly and unexpectedly returned as well?

If the Prologix does not  interpret the termination characters, then presumably it must be relying on the timeout to end the receive process? Otherwise if the instrument is not configured to send EOI, how would it know when to stop receiving? Curious.

tom_iphi, could you send me an example output? You can post it up on the AR488 GitHub issues page if you like (https://github.com/Twilight-Logic/AR488/issues) or send me a PM. I will investigate further. It may be that the LF detection needs to be removed altogether. Another approach may be to introduce a custom command to deal with termination of data incoming from the instrument. I also look forward to your analysis with the logic analyser.

Regarding the ESP8266, there is an insufficient number GPIO pins available on the ESP8266 to drive all 16 signals on the GPIB bus. I have, however, been working on using an ESP8266 as an add-on module connected via the Tx/Rx pins to the Arduino. The code is 90% there, but there are a couple of sticking points to get past. The ESP32 is probably a better candidate as it does appear to have enough pins and the intention is to complete the work on the ESP8266 and then combine and port the complete code to the ESP32.

Incidentally, I have been working on adding further optional support for an SN75162 chip being used instead of an SN75161, but have ran into some difficulties. Theoretically the two chips function in the same way and both have a TE and DC control pin. However, the SN75162 has an additional separate SC pin to independently control REN and IFC. The logic is otherwise the same and it should be possible to match the exact operation of the SN75161 by synchronising the control of DC with SC except that the state of SC is reversed. While the SN75161 does not falter at all, the SN75162 behaves erratically under certain conditions. I'm wondering whether I am missing something of whether the chip might be a fake? On the datasheet, there are two longer 22 or 24 pin DIL package variants shown when compared to the 20 pin package of the SN75161, but their widths are consistent, whereas this IC is wider? Is there any way to tell whether this SN751262 is genuine or not? Both appear to have a TI logo and the one on the SN75160 looks just like on the datasheet, but on the SN75162 it looks rather different?

[artag]

I have an ancient HP 27209 ISA-bus card with a TMS9914 and TI buffers on it. The 75160 is a 20 pin 0.3" DIP and the 75162 is a 22 pin 0.4" DIP. Both are marked with both TI logo and an HP part number and are sure to be genuine parts.
 

[WaveyDipole]

Thanks. That at least confirms that the SN75162 does exist in 0.4" DIP 22 pin format.

[WaveyDipole]

It has just been reported to me that there is an issue in the latest firmware regarding the SerialEvent interrupt that affects the firmware in 32u4 boards only. Uno, Nano and Mega 2560 boards are not affected. This is because SerialEvent is apparently NOT supported on Arduino 32u4 boards. I found it difficult to locate documentation that would confirm this, but it does seem to be mentioned here, although only within the code example comments:

https://www.arduino.cc/en/Tutorial/SerialEvent

I expect that this is due to the implementation of CDC serial ports on 32u4 boards. In the latest firmware (0.48.03) a detection routine was added to AR488_Config.h to automatically invoke SerialEvent on AVR boards, but to avoid doing so on non-AVR boards or where a custom pin layout is being used. The result is that on a 32u4 based board with unmodified 0.48.03 firmware, the serial port does not respond to input.

To workaround this problem, look for a section in AR488_Config.h that looks like this:

Code: [Select]

#if defined (__AVR__) && not defined (AR_SW_SERIAL)
  // Use serial interrupt handler
  #define USE_SERIALEVENT
#endif

When compiling for a 32u4 board only, the line '#define USE_SERIALEVENT' needs to be commented out:

Code: [Select]

//  #define USE_SERIALEVENT

This will prevent the firmware from trying to use the SerialEvent handler. Checking for incoming characters at the serial port will then be handled within each iteration of the void loop() function instead. It should be pointed out that when SerialEvent is not used, handling of input to the serial port is somewhat slower because the interface has to wait for any existing process to complete and exit to the next iteration of the main loop before it can accept more characters. Use of the interrupt allows characters to be accepted even while other processes were still ongoing and therefore speeds things up a bit. This may need to be taken into account when writing scripts (e.g. Python) or other programs that communicate with the interface. Having said that, if you have already been successfully using firmware 0.47.xx, then commenting out the above line in AR488_Config.h should be all that is required.

Use of SerialEvent was dropped in version 0.47.xx but was re-introduced in version 0.48.xx. The problem affects 32u4 boards only i.e. the Leonardo and Micro. It does not affect the Nano, Uno or Mega 2560 boards. It affects firmware version 0.48.03 only. Firmware version 0.47.xx is not affected.

[artag]

Yes, I mentioned this in the original 32u4 patch which also handled it on the top of loop(). It looks as though it got lost in the transition to not use it and then use it again. It did work on at least one of the combined releases but I haven't tested all of them.

I don't think SerialEvent  calls the handler in interrupt context. An interrupt handler does capture the incoming data but the event handler is called in foreground context between iterations of loop() and possibly in delay() and some other time-consuming library calls.

I think it's actually pretty useless as it stands (especially as it's not supported on the 32u4 for no very good reason) and should be considered as only a style thing for code that's written that way. For compatibility it has no particular processing speed advantages as long as loop() executes quickly. Maybe one day it could be handled with a separate task but that's not going to happen on an AVR.

[WaveyDipole]

Thanks for debugging this. I don't think WaveyDipole has an instrument that transfers data in large pages making it difficult to test (though he does seem to be acquiring additional stuff).

My instrumentation is indeed limited. I will have a look at the manual and see what the HP3314A is capable of putting out. I have only used it a handful of times and from what I remember with it being a signal generator, it mostly accepts remote control commands. I don't have anything with a GPIB port that outputs frames of data like an SA. I could possibly simulate with an AR488 in device mode though.

Yes, I mentioned this in the original 32u4 patch which also handled it on the top of loop(). It looks as though it got lost in the transition to not use it and then use it again. It did work on at least one of the combined releases but I haven't tested all of them.

That may have been what prompted me to remove it, although....

I think it's actually pretty useless as it stands (especially as it's not supported on the 32u4 for no very good reason) and should be considered as only a style thing for code that's written that way. For compatibility it has no particular processing speed advantages as long as loop() executes quickly. Maybe one day it could be handled with a separate task but that's not going to happen on an AVR.

I also came across a number of similar comments (about SerialEvent being pointless) which gave added reason for removing it in the combined 0.47.xx version, one benefit of which would have been to make it easier to maintain compatibility. However, someone then reported some real world delays when 0.47.xx firmware was being used in contrast to version 0.46.32 which does use SerialEvent. Re-introducing SerialEvent returned things to previous performance levels which is why it has been re-introduced into 0.48.xx, but with an attempt to confine its use only to those boards that actually support it. However, I omitted to make allowance for the 32u4 which does not support it, something I intend to put right in the next release. Quite where we go with it after that I'm not yet sure, although I do have a couple of ideas in mind.

[tom_iphi]

As promised here are two logs of plot requests from an HP and a Tektronix spectrum analyzer with an original Prologix V6 adapter.
The requests were performed with the KE5FX plotter emulator software.
Indeed, in the communication there are lots of characters < 0x20 sent by the instrument, particularly some LF.

Btw, my AR488 code modification that waits for CR+LF works with both instruments.

And, btw, I have been in touch with KE5FX. He has promised to update his GPIB software package to accept the original AR488 version string and handle the device like a Prologix V6.

[WaveyDipole]

Thank you for sharing this information. It would seem from the output of the HP8593E instrument, that an LF sometimes appears in the string within the LB<string>ETX construct, usually immediately after the initial characters 'LB'. In hex this starts with 4C 42, then 0A and possibly some further character and finally ends with 03. The characters LB are a mnemonic for the LABEL command. Quite why there would be an LF inside a label I'm not sure, but perhaps this is used for formatting or positioning the label. From the provided output, evidently the Tek 496P does not seem to do this so I assume that the problem did not occur with the Tek? Both instruments terminate the data stream with a CR+LF (0D 0A) and assuming that all instruments as a rule terminate their data stream with an 0D 0A, then looking for CR+LF would perhaps be an appropriate way to handle it. However, looking at the manual for one of my instruments, it seems that The terminator can be set to one of:

0 - CR+LF (0D 0A)
1 - ETX (03)
2 - CR+LF+ETX (0D 0A 03)
3 - EOI (signal only)
4 - CR+LF+EOI (OD 0A + EOI signal)
5 - ETX+EOI (03 + EOI signal)
6 - CR+LF+ETX+EOI (0D 0A 03 + EOI signal)
7 - CR (0D)
8 - SPACE (20)

Perhaps not all instruments will have all of these options and I'm not sure in what circumstances some of them would be used, but it would seem that this may not be as straightforward as it seems. However I expect that 0D 0A is likely to be used by default for most part, perhaps optionally in conjunction with the EOI signal. In any case, I will give it some more thought.

[WaveyDipole]

I have just uploaded the next update, version 0.48.07. This avoids invoking SerialEvent when a 32u4 MCU is detected and also fixes the data transfer problem reported by tom_iphi when using the HP8593. An additional custom ++eor command (as opposed to ++eos) has been implemented that allows selection of an alternative termination sequence for data coming from the instrument as follows:

0 - CR + LF
1 - CR
2 - LF
3 - None
4 - LF + CR (Keithley)
5 - ETX (Schlumberger Solatron)
6 - CR + LF + ETX (Schlumberger Solatron)
7 - EOI signal

The first four options match those of the ++eos command. The remainder have been added based on possible termination sequences available on instruments that I have to hand. One of the manuals also had SPACE as a terminator option, although I have never seen that used in practice. By default, option 0 (CR+LF) is used.

I would be interested in feedback from Tom if he could test with the default setting on the HP8593?

The sharp eyed will also notice some code has been added to support the SN75162 chip, but although this appears work for most part, on my breadboard test layout it fails ++spoll and struggles with ++lon so should be considered experimental for now. The manual has been updated with the details of the ++eor command, but details of the SN75162 chip operation are yet to be added.

[tom_iphi]

Many thanks for the update!
The default settings work fine with my HP8593E. 

Could you possibly add a simple serial number or id function like ++id or ++serial, where the adapter answers with a predefined/hardcoded identifier string like "HP8593E"?
The idea is to have one personalized adapter per instrument instead of heavy GPIB cabeling. This would also solve the "one instrument on bus in switched off state" problem.
The downside will be many com ports on the PC side. The identifier string would help tell them apart.

[rhb]

Tom,

That already exists.  Read the ++setvstr and ++ver command descriptions.

IDC cable works well for making short GPIB cables.  I've not evaluated performance other than basic function though.  The ribbon works very nicely if you put one AR488 per instrument stack. Add a Pi or Beagle with a USB hub and you can read everything via ethernet from the PC.

There is at least one Chinese OEM selling single instrument interfaces, though I don't know what FW they use.


@artag designed a Uno shield that connects to a 24 pin IDC header:

https://oshpark.com/shared_projects/h67uh7OO

I've been too busy with other stuff to actually order boards as I want to get them from China and never having ordered a PCB I'm sure the first time will not be quick.  I'll have to learn what I'm doing and how to view the board files, etc.

There is also a design by @vindoline for an AR488 based GPIB-USB adapter:

https://github.com/Twilight-Logic/AR488

which is what I used for logging data from the USA Cal club round 2 PX and FX references.  However, if I had not had a standard GPIB cable I could not have connected it to my 34401As because of interference from the power cord connector.

There is at least one other bespoke board design farther back in this thread.

Have Fun!
Reg

[WaveyDipole]

Many thanks for the update!
The default settings work fine with my HP8593E. 

Glad to hear that works. 

Could you possibly add a simple serial number or id function like ++id or ++serial, where the adapter answers with a predefined/hardcoded identifier string like "HP8593E"?
The idea is to have one personalized adapter per instrument instead of heavy GPIB cabeling. This would also solve the "one instrument on bus in switched off state" problem.
The downside will be many com ports on the PC side. The identifier string would help tell them apart.

Funnily enough I was contemplating adding something like an ++id command to return a response in reply to the *idn? sequence. I figured that something like that might be useful in the case of older instruments that do not respond to an ID request. The string would be of limited length, perhaps 20-30 characters. Any feedback on this idea would be appreciated.

The original idea for ++setvstr in conjunction with ++ver, was to set a custom string in response to the ++ver command so that EZGPIB, KE5FX and other GPIB programs can get the expected reply string they are "looking for" (e.g. "GPIB-USB") in order to identify a Prologix interface, however this feature could also be used to provide a means to identify the connected instrument.

BTW, the vindoline adapter design details are here:
https://github.com/vindoline/AR488-USB-GPIB

Regarding the number of com ports, perhaps something like this (or similar) with a suitable wall wart might help?
https://www.ebay.co.uk/itm/4-7-Ports-Powered-USB-3-0-HUB-Splitter-Box-5Gbps-Super-Speed-AC-Power-Adapter/383340983670

I would have thought that USB3.0 should provide more than enough throughput capability?

[tom_iphi]

Funnily enough I was contemplating adding something like an ++id command to return a response in reply to the *id? sequence. I figured that something like that might be useful in the case of older instruments that do not respond to an ID request. The string would be of limited length, perhaps 20-30 characters.

That would certainly be very useful for instruments that do not understand the *IDN? command. Btw, the HP8593E is of that kind. It only responds to ID?.
And my good old HP8672A signal generator doesn't even return any identifier. This box does GPIB without any microprocessor!!!
I think 32 characters would be more than sufficient. Functionality wise it would be cool if the string could be saved in the EEPROM, thus non-volatile but changeable, e.g.

++id my Instrument
  saves the string "my instrument" to some EEPROM location
++id
  clears the EEPROM location

If the EEPROM location contains a valid string of length >0 then that string is returned upon *IDN? query, else the query is put forward to the instrument via GPIB.

Still, it would be terribly nice if I could assign a fixed individual serial number string to each adapter, hard programmed in flash.
Something like ++serial should simply return that string.

The original idea for ++setvstr in conjunction with ++ver, was to set a custom string in response to the ++ver command so that EZGPIB, KE5FX and other GPIB programs can get the expected reply string they are "looking for" (e.g. "GPIB-USB") in order to identify a Prologix interface, however this feature could also be used to provide a means to identify the connected instrument.

Not quite. The modified ++ver-string is volatile. After power down and back up, it is replaced by the original AR488... string, so no good for permanent identification of the hardware.

[WaveyDipole]

Sorry, yes meant *idn? (or *IDN?). Have edited my previous post.

After ++setvstr you have to do a ++savecfg. That saves the adapter configuration in EEPROM.

In keeping with other Prologix commands, one might expect ++id to return the currently set ID string, although naturally, *idn? would do that anyway, in which case the exception perhaps makes sense. However, one could also do something like ++id # or similar to delete. I will have a think about that.

Since these strings (ver, id and serial) are not likely to be changed very often, I could set it up so that they are saved independently as you suggest. What do others think?

[artag]

I would like to support something like this at the USB level in the 32u4 version (so it appears in dmesg and lsusb listings) , though that's not trivial as the current USB driver doesn't support custom names.

If I did that, should it hang off the proposed ++id idea or should it be yet another level of naming ?

[tom_iphi]

@WaveyDipole

After ++setvstr you have to do a ++savecfg. That saves the adapter configuration in EEPROM.

Cool, many thanks for the hint!

In keeping with other Prologix commands, one might expect ++id to return the currently set ID string, although naturally, *idn? would do that anyway, in which case the exception perhaps makes sense. However, one could also do something like ++id # or similar to delete.

Either way would be fine!

Since these strings (ver, id and serial) are not likely to be changed very often, I could set it up so that they are saved independently as you suggest.

Indeed, having all those strings in the EEPROM would be more flexible than in flash. Reconfiguration would then require no source code change.

@artag

I would like to support something like this at the USB level in the 32u4 version

You mean something that would appear as a "friendly name" of the corresponding COM port? Right now, it appears as "Arduino Leonardo".
I am not very familiar with the Arduino IDE environment. I assume, the USB endpoint is defined somewhere in the bootloader and it would have to be changed there.
An alternative would be to set up a second USB CDC endpoint, but I have no idea how this would be done in Arduino without interfering with the bootloader...

Btw, where would the bootloader source code be found and how does it get included into each sketch being uploaded?

[artag]

I would like to support something like this at the USB level in the 32u4 version

You mean something that would appear as a "friendly name" of the corresponding COM port? Right now, it appears as "Arduino Leonardo".
I am not very familiar with the Arduino IDE environment. I assume, the USB endpoint is defined somewhere in the bootloader and it would have to be changed there.
An alternative would be to set up a second USB CDC endpoint, but I have no idea how this would be done in Arduino without interfering with the bootloader...

Btw, where would the bootloader source code be found and how does it get included into each sketch being uploaded?

Possibly. I think it might be buried somewhere in the device management stuff in Windows. I don't use it much. It's a bit more accessible in Linux.

The bootloader is separate from the runtime code, as it's possible to replace the serial device with something else (such as a keyboard). The bootloader is installed on the Arduino and left there for subsequent code changes - it isn't replaced when you program it. However, sources can be found in
<arduino root>/hardware/arduino/avr/bootloaders/.  Runtime USB drivers are in <arduino root>/hardware/arduino/avr/cores/arduino/. I think the PluggableUSB is the right area but haven't really looked into it yet.

[tom_iphi]

I have just hooked up an ESP8266 configured as wifi-UART bridge to the Leonardo AR488 and it works great! See picture.
The ESP8266 presents itself as a TCP socket server linking directly to its UART.
The KE5FX software can directly connect to a TCP socket server. Thus, I can read screenshots from my HP8593E wirelessly now via wifi and the KE5FX 7470A plotter emulator software.
Cool stuff!

I have used a very rudimentary ESP8266 code from here:
https://github.com/roboremo/ESP8266-WiFi-UART-Bridge
Not very comfortable as it can only be configured by changing the source code and you have to find out the dynamically assigned IP address somehow.
I'm not very experienced with ESP8266 programming.
So, a proof of concept! But that's the way I want to talk with my instruments eventually! 

[Gerhard_dk4xp]

As promised here are two logs of plot requests from an HP and a Tektronix spectrum analyzer with an original Prologix V6 adapter.
The requests were performed with the KE5FX plotter emulator software.
Indeed, in the communication there are lots of characters < 0x20 sent by the instrument, particularly some LF.
Btw, my AR488 code modification that waits for CR+LF works with both instruments.

For me, it seems that the spectrum analyzers send their screen data as a binary data block.
That would require the use of the EOI line AFAIR. That the CRLF works would be more a
consequence of the fact that CRLF is 256 times more improbable than CR alone.

Disclaimer: My 488 experience dates from 4MHz Z80 times. I still have some TMS9914
and yes, one of the two bus transceivers was 0.4". Those skinny long 0.3" DILs came
many years later.


(Hi, Tom! I'm no more in Bollingen since several years. We've met there once
in the early VNWA days. :-)   )

 

[Gerhard_dk4xp]

Sorry, yes meant *idn? (or *IDN?). Have edited my previous post.

After ++setvstr you have to do a ++savecfg. That saves the adapter configuration in EEPROM.

In keeping with other Prologix commands, one might expect ++id to return the currently set ID string, although naturally, *idn? would do that anyway, in which case the exception perhaps makes sense. However, one could also do something like ++id # or similar to delete. I will have a think about that.

Since these strings (ver, id and serial) are not likely to be changed very often, I could set it up so that they are saved independently as you suggest. What do others think?

++id and *idn? are not the same thing.  ++id asks the dongle, *idn? asks the currently selected talker.

Last week I had a 488 blast from the past when my Agilent 89441A acted weird under remote control.
It has both the 488 and LAN options and I operated it via LAN flawlessly for several years. I used to open
port 5025 on 192.168.x.y and then could simply talk GPIB strings.The connection
got shaky now and then, and finally it ceased working at all.
I had bought a Prologix USB dongle as a fallback solution and could achieve some communication,
but I never got it really stable. Sometimes I got nothing at all and then answers that belonged to
a previous query. My problems seemed to be centered around the ++eot command and I
could never understand what a timeout really does apart of (maybe?) happening.

I got the TCP/IP working again, so I'm no longer under pressure to finish the GPIB problem.
It turned out that one is supposed to do an (empty) fseek() when the direction of the socket
is reversed. It worked 5 years without, but the new Linux kernels/C libraries seem to be more picky.

Cheers, Gerhard