Gpib troubleshooting - Page 1
Forum section: electronics / beginners

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 02, 2020, 09:47:45 pm
content: Looking for assistance with arduino to gpib adapter unable to communicate with instruments. Tested basic commands through terminal commands and not much other than ++ver works. Error seems to be the same using arduino nano and pro micro 32u4.Verbose: ON> ++verAR488 GPIB controller, ver. 0.48.28, 01/07/2020> *idn?gpibWriteByte: timeout waiting for receiver attention [NDAC asserted]gpibSendCmd: failed to send command 3F to devicegpibSendData: failed to address device 1 to listen++addrgpibWriteByte: timeout waiting for receiver attention [NDAC asserted]gpibSendCmd: failed to send command 3F to devicegpibSendData: failed to address device 1 to listen

author: m k
author_rank: Super Contributor
timestamp: December 04, 2020, 09:52:18 am
content: Mamual says that at the beginning the device is a controller at address 0.Also that saved configuration is used if found.Also that unpowered Arduino controllers should be disconnected.Is the bus properly terminated and stuff?Can you communicate between those two MCUs?

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 05, 2020, 12:04:40 pm
content: Both mcu's will reply to ++ver and ++addr commands. Other than that im getting error message above, I tried manually setting gpib address as well as auto search same result. I have tried burning uno bootloader to nano as well no change.

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 05, 2020, 03:04:50 pm
content: Also im observing the display of the multimeter according to manual there should be announciator on the screen that displays tlk or lsn talk/listen when sending or recieving commands. Im getting neither. Is there a possible minimal wiring route to mcu just to test that instrument is sending and recieving data?

author: m k
author_rank: Super Contributor
timestamp: December 06, 2020, 05:50:12 pm
content: What exactly you are sending?Something like++addr [your device]*IDN?++readKeep in mind that I may know nothing about your specific devices, but until you get something relevant through your connection that is not a big issue.Google wasn't a friend but at least something.Both links have timing pictures, actual timing is not relevant here, change of a level anytime is enough.http://www.interfacebus.com/Design_Connector_GPIB.htmlhttp://www.hit.bme.hu/~papay/edu/GPIB/tutor.htmIf nothing had come through, ever, you should consider that your system is faulty.What I would do, after checking all wirings once more, is creating a dummy device.Your second MCU can be that.Configure it being a device and give it a custom ID-string.Then ask that id using the other MCU.

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 06, 2020, 10:08:28 pm
content: After reading the links you suggested I had a play with tms "bus" timings thinking that was the issue as was also suggested by another forum member. Still no progress in talking to instruments even attaching my o-scope to connector DAV pin 6 line to arduino nano pin D11 I am seeing the line pulled low when giving the ++read command and I get this.> ++addr1> ++addr 23Set device primary address to: 23> ++readgpibWriteByte: timeout waiting for data to be accepted - [NRFD asserted]gpibSendCmd: failed to send command 3F to deviceFailed to address the device23 to talkgpibReadByte: timeout waiting for DAV to go LOWBytes read: 0Timeout waiting for sender!gpibWriteByte: timeout waiting for receiver attention [NDAC asserted]gpibSendCmd: failed to send command 3F to devicegpibSendData: Failed to untalk busAny ideas on what I could be doing wrong to address device23 to talk which I assume is my instrument address 23.

author: m k
author_rank: Super Contributor
timestamp: December 07, 2020, 11:01:23 am
content: First timeout means that Multiline Message Unlisten(UNL) was tried but NRFD stayed down.Since NRFD is controller input it shouldn't be low if connector is disconnected.The operation goes so that first all devices release their NRFDs.Databus is then clear and free.Then DAV goes down and so data is in the bus.Then NDAC goes up and so data is accepted and bus can continue.Since DAV is operational it seems that connector rows are not mixed.Check ATN and IFC also.You can try following stuff but first you need to get those signals co-operating.++mode 0++auto 2++addr 23*IDN?++mode 1++auto 1++addr 23*IDN?

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 07, 2020, 11:55:04 pm
content: With settings at ++mode 0, ++auto 2, ++addr 23, and typing *IDN?I get on nano boardD11 6 DAV 2.8 volt idle, 4.2 volt command sentD7 11 ATN 2.8 volt idle, 2.8 volt command sentD8 9 IFC 2.8 volt idle, 2.8 volt command sentwith error- *IDN?gpibWriteByte: timeout waiting for receiver attention [NDAC asserted]With settings at ++mode 0, ++auto 2, ++addr 23, and typing *IDN?I get on nano boardD11 6 DAV 4.2 volt idle, 2.6-4.6 volt command sentD7 11 ATN 4.2 volt idle, 0-4.6 volt command sentD8 9 IFC 4.2 volt idle, 2.6-4.6 volt command sentwith error- > gpibWriteByte: timeout waiting for receiver attention [NDAC asserted]gpibSendCmd: failed to send command 3F to deviceFailed to address the device23 to talkgpibReadByte: timeout waiting for DAV to go LOWBytes read: 0Timeout waiting for sender!gpibWriteByte: timeout waiting for receiver attention [NDAC asserted]gpibSendCmd: failed to send command 3F to devicegpibSendData: Failed to untalk busIn ++mode 1 ++auto 1 DAV isn't being pulled low enough it appears only getting down to 2.6volt instead of 0. Could this be the problem?

author: m k
author_rank: Super Contributor
timestamp: December 08, 2020, 01:48:30 pm
content: Yes, DAV must go down, it's the data Strobe, nothing is happening without it.(NRFD is Busy and NDAC is Ack)Definition for low is half a volt.You can also try stuff without the DMM.Response is what it was in your opening post but DAV should pulse.Earlier NRFD has dissapeared, seems that line is not stuck.Try++auto 3++mode 1 ; scope IFC++mode 0 ; it should pulse++ifc ; this should also pulse it++addr 23 ; scope ATN, NRFD, DAV and NDAC++addr 23 ; all should pulseFirst AR488 puts ATN low for controller message, possibly sending UNL like earlier, if so those handshaking signals should pulse then also.Then it should send an address message and handshaking signals should pulse.If all are pulsing then try++clr*IDN?Now some ID stuff should finally appear.

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 08, 2020, 04:18:29 pm
content: ++auto 3++mode 1 ; scope IFC++mode 0 ; it should pulse++ifc ; this should also pulse itD8 / 9 / IFC ++mode 1 to ++mode 0 no state changeD7 / 11 / ATN ++mode 1 to ++mode 0 changes it from 4.6v to 4.2vD10/ 7 / NRFD ++mode 1 to ++mode 0 no state changeD11 / 6 / DAV ++mode 1 to ++mode 0 changes it from 4.6v to 4.2vD9 / 8 / NDAC ++mode 1 to ++mode 0 no state change++ifc not available in ++mode 0 but in ++mode 1 the above 4 pins no pulse on any sending ++ifc.This rabbit hole is getting deep enough to warrant just buying a prologix adapter.Read through the AR488 manual again and found this.The ++xdiag command can be used to test that individual lines are being asserted / unasserted.The command takes two parameters: mode and value. To manipulate control lines use mode 1,and for data lines use mode 0. To assert a line/data bit, simply speciy one of the values in the tablebelow. To assert multiple lines/bits simultaneously, simply add the values. To un-assert a line,subtract its value from 255 The following two tables list the GPIB signals and the command used toassert them.Command signals:Assert IFC ++xdiag 1 1Assert NDAC ++xdiag 1 2Assert NRFD ++xdiag 1 4Assert DAV ++xdiag 1 8Assert EOI ++xdiag 1 16Assert REN ++xdiag 1 32Assert SRQ ++xdiag 1 64Assert ATN ++xdiag 1 128Assert ALL ++xdiag 1 255Un-assert ALL ++xdiag 1 0I tested all pins and each are pulled low when commanded to... Now im thinking its arduino code error or possibly arduino IDE version possibly.

author: m k
author_rank: Super Contributor
timestamp: December 09, 2020, 09:26:31 am
content: My version of the manual has no xdiag.Since xdiag does what it should the system is generally quite a bit operational.If you get NDAC error then something is not right at low level.It can also mean that device address is wrong and nobody is fetching.You can also try known wrong address and compare results.My understanding is that you should never get that earlier "failed to send command 3F to device" message.Is your DMM IEEE-488.2 compliant?Maybe it's too much HP and you should send something completely different.Old HP manual says that by default 3478A listens port 21 and talks to port 23, AR488 manual is not clear what it's address is, my guess is that it's always zero.HP continues that 3478A can be set to talk-only mode by dipping address switches to one, also that all lower case characters are ignored, like are many others, spaces also.Talk port 23 (MTA23) is letter W, same manual says that W can uncalibrate the machine.Try++auto 3++mode 0++addr 21D2HELLO 3478ABYour DMM can also be quite slow.Maybe you must wait more... and more.

author: Tj138waterboy
author_rank: Regular Contributor
timestamp: December 10, 2020, 05:40:20 pm
content: In ++mode 1 ++auto 1 DAV isn't being pulled low enough it appears only getting down to 2.6volt instead of 0. Could this be the problem?Answered the problem without knowing. Bad ground connection so it couldn't pull low. Have arduino nano working now. Thanks for the help