Serial poll seems to swallow SRQ 70H - other SRQ values work correctly.

[Walrus]

NI4882 Device-level Serial Poll behaves differently when equipment asserts 0x70 vs. any other SRQ value.  For every value other than 0x70h, the returned SerialPollFlags contains the asserted SRQ;  for 0x70, the value is a non-integer text value.  I'm certain the equipment is asserting 0x70 because I see the value in NI-Spy.  I'm using NationalInstruments.NI4882.dll v2.0.50727.  Any ideas what is going on here?  Thanks !!

m_testDevice.Wait(GpibStatusFlags.Timeout | GpibStatusFlags.DeviceServiceRequest);

SerialPollFlags spf = m_testDevice.SerialPoll();  // does not like 0x70 !!

int n = Convert.ToInt32(spf.ToString());

[Alisha_P]

Hi Walrus,

I'm not sure exactly what's going on here, but I was wondering if you could post your NI-Spy Log. Also, what value are you getting when your equipment asserts x70h - you mention that it's a non-integer text value? What equipment are you using? Do you have multiple pieces of equipment along this serial line? Let me know and maybe I can be of more help.

[Walrus]

Hi Alisha,

Thanks for your reply !!

I'm developing a tool simulator, so both host and equipment are standard Windows XP computers.  The equipment I'm trying to simulate is a TEL prober, which asserts 0x70 during its process flow.

Each computer has a GPIB board - one is PCI, the other is USB - and they are connected by a single cable - no other instruments on the bus.

I did more investigation on this:

m_testDevice.Wait(GpibStatusFlags.Timeout | GpibStatusFlags.DeviceServiceRequest);

SerialPollFlags spf = m_testDevice.SerialPoll();

The issue is the Wait() method is timing out.  when I look at the spf value following the timeout, the value is:

NationalInstruments.NI4882.SerialPollFlags.RequestingService | NationalInstruments.NI4882.SerialPollFlags.MessageAvailable

When the timeout does not occur, the spf value is the SRQ value: i.e., if I send an SRQ59, the spf value is 59.

This issue occurs for some SRQ values, but not others.  The timeout is 20s, so I seriously doubt it is a "real" comms issue.  I tried sending each SRQ value, from 1 - 127, and here is what I found:

SRQ 1-64 (decimal) ALWAYS time out

SRQ values: 80, 96, 112, 128 (all decimal) produce the timeout

All other SRQ values in the range 65-127 (decimal) work fine; no timeout

The behavior is 100% repeatable.  Help !! 

Thanks + regards, Rick

[Walrus]

I did a little more testing on this.  after rebooting both of my test boxes, SRQ 1 - 64 worked - so I suspect the prior issue with those SRQ's was residual from prior failure.

Only the following SRQ values are problematic at this point:

00010000 0x10 - broken
00100000 0x20 - broken
01100000 0x30 - broken
01000000 0x40 - broken
01010000 0x50 - broken
01100000 0x60 - broken
01110000 0x70 - broken
10000000 0x80 - works
10000000 0x90 - works

Interesting the low-order four bits are zero for each of these - does this mean anything to anyone?

Plan B: don't use the .NET assemblies for GPIB - and if I have to go that route, are there examples for calling the older GPIB methods from C# ??

Thanks !!!

[Alisha_P]

Hi!

We've done some testing to try and replicate this odd behaviour, but we haven't been able to replicate it; it seems to work fine on our end. 

If you could send us your code and screen shots of how your GPIB interfaces are set up in MAX, then we can help you further troubleshoot this issue.

[Walrus]

Hi Alisha,

Deal !!  I created both sides of the interface and I included a document that shows my setup.  I think I added enough comments in the code so you can follow it (fairly simple), but please do let me know if you have any questions.  After you unzip the attachment, navigate to .\NISerialPollTester\Doc - it contains a word document with the GPIB setups and instructions for setting up the test. The file also contains output - so you can get a good glimpse of what is going on.

I really appreciate your help !! 

Regards, Rick (AKA, the Walrus !!)

[Alisha_P]

Thanks for your files! We're looking into it.

[Alisha_P]

Hi Rick,

I notice in your GPIB configuration that you have autopolling checked. This might be creating a race condition that could result in what you're seeing. Can you run the test again with autopolling unchecked and see if you get the same result?

[Walrus]

HI Alisha,

I cleared the autopolling flag (host and device) and received the same result.  On another note: I retooled using the language interface, which uses the "traditional" gpib commands - it works with no issue.  If needs be, I can leave it as-is.  Incidentally, I only need SRQ64-127 to work - I checked our automation code and found values < 64 are masked out.

Thanks, Rick

[Alisha_P · Accepted solution]

Hey Rick,

I'm a little confused by your statement "I retooled the language interface." What exactly did you do? Does that work as a workaround for you or does using the "traditional" gpib commands cause you additional problems?