Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Blocking read on GPIB bus, and CPU not tied up

Can U tell me how to read GPIB buffer on asynchronous events using ibrd and the EOS termination.
When I program my application and when no EOS is reveived the CPU is tied up, blocking the rest on the threads of
my application.

What I want to do is to wait the EOS termination buffer but not tied up the CPU.
Is it possible easily or do I need implementing interrupt and catch signal?
How can I configure the bus for no polling at all?
0 Kudos
Message 1 of 12
(3,993 Views)
Julien,

Please reply to the other thread which you started on this topic. What programming language are you using? Is this in Linux? What driver version? How do you know that the CPU is tied up? How many other threads does your application have? Are these threads doing GPIB communication or something else?

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 2 of 12
(3,983 Views)
Scott
I program in C under Linux Red Hat 8.0
The linux driver is 0.8.5, which is not thread safe, is it.
I have a single main

The CPU is tied up because I have no cursor on the screen and I have to halt manually the PC
to work again.

Thank U
0 Kudos
Message 3 of 12
(3,980 Views)
Julien,

Can you upgrade to our latest Linux beta? Are you using multiple threads in the program? Are they all doing GPIB? What GPIB calls are you making? Which one is hanging the system?

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 4 of 12
(3,972 Views)
I have one NI PCI/PPIB controller card and one Newport motion controller.

One thread is calling ibrd synchronously, and must return if data are available.
The other thread is calling ibwrt with the same device ID and writes commands to the GPIB.

Is it possible to call ibrd in one thread and ibwrt in the other?
0 Kudos
Message 5 of 12
(3,970 Views)
Are you doing this:


//Initialization:
ibdev()

//Thread 1:
while (1)
{
ibrd()
}

//Thread 2:
ibwrt()
ibwrt()
ibwrt()
ibwrt()

//End
Ibonl(0)

If so, I would recommend rearchitechting your code. If you are continually calling ibrd() then it doesn't necessarily tie up the CPU but it will tie up the GPIB Driver. Only one thread can have a pending GPIB operation at a time. The driver will make sure that it doesn't mix or combine the two calls. This may be what you are seeing.

The recommended way of doing this is to call ibwrt() and then only call ibrd() when you have data available to be read from the device. You should know which strings will return data from your instrument. If you don't, consider using the RQS bit or the SRQ line (or both) to know when you should read. Please see the documentation for an explanation of these lines.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 6 of 12
(3,960 Views)
Thank U so much.

To finish with, the global data ibsta, iberr and ibcnt are not thread safe for my 0.8.5 linux gpib driver!
Will a new thread safe release for linux be available soon ?
0 Kudos
Message 7 of 12
(3,955 Views)
Julien,

Yes, that's true; newer versions of the driver include "ThreadIberr()" and "ThreadIbsta()" for thread-safe status. Check out our latest linux beta driver at www.ni.com/beta. You can sign up to receive it there. It has these thread-safe calls, and with what we discussed above, you should be all set.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 8 of 12
(3,938 Views)
Thank You Scott.

I have just downloaded the linux beta driver 2.3 on ni.com/beta but I have got some problems to install
because libnipalu.so is not created...
0 Kudos
Message 9 of 12
(3,936 Views)
Julien,

Please submit bug/support requests through the beta website so that we can track them. Be sure to provide all the details of your problem including linux distribution and a full output of the install script (if applicable).

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 10 of 12
(3,924 Views)