AR488 Arduino-based GPIB adapter

[GregDunn]

I was just planning to use the wiring diagram included in the .docx file unless there is in fact a later version?

[Miti]

Could this project be combined with this one
https://www.eevblog.com/forum/projects/project-extending-hp3478a-functionality/75/
If we redefine the pins?
At least for HP3478A.

[WaveyDipole]

I don't have Prologix's original software, but the behavior I observed with Girlando's code is that in ++auto 1 mode just one ++read command is issued after each command sent to the device. This generally make sense, since most GPIB instruments (except some meters in auto mode) don't have new data available in the buffer for reading at all times, only in response to a specific command.

On the other hand, for the case when data are available, it maybe useful to keep the auto mode as you have implemented it, simulating "Talk only" GPIB mode. So perhaps it would make sense to keep the continuous reading option that you have already implemented with something like ++auto 2 setting.

An even fancier implementation would be to look for "?" as the last character in the command sent to the meter. If there is a ?, then execute one ++read command, if not then don't execute the read command.  Otherwise, the ++auto 1 mode can still cause errors if a command doesn't generate a response from the device.

Thank you for those suggestions. An updated version has now been uploaded to repository on GitHub. This version fixes the #include naming clash which I am hoping that this gets rid of the remaining warnings. The behaviour of the ++auto command has also been modified and now behaves as follows:

++auto 0 = auto off
++auto 1 = auto on - (Prologix style?), executes a read after every command* string sent to the instrument
++auto 2 = auto on - executes a read only after a query ('?') terminated command string
++auto 3 = auto on - executes continuous reads after the first ++read command issued

*the interface does not distinguish between instrument commands, queries or data being sent to the instrument.

Please note that, ++auto 1 executes a read after sending any CR/LF terminated string to the instrument. It will execute a read after any direct instrument commands (e.g. ID? or TRIG), whether terminated with '?' or not. In the case of ++auto 2, a read is executed only after a string terminated with a '?' is sent, i.e. it responds only to queries. Currently neither option executes a read after any ++ commands. As far as I can tell, the only command where this might be useful is perhaps after the ++trg command. If such functionality is something that might be useful then I would consider adding it. Any thoughts?

would be nice to have a final schematic / wiring to be sure we dont miss something ??

I was just planning to use the wiring diagram included in the .docx file unless there is in fact a later version?

The pinouts between the Arduino and the GPIB connector are documented in the manual which is already on the GitHub repository:

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

There is no later version just yet, but assuming this update is OK, then I will be updating the text of the ++auto command. I was also considering drawing up a diagram or two in due course.

[GregDunn]

Both the current (0.46.01) and previous versions compiled without error on my Mac (1.8.9 hourly).  I am going to hack together a compatible GP-IB cable this weekend and test it out.

[Miti]

I get lots of warnings compiling on Windows 1.8.8.

[WaveyDipole]

I get lots of warnings compiling on Windows 1.8.8.

Thanks for your feedback.

I have been curious about this issue for a while since I have been compiling on both Linux with version 1.8.7 and Windows 10 with version 1.8.8 and not getting any errors or warnings. However, digging a little further this evening, I discovered that in preferences, there is a setting called 'Compiler warnings:'. Can I ask, what is it set to on your system?

In both environments on my computer this is set to 'None'. Since I have never changed this setting, it would seem that it was set at installation time. There are also settings for 'Default', 'More' and 'All', with 'Default' seemingly the logical default setting. Switching to 'Default' or 'More' does indeed bring up some warnings. I guess that someone in their wisdom decided at some point that hiding warnings was a good idea. If the value was set to 'Default' in earlier versions of the IDE and remained unchanged after subsequent upgrades, or perhaps some have made this change manually, then this would explain why some of us are getting these warnings whereas others (myself included) do not.

Looking at the warnings themselves, unused variables should cause no problems and these will be removed. I will have a closer look at the other warnings. Missing that setting is a bit of an embarrassing oversight, but now that the mystery is solved, I will now spend some time working through the code to eliminate these warnings and tidy things up.

[coromonadalix]

No problems on my 1.8.8 on Win10 x64   for an genuino or an uno 


Edit :  Damn    oh  if i put  compiler warnings at "default" it was settled by default to "none" in my installation,
I have tons of warnings, they repeats many times ??



ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]

invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]

In function 'void aspoll_h()':

[GregDunn]

   Indeed, it looks like the compiler warnings are disabled by default.

Other than the uninitialized index 'i' and the 'no return statement' warnings, mine look like unused variables and C++ related type conversion non-issues.  Those two might be of concern, depending on how each environment handles the variable space.

[GregDunn]

Still have a few minor warnings:

AR488.ino:1156:18: warning: unused parameter 'params' [-Wunused-parameter]
 void clr_h(char *params) {

[ x10 in different functions ]

and

AR488.ino: In function 'spoll_h':
AR488.ino:1368:12: warning: 'i' is used uninitialized in this function [-Wuninitialized]
   for (int i; i<15; i++){
            ^
AR488.ino: In function 'trg_h':
AR488.ino:1283:12: warning: 'i' is used uninitialized in this function [-Wuninitialized]
   for (int i; i<15; i++){
            ^
AR488.ino:1314:14: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized]
     for (int i; i<cnt; i++){
              ^

But they don't cause the compilation to fail.

[WaveyDipole]

I have just spent a couple more hours getting rid of the compiler warnings and have now uploaded an updated v0.46.02 sketch.

- commented out all unused variables
- corrected conversion issues
- corrected all no return statement warnings

I compiled with Compiler Warnings set to 'More' and worked through all of the warnings until I got to a point where there were no further errors or warnings. I did a few tests with my Solatron 7150 and all seems to work OK.

If one compiles with the 'All' setting then there are still warnings to deal with. It seems that I am now getting warnings on some of my workarounds!

[GregDunn]

Yes, if I set mine to 'more' I get no warnings.  I understand why the cast warnings in the cmdRec array would be hard to remove without redesigning it.

[coromonadalix]

me too   seems to compile faster too ......  were getting there loll   thks for your work

[WaveyDipole]

Just posted a minor update (0.46.3) to get rid of the remaining undefined 'i' variable warnings.

Its 02.00hrs in the morning here so I'm going to call it a night and have a think about this later, but, yes, I will need to have a think about the "unused parameter 'params'" related ones. It will require some re-designing of that array and the way it is processed I think.

[Miti]

Mine was set to All. If I change it to None, I don't get warnings but with All, I still get warnings even with 0.40.03. See the attachment.
I tried it with Arduino Uno on my HP3478A and it seems to work well.

Thanks for the effort!!

I also tried it with Arduino Pro Mini since I recently made a board for Kirill's project to extend the functionality of HP3478A. The difference is that it runs on Arduino Pro Mini and the pin allocation is a bit different. I changed the pins definition, it compiles without problems, it responds to ++ commands but I can't get it to control the instrument. I've attached the new file. Could you give me a hint why it doesn't work? I would really like to have that option since It is installed inside the instrument and I don't need a GPIB connector.
Thanks in advance,
Miti

[coromonadalix]

Same thing with the ''all" option only and the "default" and "more" shows nothing .......

Not sure if its the ide the problem,   ill try to find slightly older versions to test ??

---------------------------------------------------------------------------------------------------------------------------------------
warning: unused parameter 'params' [-Wunused-parameter]

void clr_h(char *params) {

                  ^
warning: unused parameter 'params' [-Wunused-parameter]

void ifc_h(char *params) {

                  ^
warning: unused parameter 'params' [-Wunused-parameter]

void rst_h(char *params) {

                  ^
warning: unused parameter 'params' [-Wunused-parameter]

void srq_h(char *params){

                  ^
warning: unused parameter 'params' [-Wunused-parameter]

void save_h(char *params){

                   ^
unused parameter 'params' [-Wunused-parameter]

void aspoll_h(char *params) {

                     ^
warning: unused parameter 'params' [-Wunused-parameter]

void dcl_h(char *params) {

                  ^
warning: unused parameter 'params' [-Wunused-parameter]

void default_h(char *params) {

                      ^
warning: unused parameter 'params' [-Wunused-parameter]

void ppoll_h(char *params) {

                    ^
warning: unused parameter 'params' [-Wunused-parameter]

void verb_h(char *params) {

                   ^

[maxwell3e10]

The behaviour of the ++auto command has also been modified and now behaves as follows:

++auto 0 = auto off
++auto 1 = auto on - (Prologix style?), executes a read after every command* string sent to the instrument
++auto 2 = auto on - executes a read only after a query ('?') terminated command string
++auto 3 = auto on - executes continuous reads after the first ++read command issued

*the interface does not distinguish between instrument commands, queries or data being sent to the instrument.

Currently neither option executes a read after any ++ commands. As far as I can tell, the only command where this might be useful is perhaps after the ++trg command. If such functionality is something that might be useful then I would consider adding it. Any thoughts?

I tested the ++auto modes, they work great! One nice thing about ++auto 3 mode is that it allows in some situations to use a simple serial plotter or logger program without having to continuously issue commands to the instrument.

A few bugs I found:
++status command returns "Unrecognized command"
++auto state is not saved by ++savecfg command

++trg command is typically used to trigger multiple instruments simultaneously. So it would usually require a more complicated series of commands to read different addresses.

[ejeffrey]

The problem I had with the prologix GPIB-LAN/USB devices is the eot_char implementation is basically defective.  The manual suggests it is recommended for use with binary data that is not normally terminated with a newline.  This doesn't make any sense since any character is valid binary data.  What is needed is to escape the termination character when it appears within the body of the response so that you can unambiguously determine the end of input.

[WaveyDipole]

I tested the ++auto modes, they work great! One nice thing about ++auto 3 mode is that it allows in some situations to use a simple serial plotter or logger program without having to continuously issue commands to the instrument.

A few bugs I found:
++status command returns "Unrecognized command"
++auto state is not saved by ++savecfg command

++trg command is typically used to trigger multiple instruments simultaneously. So it would usually require a more complicated series of commands to read different addresses.

Thanks again for the feedback. Can I just confirm that you used the ++status command in device mode? This command allows the user to set the status byte of the device to be returned to the controller in response to a serial poll. The command will not function in controller mode. Any command issued when the interface is set to a mode that it is not designed to operate in returns "Unrecognized command" as does the Prologix adapter.

You are correct that the auto setting is not saved to EEPROM. The Prologix manual states that it should be one of the parameters that is saved, so I will update the code to do this. I have logged an issue for this problem.

Same thing with the ''all" option only and the "default" and "more" shows nothing .......

Different settings will yield a varying number of warnings, presumably depending on the relative severity of each warning as determined by the compiler, evidently the 'All' setting being the strictest. So, how far does one need to go for released code to be acceptable? And why is the setting configured by default to 'None'?

Personally I think it is a good idea to heed all warnings because it forces one to think about the issues involved and follow good coding practices. Now that I am aware of this setting I intend to ensure that any further code will pass the 'All' level. I am aware of the reason for the remaining warnings and plan to do some work to remove them, but this will require a little bit of restructuring of the command parser. Hopefully it will not take too long.

I appreciate all of the valuable feedback. It has been very helpful.

[coromonadalix]

Once again  Thanks for all the time and efforts put in this project, i'll never thank you enough for your contribution   

[WaveyDipole]

Ok, I have now dealt with the remaining warnings and tested with the Compiler Warnings option set to 'All'. I have also updated the code so that the value of the auto setting is saved in EEPROM when a ++savecfg is issued. I have also updated the description of the ++auto command in the manual.

The updated sketch (version 0.46.10) and manual have been uploaded to the repository.

[GregDunn]

I'm not used to things working this easily. 

Loaded the sketch, bodged together a quick GPIB connector/cable, and plugged it into the 3478A - upside down.    This is what happens when you check every wire, every interconnection, and then assume that the connector is "right side up".       No harm done; flip it over, and it just works.  ++auto 3, ++read, and the DMM started dumping measurements as fast as it could go.  I was able to set ranges, modes, and local/remote easily.  Now to figure out how to script it so I can log measurements to a file.

Love it!

[Krampmeier]

I just tried v0.46.10. It compiled just fine, but I still get the problems with the first character of the device response, and the device going out of remote mode.

Keithley 2010

Code: [Select]

AR488 GPIB controller, version 0.46.10, 02/03/2019
⸮5.49378228E-01
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15  /A02 

Keysight E36312A

Code: [Select]

⸮eysight Technologies,E36312A,MY57290136,1.1.1-1.0.2-1.05
Keithley 196 - no communication at all, does not go into remote mode. Broken GPIB interface?

Adret 103A - works fine, but this is a "listen only" device.

Any ideas on what might be going wrong with the Keithley and Keysight devices?
I use about one meter of ribbon cable, not a genuine GPIB cable, but I have seen GPIB work fine with much longer ribbon cables, and 8 devices on the bus...

Edit:
The effect changes when DEBUG7 is defined and I switch verbose mode on:

Code: [Select]

> *idn?
> ++read
OAfter loop:
2
0
0
Bytes read: 1

> ++read
MTHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15  /A02 
After loop:
2
0
0
Bytes read: 54


[Miti]

I was able to set ranges, modes, and local/remote easily.  Now to figure out how to script it so I can log measurements to a file.

You don't need to. It's been done. 
https://www.eevblog.com/forum/testgear/free-hp3478a-multimeter-control-program/msg2136739/#msg2136739

[GregDunn]

Excellent - and in Python, no less.  That will save me some effort, thanks!

[maxwell3e10]

There maybe some timing parameters that need to be fine-tuned. For me it worked just fine with HP 3457A, but when I hooked it up to HP53310A, it would sometimes have problems, reading only the first character of the instrument's response string. If I upload the original Girlando's sketch to the same board, it works fine.

The repeated ++auto mode turned out to be really useful for streaming data. This made me think that with Arduino architecture one can go beyond the typical role of GPIB controller by shifting some GPIB commands to the Arduino itself. In this way it would be similar to the new DMM7510 and DMM6500 from Keithley that allow SCPI command scripts running on the instrument.

With Arduino, one would have the option of setting up some custom routines that send a few commands repeatedly or do some simple data processing. For example, some instruments need repeated FETCH? commands or in HP3457A one could read the high resolution register and add it to the reading before sending to the computer. With a simple template for such routine anyone could add commands within the Arduino IDE. This would make this GPIB-USB driver not only much cheaper, but also more powerful than anything on the market!