Regarding the timing bug in the file <AR488_GPIBbus.cpp>

[EveryIsZero]

`

/* Before modification */
//assertSignal(DAV_BIT | EOI_BIT);

/* After modification */
assertSignal(EOI_BIT);
assertSignal(DAV_BIT);

`

By directly passing in the pins to be operated through OR logic, it is impossible to predict whether the pins will be controlled according to the required timing sequence. This bug may cause DAV to be pulled high first when the output state of EOI is unknown, causing other devices to receive incorrect EOI signals. It is recommended that all control signals should not use this kind of OR logic simplification for control.

AR488_GPIB.cpp, ver. 0.53.11, 08/05/2025
Known problematic line number: 1228
Potentially risky line numbers: 129, 151, 156, 408, 1257

In addition,
suggestion 1: Please create a compressed package for each version you upload. The versions in "Archive" are very old, and the content in "src" is always changing.
suggestion 2: I also need to support the device mode that can connect to the software NI MAX. Currently, in most test cases, the device address cannot be scanned, but it can be found with a small probability. Once found, normal communication can be achieved.

Thank you for sharing the code. It's very useful.

[Twilight-Logic]

By directly passing in the pins to be operated through OR logic, it is impossible to predict whether the pins will be controlled according to the required timing sequence. This bug may cause DAV to be pulled high first when the output state of EOI is unknown, causing other devices to receive incorrect EOI signals. It is recommended that all control signals should not use this kind of OR logic simplification for control.

This is actually passing the pin numbers to be switched to a routine that does the actual switching logic via direct register manipulation, in which case the pins will switch simultaneously. However, for the custom board profile, what you say remains true so I will review the code including the line numbers indicated. Thank you for pointing that out.

suggestion 1: Please create a compressed package for each version you upload. The versions in "Archive" are very old, and the content in "src" is always changing.

I did previously do that but I didn't think anyone was actually using them so I stopped doing that. However, now that you have suggested it, I will look at automating the process somehow.

suggestion 2: I also need to support the device mode that can connect to the software NI MAX. Currently, in most test cases, the device address cannot be scanned, but it can be found with a small probability. Once found, normal communication can be achieved.

The question is what is the NI MAX looking for when it scans? The USB Vendor ID and PID cannot be changed. The only other item is the version ID string. If its looking for a GPIB address, then it ought to be able to find it. I don't have a purchased licensed copy of NI MAX to test with unfortunately. There may be something in the NI MAX documentation so I will see if I can find it..