Instrument Control (GPIB, Serial, VISA, IVI)

Showing results for 
Search instead for 
Did you mean: 

Ridiculous GPIB ibwrt error when communication with Handler~

Go to solution

I have already communicated with several Handler/Prober normally before.

But I meet a ridiculous issue to communicate with a new handler today, and can't find how to solve it.

the basic communication protocol is handler will trigger a SRQ 0x41, then I will use ibwrt  to send a command and use to read the result~

In normal case, before communication I will use NIMax scan for instrument function to make sure Handler's status is normal.

In this ridiculous case, if the Handler is in normal status (ni max can detect the handler), when I receive SRQ, I send the ibwrt command will get EABO error, like the attached file IMG_0340.jpg....

then if the handler is not in normal status (ni max can't  detect the handler), but I still can receive SRQ and send the ibwrt command will successful, like the attached file IMG_0352.jpg. 

I don't know why? the issue is me or handler software?

Please help me~thanks


Download All
0 Kudos
Message 1 of 5

You don't seem to be comparing identical cases here.  It would be a lot simpler if you posted the commands you were sending in sequence rather than a photo os a NI-IO trace! 


Its hard to debug your problem when you post two traces that clearly show two completely different case of operation. 

- In the error case the log shows you initialize communications, set the timeout, disable DMA, set the SRQ then set the instrument to wait, then do a read which times out or interrupts the ibwait resulting in the EBAO error.  I suspect your instrument never asserts a service request since you havent sent it a command to do so.


- In the other case you do a serial poll for byte 0 and then 65, get no erros an then send the instrument a command (FULLSITES?)  and read a response.  All works fine.


Its not really clear what the problem is, you can obviously communicate with the instrument just fine.  Are you using existing code that doesn't work or writing new code and trying to figure out command sequence?  


Your full sequence should be something like..

- intialize communications

- setup timeout

- setup SRQ events

- send command that will cause SRQ event

- ibwait for SRQ

- ibread()



0 Kudos
Message 2 of 5

Dear Craig

I'm very appreciate for your reply. The following C++ code is my basic communicated flow.

while (!Exit_Flag)
   unsigned int srq;
   char result[128];
   ibrsp(UD0, &srq);
   if (srq&0x41 == 0x41)

First, use ibdev to get handle for instrument. Then use a while loop to polling SRQ event that Handler will trigger it. If get the correct SRQ (0x41), I will use ibwrt to send the command and use ibrd to read the command result. 

Do I lost some command before ibwrt?


I find out that I attached the wrong NI TRACER picture. so it can't be really to explain the situation that I encountered. I will explain again and use correct picture.


The current situation is if NIMax can't not detect the Handler, after ibdev command, I user ibrsp will display red line error in NI TRACE. but It still can detect the right SRQ if handler trigger, and I then use ibwrt and ibrd will correct. Like IMG_0352.jpg


if NIMax can detect the handlerafter ibdev command, I user ibrsp will display correct status  in NI TRACE. It still can detect the right SRQ if handler trigger, but then I use ibwrt and ibrd will EABO error. Like IMG_0340.jpg




Download All
0 Kudos
Message 3 of 5

You really shouldn't run NI-MAX and your measurement software at the same time.  The results won't be predictable as they will likely intefere with communications.  If you close NI-MAX and just run NI-I/O Trace in the background, what happens?  


How many times is the loop iterating?  How many commands can the instrument process or store?


The code looks ok, I'd be tempted to replace the ibwait() with just a regular time delay and not be sending so many commands over the bus.  

0 Kudos
Message 4 of 5
Accepted by topic author ychch

Thanks for your reply~~

The result of the issue is Handler Software bug~~


0 Kudos
Message 5 of 5