AR488 Arduino-based GPIB adapter

[WaveyDipole]

Yes, I am a little surprised as well, especially as the focus seemed to be on timing, but I wanted to test from all angles. This may not mean that the problem is caused by the SCPI language per se, but there may be a factor such as a particular character, character sequence or length of response or some other factor that messes things up. Ascii characters such as the colon or asterisk should have no bearing. Further investigation and analysis will be required.

Anyone have an EZGPIB or Python script for a Keithley DMM that they use so I can get some idea of the SCPI command sequences that are being used?

What I have found is that if I do a *idn? followed by a ++read this returns the full version string every time, although each subsequent response is displaced to the right and one line down from the last rather than from the beginning of a new line. The effect is similar when I do ++auto 1 and then repeatedly type :data. However, when I start to use other commands things get a "interesting" and unpredictable and I start to get errors. I did notice that if you use commands like *cls with ++auto set to 1 then the meter would sound a beep and return error 420, which one might expect since there is no response to read. Here ++auto 2 worked better. I am however just experimenting and issuing commands manually from a terminal rather than at speed from a script.

[macboy]

Hi, I've built the Arduino GPIB interface and connected it to my Datron 1065.  I've fired up EZGPIB and run the debug messages to test the setup.  I know the arduino is on Com9 but the EZGPIB debug message is reporting that Com9 has been opened but no CTS signal detected and thereafter disregards the port.  The AR488 manual identifies an issue with the ch340g chip not asserting a CTS signal and suggests a work around by connecting pin 14 to pin 9 on the chip.  The Arduino I've got is a Uno R3 which uses an ATmega16U2 as the UART-USB adaptor, so is there a similar work around for the ATmega16U2 that will provide a CTS signal?  Many thanks, Les.

The best solution to the handshake flow control issue is to actually implement the handshake. I prefer to buy UNO clones that have the handshake lines broken out into a header, like the following example. Note the unlabeled 4-pin header near the CH340 chip. This has handshake lines on it. You can see that pins 9, 10, 12, 13 are connected to the header, and these are CTS, DSR, DCD, DTR. The software changes to implement the handshaking on GPIO pins are trivial.
By implementing the handshake, you can improve reliability of all serial communication substantially.

[WaveyDipole]

I have uploaded an update (0.46.12d) into the "experimental2 folder on the GitHub. This update should mark a significant improvement towards solving the problem with the corrupted readings being obtained when the interface is used with a Keithley series 2000. It now seems to work fine on a UNO connected to the Keithley 2000 here with commands such as *idn?, :read?, :fetc? and :meas? and *rst, with commands both typed in at the terminal and called from a short python script. I am a bit cautious about calling it a fix at this stage as it has not yet been tested on any other instruments that have exhibited this problem, and there are numerous individual SCPI commands that have not yet been tested.

I am expecting that the timers will no longer make any difference and they can probably be set to zero. Depending on feedback, I may remove them completely when the next version is released as I now believe that any effect they had was co-incidental.

[artag]

Well done !
Briefly tested on K2015 and HP53131A and seems OK. Will try some other instruments when I get a chance

[uslrs]

Thanks for that - I've got the same Uno clone, so will have a crack at getting the handshaking sorted, so that EZGPIB is usable.  I've managed to get the Datron communicating via Realterm and the ++auto 3 command has allowed me to set up a data logging function using Realterm's capture facility, so making some progress.  I'm now attempting to find out how to remotely control the function and range settings on the Datron - not had much success so far, but pleased that I can now read data into the PC.  Onwards and upwards!

[maxwell3e10]

I tested the new version d and it seems to work OK in terms of transmitting all the strings properly. The ++llo and ++loc also work as intended. The only problem that I found is with inconsistent response for ++auto 1 command.

For  Agilent 33512 it does not automatically return an answer for *IDN? command, but returns an answer for FREQ? command. On the other hand, for Keithley  DMM7510, it responds properly to *IDN? command but does not respond to read? command. In all cases, the answer can be obtained by sending an extra ++read command.  See attached log file.

It would be really nice to add a couple of extra functionalities to this program. One would be to have a loop where it sends one string over and over and reads the response. One could have something called auto_str that can be set to save the command string (like "FETCH?") to be send to the instrument to get a response.

Another functionality is to have a skeleton for a custom routine that can be added to Arduino code by the user. Here one can program a more complicated series of commands for processing (such as limit checking or basic arithmetic). This will shift the program to the Arduino, so the output can be used easily for logging, for example, without requiring another programming layer.

[WaveyDipole]

For  Agilent 33512 it does not automatically return an answer for *IDN? command, but returns an answer for FREQ? command. On the other hand, for Keithley  DMM7510, it responds properly to *IDN? command but does not respond to read? command. In all cases, the answer can be obtained by sending an extra ++read command.  See attached log file.

Thanks for your further feedback. I could partially replicate this on the Keithley here. After power up I could send an *idn? and the DMM would reply with its ID string. I then send a read? and get a beep with a -213 (init ignored) error. Subsequent read? commands always result in a beep although sometimes a reading is returned. A logic analyser trace showed the command string terminated with a CR+LF always gets sent to the meter, but the meter, more often than not, does not return any data. By contrast, the fetc? command seemed to work every time. If I sent a meas?, a reading was returned and after that, all 3 commands - fetc?, read? and meas? would work normally without any beeps. It seems that at least in this respect, the meas? command behaves differently from read?, at least on the Keithley. After a power cycle it was back to the same behaviour.

After a bit of digging I found a reference that suggested that if the meter returned -213 errors, then sending an *rst command should clear it. So I power cycled the meter, did and *idn? and followed this by *rst and sure enough all 3 commands now worked OK without any bleeps. So was the *idn? command leaving the meter in some sort of error state? To test this, I power cycled the meter again and this time without sending a *idn? command, just started sending read? commands, but got the same problem result. Therefore it was nothing to do with the *idn? command and once again sending an *rst cleared it.

At this point in time, I don't know why the DMM is behaving in that way. I did notice that when the meter is power cycled, after starting up, it sits periodically refreshing its display with a reading. It continues to do this even after sending an *idn?, read? or fetc? commands. However after sending an *rst, the display shows  "------- VDC" until a read? or meas? is sent, at which point it will show a reading. Not surprisingly if a fetc? is sent while there is no reading displayed, the meter returns an error as no data is available yet. If you send a read? after the *rst, or send a meas? at any time (either before or after an *rst), the display shows a static reading and no longer refreshes periodically. It therefore seems that meas? and *rst both stop the meter from automatically taking readings (equivalent to ':init:cont off' perhaps?), but read? does not, and will display readings without error only after an *rst. The meas? command does not require additional commands such as *rst to be sent. Not sure if that is significant, but clearly meas? and read? behave differently on the Keithley.

It would be really nice to add a couple of extra functionalities to this program. One would be to have a loop where it sends one string over and over and reads the response. One could have something called auto_str that can be set to save the command string (like "FETCH?") to be send to the instrument to get a response.

Another functionality is to have a skeleton for a custom routine that can be added to Arduino code by the user. Here one can program a more complicated series of commands for processing (such as limit checking or basic arithmetic). This will shift the program to the Arduino, so the output can be used easily for logging, for example, without requiring another programming layer.
[/quote]

Implementing the command loop should not be too difficult, but the second function is a rather more complex proposition. Given the memory constraints of a Nano or Uno, the "complicated series of commands" would have to take no more than 256 bytes of memory, and that is provided it can be implemented in a way that does not impact adversely on the already tight runtime memory. The Mega2560 has greater memory capacity and would offer more possibilities in this regard. It might just be pushing things a bit too far on the Nano and the Uno.

I will have an attempt at implementing the first function, but will have to give the second one some careful thought.

[artag]

Is that because the data segment would be too big  ?

The situation could be improved by putting any required command strings in program memory. This has been done for most of the internal strings though a scattering still need it. There are also some command and pointer tables in ram that could possible be moved.

There seems to be plenty of program memory available still.

[WaveyDipole]

Is that because the data segment would be too big  ?

The situation could be improved by putting any required command strings in program memory. This has been done for most of the internal strings though a scattering still need it. There are also some command and pointer tables in ram that could possible be moved.

There seems to be plenty of program memory available still.

While it is possible to use flash (program) memory to store static strings at compile time (such as error and other messages), AFAIK it is not possible to use this space dynamically. Any commands entered by the user at runtime would have to be saved in EEPROM memory, otherwise they will not survive a restart. Such commands would also have to be retrieved and parsed at runtime. That process would, in turn, take up significant amounts of SRAM. I suppose it might be possible to use something like a PROGMEM structure to hold the commands within the sketch itself, but the commands would be hard-coded so to speak and not possible to change at runtime.

[artag]

Yes, that's correct about the progmem segment, but I read maxwell3e10's suggestions as

1. Provide a single command that would be executed repeatedly - so you'd set the instrument and interfaces into the correct mode and then repeatedly enter "fetch?" or whatever. 

Sounds useful, might need multiple commands (meas, read?) for some instruments, and I'd ask for a configurable delay too.

2. A way to make a special version of the interface that sets up and operates an instrument from power-up, with the necessary commands in arduino code. If this used F() strings for any embedded HPIB commands, they wouldn't take precious data segment space. I don't understand this as a request for a higher level command execution unit that would accept and store a scripting language.

I would think this would require a function to provide an interface command (like rst, or addr), a function to send a string on the bus, and a function to receive a result. Parsing the result and changing the program flow, if required, would be in arduino code but a fairly simple sequence would do to set up the instruments and make repeated reads which would then be sent back over USB like talk-only mode.

[texaspyro]

A program can write flash memory on an AVR... otherwise boot loaders won't work.  You may have to put the writing code in the bootloader section with some chips.

[maxwell3e10]

Regarding the reply for ++auto 1, part of it could be due to getting out of sync with available data. But maybe adding a little delay between sending a command and executing a read will help. In my limited testing, if there was no immediate response, then executing another ++read command by hand would always return the correct answer.

Regarding the programming options, the first one was meant to be defined at run time. One would give a string (could have a few commands separated by semicolon, but probably much less than 100 characters) and expect a single response from the device. Whatever initial setup would be done  by hand (either remotely or on front panel). The arduino code just needs to have one additional fixed loop with the user-defined string sent to the instrument and a ++read command.
 
For the second option I meant it to be hard-coded for a given instrument into the arduino sketch and compiled by the user. It might be similar to what one would put into a short EZ-GPIB script: A few initialization commends and a loop which maybe gets several responses from the device and combines them in some way. The main advantage of Arduino is that it can be easily reprogrammed on the fly over the same USB, so one can play with scripts specific to the instrument. It can be hard-coded with GPIB address, so upon boot up it configures the device and starts to send data.  Here one needs just a couple of extra run-time commands, to start and stop the script and an auto-start option, and an example arduino code loop that users will modify. The total length for the code and fixed command strings would be fairly small compared with the rest of the program.

[WaveyDipole]

Regarding the reply for ++auto 1, part of it could be due to getting out of sync with available data. But maybe adding a little delay between sending a command and executing a read will help. In my limited testing, if there was no immediate response, then executing another ++read command by hand would always return the correct answer.

I also observed that when :read? fails to return a result, a subsequent ++read command will usually return one. I found that the problems are more pronounced on my Nano than on the Uno but when I experimented introducing various delays, the results were mixed. I'm still working on that one...

Regarding the programming options, the first one was meant to be defined at run time. One would give a string (could have a few commands separated by semicolon, but probably much less than 100 characters) and expect a single response from the device. Whatever initial setup would be done  by hand (either remotely or on front panel). The arduino code just needs to have one additional fixed loop with the user-defined string sent to the instrument and a ++read command.

I have uploaded the next version (0.46.15) which includes a first stab at this feature. This version has no ++tmc, ++tmd and ++tml timing parameter settings. Instead, there is just one settable parameter called ++tmbus which is equivalent to the only parameter that actually made any difference during experimentation.

The new feature can be accessed via the ++repeat command as follows:

++repeat count delay commandstring

Count can be anything from 2 to 255 (a count of 1 would not be 'repeat'). The delay can be anything from 0 to 10,000 milliseconds (or 10 seconds). The parameter buffer currently has 64 characters so the command string plus the numeric parameters cannot exceed 64 characters in total. At present there is no mechanism to stop the repeat loop once it has begun. It will keep running until it is complete.

For the second option I meant it to be hard-coded for a given instrument into the arduino sketch and compiled by the user.

Ah, in that case this should be achievable, and indeed possible to implement using Arduino's PROGMEM feature. I will investigate further and experiment with it.

[WaveyDipole]

Just posted a further update (0.46.16) which now has a startup script feature. It is also now possible to enter commands in upper or lower case as well - i.e. ++auto 1 or ++AUTO 1 are both now acceptable.

The startup script can be enabled by un-commenting the define:

Code: [Select]

//#define STARTUP
by changing the line to :

Code: [Select]

#define STARTUP
The script itself is found in the DEFINED SCRIPTS section just below the help information. Due to the way that strings in program memory are implemented on the Arduino, the STARTUP script is composed of two sections which unfortunately means that is looks rather convoluted:

Code: [Select]

#ifdef STARTUP
const char start01[] PROGMEM = "++addr 7";
const char start02[] PROGMEM = "++auto 1";
const char start03[] PROGMEM = "*IDN?";
const char start04[] PROGMEM = "*RST";
const char start05[] PROGMEM = ":func 'volt:ac'";
const char * const startup_script[] PROGMEM = {
  start01,
  start02,
  start03,
  start04,
  start05
};
#endif
The first section is a list of 'const char startxx' definitions which define the individual command strings. Any number of command strings can be added simply be adding more 'const char' string definitions as follows:

Code: [Select]

const char start[i]xx[/i][] PROGMEM = "[i]commandstring[/i]";

where xx is the next consecutive and unique line number and commandstring is the command to be executed.

The second section is the the array defined as expression 'const char * const startup_script[]'. This contains the sequence of command strings that actually forms the startup script. In order for a command to be executed as part of the script, a corresponding entry (e.g. startxx) must be added to the sequence of elements in this array.

As I said, it does look a bit complex but it seems that this is the only way to get a list of character strings stored in program memory on the Arduino. Hopefully, it is still obvious what is happening here. Trying to simplify it by doing something like:

Code: [Select]

const char * const startup_script[] PROGMEM = {
  "command1",
  "command2",
  "command3",
};
simply does not work because the strcpy_P command required to retrieve the strings from program memory into a buffer at runtime, does not retrieve the correct characters. It seems that the strings have to be individually defined before they can be stored in the array.

It would, perhaps, be possible to store one long list of commands, separated by a suitable delimiter character, as one long string, however, this approach does have a couple of disadvantages:

- a long string of characters is more difficult to read as a script, especially when the line starts to wrap
- at runtime, the string as a complete single entity (i.e. the whole script) would have to be copied into runtime memory first before it could be parsed. The impact on runtime memory would depend on the length of the script and could be unpredictable.

Using an array of strings means that only one command needs to be copied at a time, keeping things relatively efficient. Using this approach would probably allow for the possibility of creating additional scripts which could be activated, say, via a ++macro command at runtime while minimising the impact on runtime memory.

There is probably further work required and I may need to add the option to pause between commands, but this short script worked on my Keithley to set it ++auto 1 and the meter into AC volts mode.

[artag]

Code: [Select]

const char * const startup_script[] PROGMEM = {
  "command1",
  "command2",
  "command3",
};


Yes, that defines the array to be of type PROGMEM, it doesn't say that about the strings themselves. The whole thing about memory types is something of a hack to C and using two tricks at once - auto-initialised arrays and memory types - may be asking too much. Some advice from comp.lang.c or use of the 'cdecl' utility might be helpful.

Another option is to use either preprocessor or string concatenation tricks to rearrange it. Note that
"abc" "def"; is identical to "abcdef", so a single long string with embedded separators can be rearranged as a series of separate lines without any difficulty. If it's actually entered as

"command 1\n"
"command ?\n"
"++read\n"

and the characters copied from newline to newline instead of end of string, then most of the other difficulties can be skipped.

I would say use whatever is the simplest option for now and revisit it when it's seen some use : there may well be changes it is worthwhile making for other reasons.

[WaveyDipole]

atrag, thanks for your helpful comments. I have now uploaded version 0.46.20. The macro feature as I've now called it, has been refined. The sketch now supports up to 9 user macros that can be called at runtime in addition to the startup macro. All macros must be defined at compile time before uploading the sketch to the Arduino.

The construction of macros is now much simpler. Here is an example of the startup macro:

Code: [Select]

const char startup_macro[] PROGMEM = {
  /* Insert startup macro here ->*/
  "++addr 7\n"
  "++auto 1\n"
  "*RST\n"
  ":func 'volt:ac'\n"
  /*<-End of startup macro*/
};
It is now necessary for the user to change only the code between the two comments. The lines must be between double quotes and a '\n' newline character is required to delimit each line. The '\n' at the end of the last line of the macro is optional.

The startup macro is macro 0. There a 9 user defined macros labelled macro_1 to macro_9. Each macro can be run from the custom ++macro command. To run a specific macro, just specify its number, for example, to run macro 1, type:

Code: [Select]

++macro 1

Running ++macro without parameters lists the macros that have been defined by number. One possible enhancement might be to add a short description. Only the user defined macros, 1 - 9 can be run from the ++macro command. Macro 0 (startup) will only run at interface startup, i.e. when the interface is powered up or when a serial connection is initiated (the latter prompting a reset). Detailed information about macros has been added to the AR488 manual.

I am open to any observations or comments and am happy to tweak things or make improvements provided that they are practicably possible.

[maxwell3e10]

Thanks, I looked at the code and hope to play with it more this weekend. A macro would be useful in many cases, but I thought one could also do some more data processing. For example, if  using an input scan card, read several channels and output them all on one line. Or measure voltage and current and then calculate power.

This first requires a  different version of  gpibReceiveData(), which appends characters to a string instead of directly sending them to the serial port. It will of course have some limit on the maximum length of string. Then one would use toFloat() to get a number and perform some arithmetic before outputting the result to serial port. One could start with your ++repeat code and add some more general commands to it.

[maxwell3e10]

I tested the code with HP3457A. It works as intended. Regarding the reliability of ++auto command, it works well if one sets ++read_tmo_ms to 100 msec or longer. For slow commands I sometimes even increased it beyond 3 sec. Maybe a default value of 1 sec would be optimal with maximum allowed up to 30 sec.

For repeat command it would be nice to allow infinite repetition number, but still have a way to interrupt the loop. It could be programmed the same way as ++auto 3 command is programmed now, as part of the main loop.

[artag]

I think I recall that the correct IEEE-488 doesn't have a timeout. This is a pain, of course, but might explain why there is a wide variation of the speed with which results are returned. Most implementations do actually time out but the default may be quite long, especially on older interfaces.

[WaveyDipole]

Thanks, I looked at the code and hope to play with it more this weekend. A macro would be useful in many cases, but I thought one could also do some more data processing. For example, if  using an input scan card, read several channels and output them all on one line. Or measure voltage and current and then calculate power.

Will have a think about that one. Also, a scan card would be required to develop and test this feature. I don't see any on eBay at the moment but I will keep an eye out in case one turns up for a reasonable price. In the meantime, I will see what I can do about doing some basic math like measuring power, however, this would assume that the DMM is capable of taking both measurements at the same time.

Regarding the reliability of ++auto command, it works well if one sets ++read_tmo_ms to 100 msec or longer. For slow commands I sometimes even increased it beyond 3 sec. Maybe a default value of 1 sec would be optimal with maximum allowed up to 30 sec.

For repeat command it would be nice to allow infinite repetition number, but still have a way to interrupt the loop. It could be programmed the same way as ++auto 3 command is programmed now, as part of the main loop.

Points noted and added to my work list.

[maxwell3e10]

Will have a think about that one. Also, a scan card would be required to develop and test this feature. I don't see any on eBay at the moment but I will keep an eye out in case one turns up for a reasonable price. In the meantime, I will see what I can do about doing some basic math like measuring power, however, this would assume that the DMM is capable of taking both measurements at the same time.

These are just examples that came to mind (I happen to have an HP3457 with a scan card). Once there is a gpibReceiveDataToString() function that returns the GPIB string within the program  the user can build an arbitrary complicated program (subject of limitations of the processor). I am planning to write a couple of such programs for the HP3457 but anyone could adapt it to their instruments and applications.

[artag]

I've looked out for a keithley scan card but they're usually a bit pricy for my minimal likely usage. It's just the compulsion to fill that empty slot in the meter

However, the schematic is available and pretty simple. If you want a simple mux it would be easy enough to clone and I'm tempted to do that sometime. If you wanted to use it for thermocouple signals it might need a bit more care.

I think I've got an older Keithley with a built in scanner (one of those hideous brown things) but it might be pre-SCPI. I've also got a Datron scanner but that's definitely pre-SCPI.

[Krampmeier]

I have just tried version 0.46.20 of the AR488 firmware. It works great with my Keithley 2010 now! 

I'd prefer if the allowed values for the ++read_tmo_ms could be extended a bit though. If I use long integration time and averaging, it can take way more than 3 seconds before the DMM answers to a :READ? command...

[WaveyDipole]

I've looked out for a keithley scan card but they're usually a bit pricy for my minimal likely usage. It's just the compulsion to fill that empty slot in the meter

However, the schematic is available and pretty simple. If you want a simple mux it would be easy enough to clone and I'm tempted to do that sometime. If you wanted to use it for thermocouple signals it might need a bit more care.

I was expecting that it might be a bit pricey, and I'm guessing from what you say that I would have the same difficulty justifying the purchase. I would be interested in the schematic. I had a look online but couldn't find it.

[WaveyDipole]

I've looked out for a keithley scan card but they're usually a bit pricy for my minimal likely usage. It's just the compulsion to fill that empty slot in the meter

However, the schematic is available and pretty simple. If you want a simple mux it would be easy enough to clone and I'm tempted to do that sometime. If you wanted to use it for thermocouple signals it might need a bit more care.

I was expecting that it might be a bit pricey, and I'm guessing from what you say that I would have the same difficulty justifying the purchase. I would be interested in the schematic. I had a look online but couldn't find it.

I have just tried version 0.46.20 of the AR488 firmware. It works great with my Keithley 2010 now! 

That is good to hear.

I'd prefer if the allowed values for the ++read_tmo_ms could be extended a bit though. If I use long integration time and averaging, it can take way more than 3 seconds before the DMM answers to a :READ? command...

I just stuck with Emanuelle Girlando's original parameters which I think were based on the Prologix, but I don't think there is any reason why the maximum limit couldn't be extended. I will add it to my list of tasks.