Connecting to NI MAX

[YYYYYJS]

Hi, may I ask—if I use NI's GPIB-USB-HS to connect to the AR488, will NI MAX be able to recognize it successfully?

[Twilight-Logic]

I don't have a definite answer for this as I have not been able to test it with a GPIB-USB-HS adapter. The AR488 doesn't yet recognise NI's high speed protocol released in the updated standard 488.1 but the NI adapter should be able to drop back to standard GPIB and be able to interoperate. I would be interested in knowing the answer to this myself.

[YYYYYJS]

Thank you, I'm trying it now. I'll let you know if I get any results.

I don't have a definite answer for this as I have not been able to test it with a GPIB-USB-HS adapter. The AR488 doesn't yet recognise NI's high speed protocol released in the updated standard 488.1 but the NI adapter should be able to drop back to standard GPIB and be able to interoperate. I would be interested in knowing the answer to this myself.

[TekCastPork]

I'm trying the same thing, but also with HS+ adapters, and I've been finding that with a configuration which should set the ar488 as a device with PAD 1 and NO_SAD (changing cmode to 1, ontop of MACRO_0 executing a ++mode 0 just in case) NI-MAX reports finding too many listeners on the bus when i scan for instruments, despite the only thing being connected is my ar488.

I can see my ar488 receiving data from the bus when it scans via the debug console. This is on an atmega328pb on a custom board, but it does use the pinout config of the standard UNO layout, utilizing SN7516x buffers.

Code version is .53.03, though ive also not had luck with newer pre-releases or master branch.

Make/model of instrument is not applicable in this case, as the intent is for the ar488 to be the "instrument".

[YYYYYJS]

Thank you for your detailed email describing the issue you encountered. It was very helpful to read about your specific setup and troubleshooting steps. I'm quite interested in the "device overload" problem you faced with NI-MAX during the instrument scan. I was wondering if you have had any success in resolving it since your last message? I would be very grateful to hear about any new findings or potential solutions you might have discovered. Please let me know if there is any additional information from my end that could help in diagnosing the problem. Best regards, Jiasheng Yin ---- Replied Message ---- From ***@***.***> Date 09/26/2025 23:28 To ***@***.***> Cc ***@***.***>***@***.***> Subject Re: [Twilight-Logic/AR488] Connecting to NI MAX (Issue #51) TekCastPork left a comment (Twilight-Logic/AR488#51) I'm trying the same thing, but also with HS+ adapters, and I've been finding that with a configuration which should set the ar488 as a device with PAD 1 AND NO_SAD (changing cmode to 1, ontop of MACRO_0 executing a ++mode 0 just in case) NI-MAX reports finding too many devices on the bus when i scan for instruments, despite the only thing being connected is my ar488. I can see my ar488 receiving data from the bus when it scans via the debug console. This is on an atmega328pb on a custom board, but it does use the pinout config of the standard UNO layout, utilizing SN7516x buffers. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[TekCastPork]

I havent yet, its also for a work thing I cant really go too deep into what i need it for and also wont be able to touch it again until after the weekend.

From what i can gather though it looks like it may be pulling NDAC low each time my hs+ pulls ATN low.

This makes sense for the 488.2 find listeners function behavior, but it seems to be doing it for every listener address test, which likely explains why it was found 31 times (which is too many, out of 32 possible primary addresses addr 0 is the controller and 31 is a special address invalid for instruments, so it can only use between addr 1 and addr 30).

Im going to sniff the data lines more in depth when I work on it again to hopefully confirm this theory.

[YYYYYJS]

Thank you for the update and sharing your detailed analysis. Your reasoning about the NDAC/ATN interaction and address range makes a lot of sense and is very helpful. I'll also be sure to share any findings from my end as I continue my own testing. Looking forward to your further findings next week. Enjoy your weekend. ---- Replied Message ---- From ***@***.***> Date 09/27/2025 11:19 To ***@***.***> Cc ***@***.***>***@***.***> Subject Re: [Twilight-Logic/AR488] Connecting to NI MAX (Issue #51) TekCastPork left a comment (Twilight-Logic/AR488#51) I havent yet, its also for a work thing I cant really go too deep into what i need it for and also wont be able to touch it again until after the weekend. From what i can gather though it looks like it may be pulling NDAC low each time my hs+ pulls ATN low. This makes sense for the 488.2 find listeners function behavior, but it seems to be doing it for every listener address test, which likely explains why it was found 31 times (which is too many, out of 32 possible primary addresses addr 0 is the controller and 31 is a special address invalid for instruments, so it can only use between addr 1 and addr 30). Im going to sniff the data lines more in depth when I work on it again to hopefully confirm this theory. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[TekCastPork]

So I've made some progress:

I nailed down the issue mine was having with "too many devices" when NI-Max does a find listeners: my 75160 buffer IC had damaged buffers on bits 4 and 6, so instead of receiving 0x3F 0x5F 0x20 (UNLISTEN, UNTALK, ADDRESS 0 LISTEN) as the find listeners command starts it was receiving 0x2F 0x0F 0x20. So that was part of my problem. Replacing my 160 buffer IC looks to have fixed that.

I also disabled the internal pullup resistors of the atmega328 as the buffer ICs handle that for me, and through this I've learnt that GPIB seems to be a 3.3V bus, at least with usb HS/HS+ adapters, so having a 5V pullup on that could cause problems. Whether this is a factor I do not know but im inclined to keep them disabled.

Now that that's solved though NI max reports finding nothing, so there is still some quirks or issues in the way.

[TekCastPork]

Additional testing and debugging and I think what is happening is AR488 is reading in the entirety of the bytes sent by the 488.2 standard's find listeners command (which is what NI-MAX, and most GPIB software that presents a drop-down of available devices I've encountered for that matter) uses to locate available instruments, so by the time it realizes its been addressed to listen (as part of that command) the window in which it should've "responded" is well past.

I also dont think it responds to the ibln command correctly either (this command just tests 1 address instead of all addresses), as I can set the AR488 adapter to address PAD1 NO_SAD and have my software execute a ibln for address PAD2 NO_SAD and I can see AR488 read the bytes via its debug system and ibln returns true (that it found a listener), despite AR488 being the only item on the bus and not being assigned the address tested by ibln.

Unfortunately the AR488 internal code is too unknown to me at this time to suggest some kind of fix to make it more compatible with software using these commands.