Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Notify event not firing after first time

I just had my app which has an HP VXI switch and an HP 3458 DMM stop working when I had my platform exchanged from a P3-800MHz to a 2.5GHz P4 on a new Intel D865PERL Mother board. I use a timer to as a state machine to initialize the VXI/dmm combo to measuere TC voltages then 4-wire ohms. Timer sleeps when the scan is initiated. When VXI completes the scan, it does a service request, the GPIB notify event captures it and starts up the timer state machine to read data, and start the next scan. This worked well on the old platform, now I complete the 1st scan, read the data from the dmm, start the 2nd scan, it completes but GPIB notify does not fire. Using NI SPY I notice that Start in notify/stop ib notify is only cap
tured on the first ibnotify call. I'm stumped. Tried a delay between issuing the .notify and starting a scan, no difference. Any help appreciated. Attached is code and NI Spy capture. Open the last 1000 lines of the spy file and then look from lines 955-996.

David
Download All
0 Kudos
Message 1 of 5
(3,995 Views)
Hello David,

I see that you're calling ibnotify() successively in your program. Are you arming, disarming, and re-arming your callback function, or are some of those ibnotify calls superfluous? Do you expect that just after the ibnotify call in line 995 that the callback function will be invoked? (That is, the device linked with UD0 has its RQS bit set?)

I also noticed a number of ibrsp() calls. From the 488.2 driver online help for ibnotify: "For device-level usage, notification on RQS is not guaranteed to work if automatic serial polling is disabled. By default, automatic serial polling is enabled." So I wanted to make sure that you did have auto-serial polling enabled.

Are you sure that your device is actually asserting its RQS bit? Also, what dr
iver version are you using and what OS?

Scott B.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 5
(3,995 Views)
Scott,

Like I said, this worked on Win2k SP4 P2-850 (not p3) machine.

1)I had driver 1.7, then when I had problems, switched to 2.1. Using Win 2K SP4.

2) according to NI doc for OnGPIBNotify Event, "Once this event generates, you must re-arm the event using the Notify method." which is why there is more than one invocation of ibnotify.

3) I can not find a property or documentation about automatic serial polling. I certainly am not turning it off to my knowlege.

Starting at 970, that is the 1st ibnotify. 973 starts the VXI-DMM Scan. 974 is my spoll in the OnGPIBNotify event callback.. 975-980 is waiting for DMM data available. 981-994 reads dmm data, sets dmm to 4wire, sets VXI for next scan, and waits for DMM ready bit. 995 re-arms the notify event, 996 starts the scan. At both 973 and 996, my timer sleeps(disabled, waiting to be woken(enabled) from the OnGPIB Notify call back. Obviously at 974 I have been woken, but after 996 I am not.

Like I said this worked before MB/PROC change, with same Win2k sp4 os and 1.7 driver.

On further analysis, I decided to try polling rather than being event driven. So I took out the calls to ibnotify and put in some polling on the VXI for Scan complete. Now went the ibwrite call to start the scan happens I get an EADR (3) error on the write, or in VB error 30333, "GPIB board is not properly addressing itself". If I go to VB debug mode and hit RUN, it then works just fine (see attached NI spy file). Tried putting in pauses up to 1 second before the ibwrite and it still fails. Tried putting in a debug breakpoint at the ibwrite, then resume running, it still fails. But it always works the second time after failing. See attached file.

Tried turning off Hyper-threading. No difference
Tried moving the card to another PCI slot where it had its own interrupt vector. No difference.

This is our first GPIB experience with this MB, I think the problem may be with it.

Attached is the NI-spy file for the Polling method error.
0 Kudos
Message 3 of 5
(3,995 Views)
Scott,

So I found the Unaddressing property of the GPIB ActiveX and decided to give it a shot and set it to true. I knew in the old, old, days we always did an UNT/UNL after writing or reading.

It has cured both problems! My question now for NI is why on this platform does this make a difference? I never have had to use this before with NI drivers on a PC.

Thanks for any feed back on this.

David
0 Kudos
Message 4 of 5
(3,995 Views)
I reproduced this and will look into it. Thanks for the further clarification and the spy capture.
0 Kudos
Message 5 of 5
(3,995 Views)