Timeouts on NDAC, DAV and debug code out of sync

[PelNet]

Hey there! First of all, nice work on a simple rudimentary GPIB implementation at next to no cost!

Unfortunately, I'm hitting a bit of a snag. First, the main problem; I'm running an (authentic) Arduino Uno and loaded the firmware. As per the ++xdiag command, I've tested all the control lines with a logic analyzer and that's fine. I can also assert the REN line and the target device stops responding to local input as expected.

the firmware version number

Latest from the repository.

the type of board being used

Arduino Uno R3, authentic, no modifications or other peripherals.

the make and model of instrument you are trying to control

Two tested, a Tektronix 2430 (non-A) and an HP 54600A.

a description of the issue including;
what steps are required to reproduce the issue

First issue is that I cannot get a single command to 'go through'. Unfortunately, I have no other adapter for reference, but I'm fairly confident that at least one of the two instruments has a working GPIB interface. Here's what I typically run into when sending a command:

16:13:35.005 -> > ++addr
16:13:37.740 -> 1
16:13:37.740 -> > ++auto
16:13:42.516 -> 1
16:13:42.516 -> > ++mode
16:13:47.491 -> 1
16:13:47.491 -> > CH1 VOLTS: 5
16:13:54.786 -> Received for sending: 43 48 31 20 56 4F 4C 54 53 3A 20 35 
16:13:54.786 -> AR488_GPIBbus.cpp:832 (setControls) > Set GPIB lines for sending a command
16:13:56.011 -> AR488_GPIBbus.cpp:1201 (writeByte) > NDAC LO timeout!
16:13:56.011 -> AR488_GPIBbus.cpp:488 (sendCmd) > Failed to send command 3F to device 1
16:13:56.011 -> AR488_GPIBbus.cpp:857 (setControls) > Set GPIB lines for writing data
16:13:56.011 -> AR488_GPIBbus.cpp:684 (sendData) > write data mode is set.
16:13:56.011 -> AR488_GPIBbus.cpp:685 (sendData) > Begin send loop ->
16:13:57.208 -> AR488_GPIBbus.cpp:1201 (writeByte) > NDAC LO timeout!
16:13:57.240 -> CAR488_GPIBbus.cpp:715 (sendData) > <- End of send loop.
16:13:57.240 -> AR488_GPIBbus.cpp:820 (setControls) > Set GPIB lines to idle state
16:13:57.240 -> AR488_GPIBbus.cpp:753 (sendData) > done.
16:13:57.240 -> AR488_GPIBbus.cpp:832 (setControls) > Set GPIB lines for sending a command
16:13:58.435 -> AR488_GPIBbus.cpp:1201 (writeByte) > NDAC LO timeout!
16:13:58.435 -> AR488_GPIBbus.cpp:488 (sendCmd) > Failed to send command 3F to device 1
16:13:58.468 -> AR488.ino:876 (sendToInstrument) > done.
16:13:58.468 -> > AR488_GPIBbus.cpp:1201 (writeByte) > NDAC LO timeout!
16:13:59.663 -> AR488_GPIBbus.cpp:488 (sendCmd) > Failed to send command 3F to device 1
16:13:59.663 -> AR488_GPIBbus.cpp:523 (receiveData) > Failed to address device to talk: 1
16:13:59.663 -> AR488_GPIBbus.cpp:845 (setControls) > Set GPIB lines for reading data
16:13:59.663 -> AR488_GPIBbus.cpp:539 (receiveData) > Start listen ->
16:13:59.663 -> AR488_GPIBbus.cpp:540 (receiveData) > Before loop flags:
16:13:59.696 -> AR488_GPIBbus.cpp:541 (receiveData) > TRNb: 0
16:13:59.696 -> AR488_GPIBbus.cpp:542 (receiveData) > rEOI: 1
16:14:00.886 -> AR488_GPIBbus.cpp:1101 (readByte) > Handshake error!
16:14:00.886 -> 
16:14:00.886 -> AR488_GPIBbus.cpp:600 (receiveData) > After loop flags:
16:14:00.886 -> AR488_GPIBbus.cpp:602 (receiveData) > TMO: 
16:14:00.917 -> AR488_GPIBbus.cpp:603 (receiveData) > Bytes read:  0
16:14:00.917 -> AR488_GPIBbus.cpp:604 (receiveData) > <- End listen.
16:14:00.917 -> AR488_GPIBbus.cpp:619 (receiveData) > Timeout waiting for sender!
16:14:00.917 -> AR488_GPIBbus.cpp:620 (receiveData) > Timeout waiting for transfer to complete!
16:14:00.917 -> AR488_GPIBbus.cpp:832 (setControls) > Set GPIB lines for sending a command
16:14:02.112 -> AR488_GPIBbus.cpp:1201 (writeByte) > NDAC LO timeout!
16:14:02.144 -> AR488_GPIBbus.cpp:488 (sendCmd) > Failed to send command 3F to device 1
16:14:02.144 -> AR488_GPIBbus.cpp:630 (receiveData) > Failed to untalk bus
16:14:02.144 -> AR488_GPIBbus.cpp:820 (setControls) > Set GPIB lines to idle state
16:14:02.144 -> AR488_GPIBbus.cpp:646 (receiveData) > done.
16:14:02.144 -> Error while receiving data.

As you can see, I've enabled some debug options in the config. A little note on these, some are broken in their current state in the repo. See this for example (there are a few scattered through the files). I'll make a fork and PR soon:

-    DB_PRINT(F("Handshake error!"));
+    DB_PRINT(F("Handshake error!"), "");
   }

Anyhow, a few of those minor fixes got most of the debug working. I'm using the Tektronix as my main target as it provides more feedback (LED's above the screen for LOCK, SRQ and ADDR) and has configuration options the HP does not offer (like the format of responses, EOI with and without LF and so on. The HP basically allows you to set the bus address and choose between Printer, Plotter and Computer as the 'other device'. Printer and Plotter would be Listeners, so obviously I'm using Computer, but the response is the same.

If I manually modify the code or draw the NDAC pin low, it will fail at the next step, so the communication simply isn't working at all. Apart from the REN line disabling local input, I can't get anything to work. I've double and triple checked the pinout, hardware and so on. As mentioned, ++xdiag pulls the pins up and down as intended and I can witness this when connecting to the scope(s). I would like to add that I'm fairly tech savvy, also including low level TTL communication and so on but have no practical experience with GPIB. Any clues or suggestions? :-)

[PelNet]

Another question - less important - is why the addressing runs from 1-30, whereas GPIB supports address 0? I wondered whether this might be an offset issue but I tried 'shifting' and it made no difference.

Also, when I run an ++xdiag 1 8 to assert DAV, the bus is drawn high and then released. This confuses me, as it should be inverted, low for assert, high for deassert, correct?

[Twilight-Logic]

Thanks for reporting the issues you are having.

With regards to the addressing, it follows the Prologix which ran from 0 to 30, although 0-31 could actually be used. Address 0 is reserved for the controller and cannot be used to talk to a device. Again, the controller could use any primary address. I had thought about implementing a feature to change the controller address, in which case address 0 could be used, but never got around to it.

I can only apologise for the debug statement errors and will get them fixed.

Can I ask whether the interface was disconnected from the bus when you ran the ++xdiag command?

Just to rule out a physical connection issue, can I also ask whatever your connection method between UNO R3 and instrument, whether ground is connected at each end of the cable?

I note that the 2340 uses EOI and LF as a termination character so a CRLF may confuse it. You may need to set:

++eoi 1
++eos 2

A quick review of the HP54600A documentation indicates that it needs to be set in addressable mode via a switch at the back and then reset (first toggle set in the down position then reset pressed or the instrument power cycled). Both carriage return and linefeed are considered terminators, so it shouldn't have a problem communicating with the default CRLF terminator.
In talk mode the instrument will only send you data and the interface would need to be set to listen only mode with:
++lon 1
in order to receive it. Addressing would then be ignored.

[PelNet]

Hey, thanks for getting back to me here! No worries about the addressing, I'll be dealing with about three instruments tops, and likely never sharing the bus between them, so for my use cases that's fine. I was just a little confused due to not being very familiar with the protocol in the practical sense. Meanwhile I've delved further in the whitepapers and protocol spec. RTFM for the win, hehe.

I can only apologise for the debug statement errors and will get them fixed.

No worries, I'll let you have a crack at that, as I'm not entirely sure what happened with the handshake debugging - some states seem to have been replaced. Perhaps it would be a good time to mention that I managed to get the Tektronix working and the bus behavior consistent!

Can I ask whether the interface was disconnected from the bus when you ran the ++xdiag command?

No, this was with the Tektronix scope connected as I was attempting to analyze the handshake and determine the cause of the fault. After upgrading the IDE and switching out the board, operations seem to work correctly. I incidentally checked the original board and using simple "blink" style sketches it operated fine. I circled back to the board and was unable to reproduce the problem, so I can only assume that the IDE or bundled avrdude compiler somehow interfered there. Left me a bit confused, but OK. I should have mentioned the version of the IDE I was using, which was just north of 2.0.

Just to rule out a physical connection issue, can I also ask whatever your connection method between UNO R3 and instrument, whether ground is connected at each end of the cable?

Yup, all grounds including pin #12 for the shield were tied to a single common ground. This works just fine now. 😄

I note that the 2340 uses EOI and LF as a termination character so a CRLF may confuse it. You may need to set:

According to the documentation it will ALWAYS honor the EOI, and will optionally (if configured to do so) honor an LF.

Thanks for those pointers on the HP! I'm literally in the process of trying to get that to work. Currently I'm a little stuck on a 'Query unterminated' error which pops up on screen so I think the EOS and EOI may need a little tweaking. I think I'll get it sorted fairly quickly, now that I know the controller is operating correctly and I can make some (semi) educated guesses.

Thanks again!

I guess you can add these two devices to the 'known compatible' list and close the issue if desired. If you like, I can also drop a line here when I've confirmed the HP is working correctly.

[PelNet]

Update: Yup, I've got the HP working. This is using an HP 54650A HP-IB interface module, no DIP switches or any other configuration on the module or rear panel. Setup is done from the scope itself where you can select a bus address, whether to transmit factors, the resolution and whether the remote end is a Computer, Plotter or Printer. I'm guessing the Plotter option outputs HPGL, the Printer option does raw PCL.

I also have an HP 54645D with the RS-232/Parallel interface for which I've written a nifty little Python CLI and GUI app which receives the PCL data and converts it to a PDF or PNG, saves a copy, automatically previews it on screen, etc.

The main reason I've been looking to get GPIB working on the Tek and this 54600 is because I would like to be able to save captures from them, too.

TL;DR: All sorted, working. Thanks a bunch!

[Twilight-Logic]

I am glad you got it sorted and working!

That's an interesting note about early versions of IDE2.0.x. I was aware that there were some issues such as with the serial console and the odd IDE glitch, but none that I am aware of affecting the compilation of code. Yet since you were able to cycle back to the original board after upgrading the IDE and recompiling the code, that would seem to suggest possible problems with the early releases.

One of the problems with adding debug messages is that they take time to print to serial which can affect the timing of the handshake process. I have made an effort to place debug messages outside of reading and writing loops, but there may be more work to do to improve the process.

I must admit I hadn't though about maintaining a list of compatible devices. Maybe I should!

[PelNet]

Yup, that was a bit of a pain as I didn't have a working system for reference, hehe. The ironic part being that I could analyze the handshake and digital I/O using the 54645D and even snag that data to the computer using a nullmodem cable and my little tool. I'm on Linux, FWIW, using the Arduino IDE(s) from their site, not a distribution packaged version or anything like that. System in use here was an Intel running Ubuntu 22 LTS.

It would be nice to see the debug working as it is actually very handy.

The HP didn't actually require any special configuration but actually displays semi-helpful messages on screen when GPIB communication failures occur. "Unterminated query" or "Header missing", that sort of stuff. I'm not an expert on these matters as you've noticed, but from what I'm seeing I think an 'incompatibility list' might make more sense. After also having read the extensive thread on the EEVblog, I think this controller should be capable of most 1:1 instrument interaction as far as the basic command sets are concerned. Are there things that you think might be problematic on the scopes I've got? If so, I'll gladly put it through its' paces and see what I come up with.

I think I may extend that tool to be able to flip the controller into device mode and then receive and process the data from a 'screenshot' or 'print job' as it does when simply using a serial interface.

[PelNet]

Right, I've implemented the 'startup command sequence' in my utility and referred back to this tool in the README.

https://github.com/PelNet/scope-dump

Unless you wish to keep this issue open for addressing the debug functionality, I'm fine with it being closed.

Thanks again!

[Twilight-Logic]

Thank you for the feedback. Nice tool for capturing the PCL dump. I don't have any of the instrument supported so can't provide any further feedback on it unfortunately.

No problem with referring back to the AR488 project. Apart for timing issues that needed to be resolved in the early days of this project, I have not had to date reported any specific compatibility issues that were not resolved through tweaking the settings to use the appropriate parameters, which is usually a matter of discovery. The one exception is an instrument, for which there is an open issue, that requires secondary addressing, which as yet, is not fully supported.

I will keep this open for now as a reminder to self to review the debug messages.