SRQ Not Asserting Properly

[Matt C.]

Hey everyone,

I'm writing a controller for the Agilent 4395A Impedance Analyzer. Basically, the analyzer performs frequency sweeps and records data while tracking a resonance peak. A key part is the SRQ, which prevents any measurement or peak tracking from occuring until a sweep is finished.

My problem is that I cannot get this SRQ to work properly. What happens is that after a sweep occurs, an SRQ should be asserted via the event status Register B and the service request enable register. The specific GPIB string I used was *SRE 4; ESNB 1 to enable those specific registers, and I am relatively certain that they are correct (based on the 4395 Programming Manual). However, no SRQ is ever asserted and the program just sits at the WaitSRQ VI until a timeout occurs. 

My thinking is that the problem lies somewhere in an incorrect GPIB string or that somehow I've wired the SRQ VI incorrectly into my program. If anyone could help me diagnose the issue I would really appreciate it. I've attached the controller program (or alternatively, a screenshot of the SRQ portion) as well as the 4395A Programming Manual.

Thank you in advance,

Matt

[Justin_E]

Hey Matt,

Have you tried taking a look at the 4395A instrument driver on our Instrument Driver Network? That driver can be found here : http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=2056

This driver is unfortunately not NI Certified, but it might be worthwhile to take a look at to see if it works with your device, and if you can pull anything from that into your program. If not, hopefully there is someone else who has experience with programming this controller. Do you receive any errors or warning messages when running your program? Usually if a command sent to the device is formatted improperly, you'll either get an error returned from your device or a timeout will occur.

[JÞB]

Matt,

I've run into this myself.  Wait for SRQ operates by serial poll.  So it asks each device on the bus starting at the lowest address if it is holding SRQ.  When it finds SRQ asserted it compares that address to the one in Wait for SRQ.  If they don't match it starts again at address 0.

So Assume you are waiting for SRQ at Address 29.  Another device at Address 5 has a service request.  Wait for SRQ @29 times out unless the Request for service @5 is first cleared.

Usually you can disable SRQ on every other device on the bus.

Now, this is NOT a BUG!  it is a specific design intent of the GBIP standard.  Ideally you would place your most important equipment on the lowest addresses (hence the controller defaults to 0) and use serial poll to aid in Service Request Arbitration.  (So that the most important requests mask less important requests)  

[Matt C.]

Jeff, I was actually looking into the addresses to see if that might have been a problem, but in this case it actually was not. While looking further into the program I think I found the problem.Turns out that first off, the BUS Trigger sets a different register than an internal trigger when a sweep occurs (which explains the hanging loop part since the device was never checking the right register) and secondly there is a small set up time with the 4395A SRQ so that a small delay is required between the sweep command and the SRQ, otherwise the SRQ is bypassed completely by the program. With these corrections, the program appears to be functioning correctly.

Thanks for your help guys, I really appreciate it!