How can I hold off a GPIB Master without it timing out?! - Page 1
Forum section: electronics / testgear

author: blipton
author_rank: Newbie
timestamp: August 24, 2017, 02:32:46 pm
content: I am acting as a GPIB slave, and some commands take a long time for me to process...I can't change the protocol, so I'm looking for a way to use the GPIB hardware handshake lines, to delay the Master so that it doesn't move on until I'm done, but at the same time not timeout.According to the datasheet for the GPIB chip (NI NAT9914 / TI TMS9914A ) there is a signal called 'Not Ready for Data', but how can I hold off the bus once I received the data and need extra time until I'm done?

author: merox
author_rank: Regular Contributor
timestamp: August 24, 2017, 06:12:14 pm
content: What's the master/the device talking to you? Are you trying to emulate obsolete gear?

author: blipton
author_rank: Newbie
timestamp: August 24, 2017, 09:01:56 pm
content: Yes I'm trying to emulate an Agilent 6032A (power supply).. the master could be anything but I'm testing using an NI's gpib-usb-hs and a simple program I hacked together using pyvisa/lantz/instrumentkit.I don't have an original 6032A to test with, but if the master tells the power supply to turn on, and then quickly goes to the next gpib device to measure the power supply's voltage, it could potentially measure incorrectly since the ps isn't fully up yet.What mechanism does a slave device have to tell the master to wait before proceeding?

author: macboy
author_rank: Super Contributor
timestamp: August 25, 2017, 03:05:21 pm
content: If you become addressed to listen, and you are not ready for data, then assert NRFD "Not Ready For Data". That's what it is for!Never handshake (assert NFRD or NDAC) when not addressed as a listener. Note there may be any number of listeners addressed by the controller at a time, and any or all may assert NRFD whenever they are not ready. Only when all listeners unassert this open-collector signal will it float high (=false due to negative logic). Listeners only stop listening when "unlisten all" (a.k.a. listen address 31) is sent on the bus.In addition, when a device is addressed to talk, there is no fundamental requirement that it must talk immediately. It can do so whenever it wants to, while addressed to talk. So if you send a command that is expected to be followed by a response (e.g. "IDN?"), the device can take however long it needs to. This is important for things like getting a measurement... if the measurement isn't ready yet, then there could be a "long" wait. I try to avoid blocking the bus, so I set up instruments to SRQ when a measurement is ready, then I poll to find out which instrument is asking for attention and why, then ask it to talk, get the measurement, and untalk immdiately. This way all instruments respond in a timely manner and I can keep the bus idle and ready. I can have a half dozen multimeters on the bus, each sending many measurements per second to the controller, and never miss a measurment, and have plenty of bus bandwidth left over. If you write you code in a simple inline blocking manner, that will not be possible.It is always possible for the controller to time out waiting for a device to respond, but this timeout duration is a function of the controller, not the device. The timeout should be a configurable parameter in the GPIB low-level software layer/driver. (e.g. in Agilent I/O Libraries for Windows.).