First character of ++read result is being garbled when reading some devices

[Twilight-Logic]

Reported by user Krampmeier on EEVblog, using version v0.46.10.

Version 0.46.01:

Communication with my HP 4192A impedance analyzer sees to work fine, but when I sent *IDN? to a Keithley 2001, the first 1 to 3 characters of the response were always wrong. Same with a Keithley 2010.

I just tried it again: Quote

*idn?
++read
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15  /A02
fetch?
++read
m9.59916086E-01
:SENS:FUNC?
++read
bVOLT:DC"

Edit: I just noticed that the Keithley's display twitches when I send the ++read command. The instrument also clears the "REM" indicator, so it goes out of remote mode. Hmmm. Did I make a mistake in the wiring?

Version 0.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

[Twilight-Logic]

Devices identified with the read problem:

Keithley 196 - no communication? Keithley 2000 - second (and possibly all alternate) read returns nothing Keithley 2001 - up to 1st 3 characters garbled Keithley 2010 - up to 1st 3 characters garbled Keithely 2015 - some reads OK, others showing just 1 character

Keysight E36312A

HP53310A

[Twilight-Logic]

Issue was related to a EOI signal detection error in the code. This is now fixed.

[ZeroV0LT]

I have the same problem with a device ILX LTD-5910.

I'm using current version that is:

AR488 GPIB controller, ver. 0.47.53, 25/10/2019

This device is a TEC temperature controller, if I read the current temperature I get always a 3 at begging of the string so that the "20.3" string become "30.3" and only very few times it read the right value.

If I read calibration string I get "�LX CALDATE 7-5-89" while it should be "ILX CALDATE 7-5-89".

Any help?

[Twilight-Logic]

Could you please enable DEBUG7 and DEBUG1 and also ++verbose send me the output please. Thanks.

[ZeroV0LT]

No problem, I should have some time this evening to give it a run.

[ZeroV0LT]

I had to fix a compile error when enabling debug1 ... at line 911 of the AR488.ino file it was using the old "plusCmdIdx" instead of "cmdHidx".

[ZeroV0LT]

Here is the log. Few words:

D2 - read current temperature - here should be 19.4 but it reads 39.4 G9 - read the calibration string - here should be ILX CALDATE 7-5-89 but it reads ËLX CALDATE 7-5-89

Welcome to minicom 2.7

OPTIONS: I18n 
Compiled on Apr 22 2017, 09:14:19.
Port /dev/ttyACM0, 20:43:06

Press CTRL-A Z for help on special keys

parseInput: Received ++verbose
isCmd: Command detected.
processLine: Received: 2B 2B 76 65 72 62 6F 73 65 
processLine: Sent to the command processor: 76 65 72 62 6F 73 65 
getCmd: verbose - length:7
getCmd: process token: verbose
getCmd: found handler for: verbose
Verbose: ON

> ++ver
parseInput: Received ++ver
isCmd: Command detected.
processLine: Received: 2B 2B 76 65 72 
processLine: Sent to the command processor: 76 65 72 

getCmd: ver - length:3
getCmd: process token: ver
getCmd: found handler for: ver
AR488 GPIB controller, ver. 0.47.53, 25/10/2019

> ++addr 4
parseInput: Received ++addr 4
isCmd: Command detected.
processLine: Received: 2B 2B 61 64 64 72 20 34 
processLine: Sent to the command processor: 61 64 64 72 20 34 

getCmd: addr 4 - length:6
getCmd: process token: addr
getCmd: found handler for: addr
Calling handler with parameters: 4
Set device primary address to: 4

> G9
parseInput: Received G9
processLine: Received: 47 39 
processLine: Sent to the instrument: 47 39 

> ++read
parseInput: Received ++read
isCmd: Command detected.
processLine: Received: 2B 2B 72 65 61 64 
processLine: Sent to the command processor: 72 65 61 64 

getCmd: read - length:4
getCmd: process token: read
getCmd: found handler for: read
CB 4C 58 20 43 41 4C 44 41 54 45 20 37 2D 35 2D 38 39 D A After loop:
0
0
Bytes read: 19

> D2
parseInput: Received D2
processLine: Received: 44 32 
processLine: Sent to the instrument: 44 32 

> ++read
parseInput: Received ++read
isCmd: Command detected.
processLine: Received: 2B 2B 72 65 61 64 
processLine: Sent to the command processor: 72 65 61 64 

getCmd: read - length:4
getCmd: process token: read
getCmd: found handler for: read
33 39 2E 34 D A After loop:
0
0
Bytes read: 5

[ZeroV0LT]

So I was checking the code and at first I cannot se what can go wrong, but than I noticed that you read just after setting the pullup bits. Maybe due to some capacitance in the adapter or instrument itself it takes some time to settle. So by just adding some delay should solve this issue. Unfortunately I cannot check this before this evening.

[Twilight-Logic]

Thank you for the detail you have provided. I ran some tests using the Keithley 2000 to make sure that the previous issue hadn't re-surfaced and I could not replicate the problem. There were no dropped or garbled characters. However, since I do not have a ILX LTD-5910 to test with, I am unable to verify the issue with that particular instrument.

Can I ask how you are connecting the instrument to the AR488 board? Are you using a cable of some sort, or a plug directly mounted on a PCB? Looking at the binary for the initial garbled characters, it does look like adjacent bits might be being randomly added to the original character, but this is by no means conclusive given a sample of only two items of data. Whether this is down to capacitance between adjacent wires or setting time I cannot be sure at this time, but these do seem plausible explanations.

Your suggestion of adding some delay just before reading the character from the bus is certainly worth a try. By all means add a few microseconds of delay and see what happens. I would certainly be interested in the result.

[ZeroV0LT]

Good news. Just changed read function to this:

uint8_t readGpibDbus() {
  // Set data pins to input
//  DDRD &= 0b11001111 ;
//  DDRC &= 0b11000000 ;
  DDRF &= 0b00000000 ;

//  PORTD |= 0b00110000; // PORTD bits 5,4 input_pullup
//  PORTC |= 0b00111111; // PORTC bits 5,4,3,2,1,0 input_pullup
  PORTF |= 0b11111111; // set PORTC bits to input_pullup

  delayMicroseconds(1000);

  // Read the byte of data on the bus
  return ~(PINF & 0b11111111);
}

and it now reads ok.

[ZeroV0LT]

I think the possible solution can be to add some configurable delay there like the other delay already used delayMicroseconds(AR488.tmbus); in gpibReadByte

PS: tested with 10us and was not working, 100us seems to do the trick.

[ZeroV0LT]

This is the adapter ... I don't think it can be the cause, most probably it's the instrument itself

[Twilight-Logic]

Thank you for carrying out that test and confirming that this worked. This would seem to confirm that some settling time needs to be allowed, at least for some instruments, after setting the pull-ups before data is read, although I would not have expected that a delay of 100µs would be necessary. Interesting to note that 10µs did not work as I would have expected no more than maybe 5µs. Could I trouble you to try 50µs and if that would, then maybe 20µs and 30µs? I will add a configurable delay to the next release. It would help if you could determine the minimal delay for your instrument, as that would provide a suitable benchmark for a default setting.

BTW, thanks for the picture of your adapter. Others have successfully used a ribbon cable and your cable is quite short so I would tend to agree that this is unlikely to be the cause unless you had a noise source (e.g. LED lamp, wallwart or something) close to the cable.

[ZeroV0LT]

No problem, I will make few more tests.

[ZeroV0LT]

Assuming all pins on the bus to have similar capacitance

I was thinking that if we pull-up data lines at the same time of unasserting NRFD both "pull-up" should have the "same" propagation delay over the bus. In this case we receive DAV after NRFD propagated to the other side, this should ensure also that all lines are pulled-up too and no additional delay is needed before we read from bus.

So by adding a simple readGpibDbus(); in function uint8_t gpibReadByte(uint8_t *db) just before unassert NRFD should do the trick.

What you think?

[ZeroV0LT]

Tested and readGpibDbus(); in function uint8_t gpibReadByte(uint8_t *db) just before unassert NRFD works ... so if this is ok, I think is the best solution.

[Twilight-Logic]

Thank you for spending a bit of time on this, doing the tests and coming up with an excellent solution! What I think I might do is split the readGpibDbus() function into two. The first function will set the lines to input pullup mode, and the second will just read the value on the bus. In fact, it might be better for the setting of the data bus to listen mode to happen just before the data read while loop in bool gpibReceiveData(). That way, it is only still set in advance of NRFD being unasserted and needs to be set only once before a complete sequence of data is read avoiding additional CPU cycles. I will test this approach. Would you be willing to test on your adapter once I have the code ready?

[ZeroV0LT]

No problem at all, I'm happy I can help you a little bit in this project. Let me know when you complete the changes. I will trow some Python snake in coming days for the instrument for my purposes so it should also be easy to make some automatic test to make a more complete test for reading and writing.

[Twilight-Logic]

I have added the changes and tested on a 32u4 adapter. Could you try the attached to see if it works on your Nano (I presume from the photo?) adapter. If all is well, I will release as the next version.

AR488.zip

Thanks.

[ZeroV0LT]

It's a MEGA2560, not a nano ... let me know if test version is still valid even if board is not a nano.

[Twilight-Logic]

Ah sorry, yes should have realised that. I registered only your prototype board in the picture at first glance but it is actually quite clear that it is plugged into a Mega! ! The test version is valid for all supported boards including the Mega2560. I applied the update to all board layouts so that it didn't matter which one you had.

[ZeroV0LT]

I will test it during this weekend ... hope to have some script to test reliability of the communication too.

[ZeroV0LT]

Well I think I have similar problem also for writing. In terminal it all seems ok, but I tested only for sending at speed that is equal to my typing speed. When using python snake and sending all the string at one time it does not works. I was checking the code and noticed that you have AR488.tmbus delay there that sets some delay between bytes. It's worth checking this option, I'll let you know if it works.

[Twilight-Logic]

When using a script it is necessary to have some delay between commands to allow the interface to process each command and catch up, otherwise the buffer gets full at which point the serial port blocks and any further data sent gets lost until the buffer clears. I wish there was better handling of the serial port but this would probably require some kind of handshaking within the protocol.

The tmbus parameter adds a small delay between characters being sent to the bus. The larger the number the slower the transmission. The GPIB handshake should handle things so that this should not really by required (GPIB should run at the speed f the slowest instrument) and this was experimental so should not be needed. However, I look forward to your findings.

[ZeroV0LT]

I tested with 1 second delay for each command, and nothing. Tested with tmbus set at 100us and 1000us and still nothing. So I tested by sending one byte at time, with a delay of 100ms between chars (sorta emulating what I do when running by terminal) but it still doesn't works. Neither read or write works.

One can think that I made some stupid thing with serial setup in the python script but I think we can exclude this because "++ver" works as I can read the adapter version string by the python script. Also "++addr 4" works because I can see the instrument going in remote mode. Same with "++verbose" as I can read the diagnostic messages from the adapter once activated verbose mode.

I need to make some more tests ... it makes any sense to me the fact that by terminal emulation works and by python script (even when sending 1 byte at time) doesn't.

[ZeroV0LT]

So I found that after D2 command the instrument need a couple of seconds to "update" current temperature before you can read it. If you make any read request before this two seconds it will become irresponsive for few more seconds and many times it will sorta crash the GPIB interface.

So the fix is to add a sleep(2s) after the D2 command. This problem was not stated on the manual and unfortunately the sleep(1s) that I already was trying after every command was not enough.

So besides I need to make more tests to check reliability, after the first fix with pullup timing everything seems to work correctly.

All the tests up to now where done with my old fix, this weekend I'll try the version you attached with some more in deep test script and let you know the results.

[Twilight-Logic]

Thank you for your ongoing tests. It is interesting to note the behaviour of different instruments. Without a programmed delay between requests, a script could send dozens of requests. The Arduino has a very small serial buffer and limited runtime memory so will very quickly get bogged down by repeated requests while waiting for a reply from the instrument. You could perhaps experiment with the read_tmo_ms parameter. Could you perhaps set read_tmo_ms to 2 seconds (or a bit longer) and then have your script wait until it has received a response before sending the next request?

I am glad that the pullup_timing fix has been helpful and that you have found a solution to the script problem. I have found that instrument response timing often requires a bit of trial and error. I found for example that my Solartron requires a delay of about 200ms between responses in its default mode, but other modes send data quicker so the instrument can be polled faster. I hope your deep test goes OK and would be interested to hear about the results.

[ZeroV0LT]

So was busy in writing a test script for GPIB with this instrument and to run them with my patched version. The instrument is very slow by its own at processing commands, so I really cannot stress the bus that much, but I can confirm it works ok now.

I run also multi-hours real use case test during this week-end (still with my version) to check stability of the link and all is fine.

I think I will have some time to load your version in next couple of days and have it tested too so that the issue can be closed.

[Twilight-Logic]

Ok, thanks for the progress update.

[ZeroV0LT]

The zip is missing AR488_Layouts.h ... I tried to use the original but I think is missing some new definitions. Maybe you want also to create a branch for the test.

[Twilight-Logic]

Sorry about that. I have checked my local copy which looked OK and re-uploaded it. Hopefully should now be OK.

I do create a git branch for testing and then merge everything back in prior to upload, but I did inadvertently use the wrong version number in the commit message and had to correct it. I would not have expected that to impact the content of the ZIP file though.

[ZeroV0LT]

So I run some test on 0.47.60 in master branch and it's working (few hundred reads all OK and a real use case results in no more problems).

[Twilight-Logic]

Glad to hear all was OK. Thank you for the feedback. Enough time has elapsed for further comments so I guess this can now be closed.