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.
I spent quite a bit of time looking at the timing today. Since I do not have the instruments that the problem was observed with and cannot replicate the problem here, I could only compare the behaviour of Emanuelle's code and mine. My investigation did reveal what seems a minor difference in behaviour of the interface when transitioning between addressing the instrument and reading data. I have tinkered a little with the code to try and address this issue, but it seemed to have little or no impact when reading my Solatron meter so the investigation was otherwise inconclusive.
I did notice that the UNO reads my Solatron meter OK, but the NANO does have a problem with misreading the first character. Having looked at traces on the logic analyser, the reason could be tracked down to a spurious blip on D3 (A2) which occurs just a fraction after the start of the handshake to read a character. Consequently the value of the byte on the bus is being mis-read as 0x2F instead of 0x2B resulting in '+' being transformed into '/'. The effect is reproducible and consistent and occurs regardless of whether I use the GPIB6.1 or the AR488 code. It does not occur on the UNO board works perfectly fine every time. It would therefore seem to be a problem with the NANO. Once key difference is that the UNO has a proper shielded cable to the instrument, whereas the NANO sits on a prototype board and is hooked up to the UNO via Dupont wires, so it could be that the jumper wires are picking up interferance from something.
I have now uploaded an modified sketch (AR488.ino.0.46.12a) to the GitHub, but I consider this an experimental version rather than a release, which is why I have placed it accordingly in a directory called 'Experimental'. As per suggestions earlier on the thread, I have also added 3 commands for configurable timing parameters:
++tmc - settling time after changing GPIB control state
++tmd - settling time after placing a data byte on the GPIB data bus
++tml - read loop delay (delay between reading characters)
Each parameter can be set between 0 and 255 microseconds.
The default settings are tmc =3, tmd = 3, tml = 0; Please note that if a configuration has been previously saved in EEPROM, then the values of 255,255,255 (i.e. 0xFF) will be read back from the empty EEPROM space, so these parameters will need to be set with the appropriate command and the configuration saved with ++++savecfg command. Alternatively, use +default, then set up the interface as required and save the config with ++savecfg.
I would like to request further observations about the following:
1. Is there a correlation with the board being used, i.e. does the problem happen only on the NANO or on both NANO and UNO?
2. Does changing the newly added timing parameters have any effect?
3. Is there anyone with a meter that exhibits this problem that also has a Logic Analyser and could provide me with a trace, particularly of the ATN, NDAC, NRFD and DAV signal lines along with the data lines (A01 thru A04 would probably suffice for reference but all 8 bits would be ideal) while doing a ++read command for reference?
Incidentally, an issue was logged on the GitHub by 'cabo' to point out that I had omitted the ground connections in the cross-reference table in the manual. My apologies for this and hopefully no one would have omitted a ground connection from their interface assembly, but a ground connection is essential and the details have now been added to the manual.
Any information that can help nail this problem will be much appreciated.
Would it be a big problem to move the SRQ and ATN pins to port B ? That's Uno / Nano pins in the range 8-13.
Since Pins 8-12 are already occupied, there is only one pin, pin 13, left remaining on port B. On the UNO, that pin is connected via a resistor to an 'internal' on-board LED. This electrical difference was the reason why I was advised to avoid using pin 13 as a standard IO pin. I don't think that the NANO has this arrangement but the LED could be removed from the UNO if desired. There is also pin 6 available on port D. It would have been nice if the 8 control signals could be placed on one port and the 8 data signals on another, but alas this is not possible with the layout of the 328p.
Looking at the datasheet for the 32u4 it looks like at bit of work would be required to re-shuffle things and although I am not averse to this, there are other differences such as the position of the Tx and Rx pins which would make obtaining a consistent layout between the 328p and the 32u4 difficult. I will need to have a think about how to approach this.