Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

SRQ stuck on after 7th assert.

Solved!
Go to solution

I have recently discovered an issue with GPIB communication regarding asserting the SRQ line and was wondering if anyone had any suggestions as to what I could possibly do about it.

 Background:

I am running a piece of application software, developed in LabVIEW, which communicates via GPIB to another PC-based tester system, owned by our customer. This tester system requires the SRQ line to be asserted by the application software and pass a data byte to the tester that is polling the GPIB. During normal operation, the SRQ line may be asserted several times in a test profile. In order to test GPIB communication, I am simulating the customer’s tester system using a PC equipped with a GPIB card running NIMax software. I am using the “Communicate with Instrument” interface to send commands and receive messages from my application PC. I have also ensured that autopolling is enabled in GPIB properties. Additionally, in order to monitor the SRQ line I have connected in-line an additional PC equipped with a GPIB+ card running GPIB Analyzer software. I have configured GPIB analyzer to monitor all data transfers, command transfers and control line transitions between the application PC and the tester simulator PC.

 Problem:

The first six times that my application software asserts the SRQ line, everything works as expected. The SRQ is asserted, tester simulator PC detects the assert, unasserts the SRQ line and the data byte is passed. On the 7th time however, the SRQ line is asserted, but the tester simulator PC does not appear to detect it, thus never unasserting the SRQ and the data byte is never passed. Therefore producing an “SRQ stuck-on” condition. (See attached JPEG of capture file.) The only way to clear this condition seems to be to exit and re-start my application software. This issue is repeatable and always occurs on the 7th assertion of the SRQ line.

 Observation:

I discovered that the anomaly described above only appears to occur when I am communicating with my application software using a NI488.2 driver that is ver. 2.0 release or above. When I run using a system with driver version 1.7 or earlier, everything runs as expected, meaning the “SRQ stuck-on” condition never occurs. I have tested for this anomaly on various Windows operating systems, from NT4 to XP. I have also used different versions of NIMax as well. But in my current opinion, the problem appears to reside with the NI488.2 driver. I have also noticed that the properties configuration window has changed drastically from version 1.7 to 2.0. I have even downloaded and installed the most current driver version (ver.2.6) and this issue is still present. Could I be missing something when I configure this new driver version? Please help!

0 Kudos
Message 1 of 7
(4,414 Views)

Very good description.

Just one extra question.

Is the LabVIEW software behaving like an instrument should?

and if the answer is Yes, another question:

Should you not running in slave mode in that case, without autopolling?

 

And NI guru's what do you think?

 

greetings from the Netherlands
Message 2 of 7
(4,411 Views)

Thanks for the quick response!

 

In answer to your question. Yes, the application software is acting like the instrument here. It is what is asserting the SRQ line. It doesn't seem to make any difference however whether autopolling is disabled or not on the app. software PC. As far as the tester simulator PC goes, I need it enabled when I'm communicating via the 488.2 communicator.

 

On another note, I've discovered one other way to get the SRQ line to unassert. After reaching an SRQ stuck-on condition, exiting the 488.2 communicator window on the tester simulator PC and then re-opening it by selecting "Communicate with instrument" also clears the condition. This is  a much more efficient way for me to unassert the SRQ. However, I still have to exit and re-start the 488.2 communicator on every 6th SRQ assert.

0 Kudos
Message 3 of 7
(4,399 Views)
Solution
Accepted by topic author donekes

Hello,

 

This issue can occur when the autopoll queue is full and the device asserts the SRQI line.  There are 6 bytes in the autopoll queue and so it makes sense that this would occur on the 7th iteration.  There is currently a known issue in the 488.2 drivers, due to the autopoll queue filling.  You can issue an IBRSP command to get a byte out of the queue to see if thati s the issue that is occuring.  When you continue to assert the SRQI line the queue you will see this behavior again, but this will help narrow the issue.

Caleb W

National Instruments

Message 4 of 7
(4,374 Views)

Hi Caleb.

 

Thanks for the suggestion. I tried your IBRSP solution out and that in fact did the trick! Is there currently any timeline as to when NI may be addressing this issue? I noticed it occurring in version 2.0 and we're already up to what, 2.6?

 

Don

0 Kudos
Message 5 of 7
(4,362 Views)

Hey Don,

 

There's not a set date, but it is an issue that is being looked at by the developers.  I apologize for the vague answer, but there has been no indication of a release date for a fix for this specific issue. 

Caleb W

National Instruments

0 Kudos
Message 6 of 7
(4,346 Views)

Alrighty then, I guess I'll keep checking back for driver updates. Thanks for all the help!

 

Don

0 Kudos
Message 7 of 7
(4,342 Views)