AR488 Arduino-based GPIB adapter

[tom_iphi]

Hi John,

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

It is consistent and happens every time, also loss of contact after having received the plot data happens every time.

    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

Yes, I am using exactly the same procedure.

[WaveyDipole]

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!

While receiving for a reply from GPIB, characters are not buffered. Characters are sent immediately to the serial port. Detection of the terminator is used only to identify the end of the transmission. Just having another look at "Output data formats" table on page 159 of the 34401 user manual, it would appear that transmission over IEEE488 is terminated with NL only. If the interface is looking for a CR+NL sequence, it won't find one and the timeout period will follow every reading, the result would be that responses to multiple "read?" commands will be spaced out by the timeout period as you describe. It might indeed be worth trying ++eor 2 so that the interface looks for NL only as a terminator.

[WaveyDipole]

Hi John,

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

It is consistent and happens every time, also loss of contact after having received the plot data happens every time.

That is interesting and I will investigate this further. Could you confirm the ++read_tmo_ms values you have set on the Prologix vs the AR488?

    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

Yes, I am using exactly the same procedure.

Thanks for confirming that. Since you have a Prologix and this works, I wonder whether you could send a plot using the Prologix to the 7470 program and save the result to a file? Then attach the file here. My intention is to embed the file content (provided it is not too big) into the sketch and run the tests again. That way, I would be sending exactly the same data as your instrument.

[tom_iphi]

I wonder whether you could send a plot using the Prologix to the 7470 program and save the result to a file?

Yes, I can do. What exact data would you like? I can save the 7470.exe output to file. But I have noticed that this is not necessarily what the instrument sends.
The 7470.exe apparently corrects some oddities.

You already have two instrument output examples in the com port PDF logs that I have uploaded earlier, both in ASCII and hex format.
Good enough?

[WaveyDipole]

I wonder whether you could send a plot using the Prologix to the 7470 program and save the result to a file?

Yes, I can do. What exact data would you like? I can save the 7470.exe output to file. But I have noticed that this is not necessarily what the instrument sends.
The 7470.exe apparently corrects some oddities.

You already have two instrument output examples in the com port PDF logs that I have uploaded earlier, both in ASCII and hex format.
Good enough?

Fair comment and yes, I could use the data from one of the PDF files as a starting point but the drawback is that it is not possible to determine whether and where any unusual or non-printable characters (e.g. CR, LF ESC and others) appear in the output. I also didn't realize that the 7470 program may be modifying the received data so saving a plot to a file might also inadvertently hide something. What software are you using to capture the serial port? I was thinking to obtain just a standard single plot from your 8591 instrument, but ideally an exact hex representation of the captured data. If your serial capture tool can do that it would be useful. However, I will first try one of the example plots in the KE5FX software directory.

[grizewald]

While receiving for a reply from GPIB, characters are not buffered. Characters are sent immediately to the serial port. Detection of the terminator is used only to identify the end of the transmission. Just having another look at "Output data formats" table on page 159 of the 34401 user manual, it would appear that transmission over IEEE488 is terminated with NL only. If the interface is looking for a CR+NL sequence, it won't find one and the timeout period will follow every reading, the result would be that responses to multiple "read?" commands will be spaced out by the timeout period as you describe. It might indeed be worth trying ++eor 2 so that the interface looks for NL only as a terminator.

Thanks for that. I'm fairly sure that my read from the serial port in my script won't return a line to me until the line itself is terminated with a newline character, so I think I have enough clues to perform some experiments later on.

[WaveyDipole]

Tom, I managed to encode one of the example plots (file 'HP 8591EM.plt') into the sketch. Had to write a small script to read the file and export the bytes to a hex representation of the data. I then copied and pasted the exported result directly into the sketch, compiled, uploaded and ran the test to send the data over GPIB. The 7470 program had no problem with reading the resulting plot (see the attached). It is possible, of course, to just load up the example file into 7470 program, but this was, in fact, sent from one AR488 to another over GPIB and captured from the receiving AR488 by the 7470 program.

I also realized that your PDF does actually contain the data in hex further below the text dump so I spent a little time manually extrapolating this into a file and formatting it so that it could be copied into and used by the sketch. As you can see in the second attachment, after doing this and sending your data over GPIB, the plot was successfully received.

It would appear then, that neither particular characters nor the size of the data is the issue. There must be some other factor.

Since I have observed with my own setup that USB hubs can cause problems, might I ask whether your 32u4 is connected via a USB hub? Have you tried connecting it directly into the PC? It seems unlikely given that the Prologix works, but just want to rule it out. BTW, are you still using the HC06 to wirelessly connect the Arduino to the PC, or is it directly connected via USB cable?

[grizewald]

Thanks for the help Wavey.

I reset the adapter to defaults and then set:

++read_tmo_ms 5000
++eor 2
++eot_char 10
++eot_enable 1

in the setup part of my script.

I now have data coming back from the 34401A at full speed!

 

[WaveyDipole]

Thanks for the help Wavey.

I reset the adapter to defaults and then set:

++read_tmo_ms 5000
++eor 2
++eot_char 10
++eot_enable 1

in the setup part of my script.

I now have data coming back from the 34401A at full speed!

 

I don't think that ++eot_char and ++eot_enabled should have been necessary as the NL character present in the data stream from the instrument will be passed to serial anyway but I'm glad it worked. That seems to the the second scenario where the custom ++eor command appears to have helped. I will make a note that it may be useful for this instrument.

[grizewald]

I don't think that ++eot_char and ++eot_enabled should have been necessary as the NL character present in the data stream from the instrument will be passed to serial anyway but I'm glad it worked. That seems to the the second scenario where the custom ++eor command appears to have helped. I will make a note that it may be useful for this instrument.

I agree that they probably are not needed, but I've always been a belt and braces guy when it comes to software development, so it's a habit that I don't try to get out of.

[serg-el]

https://radiokot.ru/forum/viewtopic.php?p=3815540#p3815540

I remade this project a bit.

 Under ARDUINO UNO with ATmega328 installed.
 There are boards with already divorced pins A6, A7, but there are places where you need to solder to the legs of the microcircuit.

 Used the latest version of ver.  0.48.08, 27/01/2020.

 Added two LM35 temperature sensors.
 There is both hardware filtering and software filtering.


 ++ temp -> temperature 1
 ++ temp2 -> temperature 2

 To reduce interference, the LM35 is connected via an RC circuit of 10 kΩ, 0.1 μF.
 Software adjusted value.  Measured lower and higher by about 0.5 ° C compared to Pt1000.

[WaveyDipole]

Thank you for posting that. That must have taken some delicate surgery!

This prompted me to have a look at the datasheet for the 328p and I discovered also that it has a built-in temperature sensor (section 24.8, p 256) via ADC8 so one could possibly also log the temperature of the chip if one wanted.

[2N3055]

Thank you for posting that. That must have taken some delicate surgery!

This prompted me to have a look at the datasheet for the 328p and I discovered also that it has a built-in temperature sensor (section 24.8, p 256) via ADC8 so one could possibly also log the temperature of the chip if one wanted.

Built in temperature sensor is a joke, together with built in voltage reference...
You can use built in temp sensor to look at gross trends but not much more than that.
External temp sensors ar not that expensive..

[tom_iphi]

Hi John,

Since I have observed with my own setup that USB hubs can cause problems, might I ask whether your 32u4 is connected via a USB hub? Have you tried connecting it directly into the PC? It seems unlikely given that the Prologix works, but just want to rule it out. BTW, are you still using the HC06 to wirelessly connect the Arduino to the PC, or is it directly connected via USB cable?

No, no hub here. Also no wireless connection. USB directly plugged into the notebook USB port.

And I made one more experiment:
To make sure the issue is not related to the USB CDC port, I switched over to using the Leonardo hardware serial port (RXO, TXI lines) instead and hooked it up to a CH340 USB to serial converter, also directly plugged into the PC.
The behavior is exactly the same as with CDC. Host initiated plots transfer just fine. Instrument initiated plots initially start with the already discussed delay of about 10s and when the transfer is complete, the AR488 no longer reacts to commands like ++ver and 7470.exe crashes. Disconnecting from the GPIB bus is not enough to recover communication, only a power cycle will do the job.
So, this appears to be not some kind of "dirt effect" but a real firmware problem.

Can you think of any more test I can do and any more data I can gather to help you fix this?
Anything to be learned from AR488 debug output? Is it possible to run in over the CDC USB port but log the debug output over the hardware port to keep the streams separated and avoid debug data to interfere with normal operation?

Best regards.

[tom_iphi]

Hi John,
I have started playing with your ESP8266 firmware again and I'm having troubles:
0.04.06 which does not have SSL yet works fine in both AP and Client mode.
0.04.11 with SSL works well in AP mode (have tested this before, now I know I have to enter https:// :-) ), but when I switch it to Client mode it won't connect to my home AP, but fall back to AP mode.
Any hints or any test I can do?
Best regards, Tom

[WaveyDipole]

Thank you for posting that. That must have taken some delicate surgery!

This prompted me to have a look at the datasheet for the 328p and I discovered also that it has a built-in temperature sensor (section 24.8, p 256) via ADC8 so one could possibly also log the temperature of the chip if one wanted.

Built in temperature sensor is a joke, together with built in voltage reference...
You can use built in temp sensor to look at gross trends but not much more than that.
External temp sensors ar not that expensive..

Thank for the perspective. I only noted from the datasheet that it was there but given how cheap the chip is didn't expect it to be particularly accurate or serving any practical purpose other than showing the temperature of the 328p chip.

[WaveyDipole]

To make sure the issue is not related to the USB CDC port, I switched over to using the Leonardo hardware serial port (RXO, TXI lines) instead and hooked it up to a CH340 USB to serial converter, also directly plugged into the PC.
The behavior is exactly the same as with CDC. Host initiated plots transfer just fine. Instrument initiated plots initially start with the already discussed delay of about 10s and when the transfer is complete, the AR488 no longer reacts to commands like ++ver and 7470.exe crashes. Disconnecting from the GPIB bus is not enough to recover communication, only a power cycle will do the job.
So, this appears to be not some kind of "dirt effect" but a real firmware problem.

Can you think of any more test I can do and any more data I can gather to help you fix this?
Anything to be learned from AR488 debug output? Is it possible to run in over the CDC USB port but log the debug output over the hardware port to keep the streams separated and avoid debug data to interfere with normal operation?

Best regards.

Tom, thanks for confirming you are not using wireless of any kind. Your test was a good idea and shows that the problem is not the serial transmission method neither CDC nor UART. I have been back to those LA traces you provided and they don't show any interference on the GPIB bus wires. The trace is near identical to the Prologix. You also mentioned a few posts back that it seemed to work OK in terminal and you provided a terminal capture to show that.

Following on from that, I would like to confirm that you ran the Prologix GPIB Configurator (prologix.exe) supplied with the KE5FX tools and whether it detected the AR488 interface? Also, after successful detection, did you click the 'Update CONNECT.INI' button to save the detected settings (or else manually edited the file via 'Edit CONNECT.INI')? I think you said this worked OK with the Prologix so you may have done this at least once,  but since the Prologix and AR488 would present on different COM ports, the CONNECT.INI would need updating each time the interfaces are swapped or you wanted to switch between them. Apologies if you have already provided this info although I couldn't see it while scanning back through the discussion. I'm still not ruling out a firmware problem, but would like to eliminate the possibility that the 7470.exe program is not communicating with the intended serial port from the equation.

Is it possible to run in over the CDC USB port but log the debug output over the hardware port to keep the streams separated and avoid debug data to interfere with normal operation?

Not at present, but its an excellent idea and I will add this as a feature.

In the meantime, all debug levels as well as ++verbose must be turned off (debug by commenting out in the sketch) otherwise as you point out, they will interfere with the correct delivery of the plot.

Hi John,
I have started playing with your ESP8266 firmware again and I'm having troubles:
0.04.06 which does not have SSL yet works fine in both AP and Client mode.
0.04.11 with SSL works well in AP mode (have tested this before, now I know I have to enter https:// :-) ), but when I switch it to Client mode it won't connect to my home AP, but fall back to AP mode.
Any hints or any test I can do?
Best regards, Tom

This is curious since the code for connecting to and configuring WiFi is identical in both versions - it has not changed. The only difference in in the firmware is that the latter has SSL capability added to the webserver, but this should not impact being able to connect to a WiFi router.

I have a couple of suggestions:

1. In version 0.4.11, comment out the following section (lines 847 - 849):

Code: [Select]

#ifndef DISABLE_SSL
  configTime(3 * 3600, 0, "pool.ntp.org", "time.nist.gov");
#endif

2. If that does not make any difference, then compile with DEBUG_0 and DEBUG_1 enabled in the sketch as well as with enabling Debug in the Ardiono IDE (set Tools => Debug Port: to your serial port ) and set Debug Level to "wifi". Open the Serial Monitor which should generate some output including after you after you hit 'Apply' on the WiFi configuration page. Let me have a copy of that output.

[tom_iphi]

Hi John,

Following on from that, I would like to confirm that you ran the Prologix GPIB Configurator (prologix.exe) supplied with the KE5FX tools and whether it detected the AR488 interface?

Yes, I did and it has worked as intended.

Also, after successful detection, did you click the 'Update CONNECT.INI' button to save the detected settings (or else manually edited the file via 'Edit CONNECT.INI')? I think you said this worked OK with the Prologix so you may have done this at least once,  but since the Prologix and AR488 would present on different COM ports, the CONNECT.INI would need updating each time the interfaces are swapped or you wanted to switch between them. Apologies if you have already provided this info although I couldn't see it while scanning back through the discussion. I'm still not ruling out a firmware problem, but would like to eliminate the possibility that the 7470.exe program is not communicating with the intended serial port from the equation.

I did update connect.ini. This is not the issue. 7470.exe DOES receive plot data from the AR488 and display it, but at the end of an instrument initiated plot, the AR488 apparently gets into an endless loop where it no longer responds to COM commands and thus 7470.exe terminates with an error message. By looking at debug messages it should be possible to find out in which part of the firmware code the AR488 gets stuck. What should I look out for?
Btw, is the AR488 com port interrupt driven or is it polled in the main loop?

Thanks for the hints on the ESP8266 firmware. Hope to try these out over the weekend.
Best regards,
Tom

[artag]

Btw, is the AR488 com port interrupt driven or is it polled in the main loop?

For the hardware serial port I believe it has a small (16 byte) buffer which is filled by an interrupt handler. It has to be emptied by user code in the main loop.

This may (probably does) differ for the simulated uart over USB.
 

[tom_iphi]

Hi John,

1. In version 0.4.11, comment out the following section (lines 847 - 849):

This has indeed helped, many thanks. Now, I get a stable connection in client mode, both with dynamic and static IP.
Is the time server causing trouble by responding too slowly?
Maybe a software switch to disable this feature would be useful.

Best regards,
Tom

[WaveyDipole]

I did update connect.ini. This is not the issue. 7470.exe DOES receive plot data from the AR488 and display it, but at the end of an instrument initiated plot, the AR488 apparently gets into an endless loop where it no longer responds to COM commands and thus 7470.exe terminates with an error message. By looking at debug messages it should be possible to find out in which part of the firmware code the AR488 gets stuck. What should I look out for?
Btw, is the AR488 com port interrupt driven or is it polled in the main loop?

Thanks for confirming these aspects of the setup and for clarifying the extent of the problem. I had thought that the AR488 was not responding at all for an instrument initiated plot so my apologies for having mis-understood this. Since the plot data IS being received and displayed, the hang up at the end is most likely to be caused by the receive loop not terminating. The 32u4 does not support SerialEvent, so the serial port is polled in the main loop. Having access to the serial interrupt on some boards allows a number of characters to be moved to the command processing buffer in the background, but either way any GPIB transmission in progress must complete before further command processing can continue.

I would suggest enabling DEBUG7 and I would be looking at whether the loop stops as indicated by an 'After loop' output and the value of tranBrk. Theoretically, if an EOI has not been received, the loop should terminate after a timeout, but perhaps this is not happening.

Hi John,

1. In version 0.4.11, comment out the following section (lines 847 - 849):

This has indeed helped, many thanks. Now, I get a stable connection in client mode, both with dynamic and static IP.
Is the time server causing trouble by responding too slowly?
Maybe a software switch to disable this feature would be useful.

Best regards,
Tom

Thanks for confirming that. The time server seems to be crashing and causing the module to fallback to its designed failsafe mode, which is to revert back to AP mode with default settings. At this time, I am not sure what is making it crash, but I am going to implement NTP time using a different approach using time.h which is now provided with the ESP8266/ESP32 library. Time is only really relevant when the ESP8266 is operating in client mode, connected to a router with Internet access and using SSL. This is because SSL certificates are time sensitive. NTP may also be relevant if time stamped log data is required, in which case, I agree it might be worthwhile having the option to turn timestamps on and off for logging purposes and to configure the desired NTP server to connect with and even perhaps adding in an RTC as a time source.

[tom_iphi]

Hi John,

I would suggest enabling DEBUG7 and I would be looking at whether the loop stops as indicated by an 'After loop' output and the value of tranBrk.

I have just tried this. The idea was to mimic what 7470.exe is doing manually via a terminal program.
Without debug settings this works.
With DEBUG7 activated the plot data never comes and the spectrum analyzer trows an error message.
All the same, serial communications locks up.
Here is the logged com port traffic:

Code: [Select]

++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Start listen ->
TRNb: 0
rEOI: 0
ATN:  HIGH
4F 50 3B D A After loop:
TRNb: 0
ATN:  0
<- End listen.
250,279,10250,7479
++ver

Note that after me entering the plot coordinates "250,279,10250,7479" the instrument should send the plot data which it doesn't with DEBUG7.
No answer from the AR488 to my ++ver at the end.

Best regards,
Tom

[WaveyDipole]

Here is the logged com port traffic:

Code: [Select]

++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Start listen ->
TRNb: 0
rEOI: 0
ATN:  HIGH
4F 50 3B D A After loop:
TRNb: 0
ATN:  0
<- End listen.
250,279,10250,7479
++ver

Note that after me entering the plot coordinates "250,279,10250,7479" the instrument should send the plot data which it doesn't with DEBUG7.
No answer from the AR488 to my ++ver at the end.

Best regards,
Tom

Tom, can I confirm the sequence please?

Looking at this it seems that the instrument first sends the sequence (hex =4F 50 3B D A; ascii = OP; CR LF) which is being received. I presume that the instrument sends this on pressing 'Hardcopy'?

You then send the co-ordinates, 250,279,10250,7479, emulating what the HP7470 program would respond with.

You then expect to receive the plot data in return?

Communication locks up at this point both with and without DEBUG7 turned on?

Is this correct?

If so, then what seems to be happening, is that the character sequence comprising the co-ordinates string is just sitting in the buffer. The subsequent ++ver command is then added to the buffer which is still waiting for the co-ordinates to be sent over GPIB to the instrument which is not happening, so requested actions are getting queued up. If my surmise is correct then hopefully the attached should work. Just replace the existing AR488.ino file. Keep all other files the same.

[tom_iphi]

Hi John,
many thanks for the new version.
Congratulations, you were spot on!
Now, instrument initiated plots from my HP8593E work flawlessly!
And plot data is coming a lot quicker than before!   
Many thanks again for your great work and best regards, Tom

[WaveyDipole]

Hi John,
many thanks for the new version.
Congratulations, you were spot on!
Now, instrument initiated plots from my HP8593E work flawlessly!
And plot data is coming a lot quicker than before!   
Many thanks again for your great work and best regards, Tom

Thank you for the confirmation. I will get this fix added to the official release shortly.