Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Multithread problem with ibstop()

I have a VC++6 application that uses a thread to read data from the GPIB
using ibrda(). Another thread needs to send data to the GPIB. If I use
ibstop from this thread (the one that did not call ibrda) before sending the
data, the ibstop call does not return. The function that sets up the async
read and the one that calls ibstop are protected by a critical section. Any
ideas as to what would cause ibstop to get hung up? When I break using the
debugger it is stuck in a loop in Shell32.
0 Kudos
Message 1 of 4
(3,795 Views)
I have some questions for you in order to get a better picture of what is happening.

1) What OS and NI-488.2 version are you running with?
2) Why are you using one thread for the asynchronous I/O and resynchronizing with another? I mean, does something in your application prevent you from trying to resynchronize with the same thread that is calling ibrda()?
3) What are you protecting in the critical section? Are you trying to protect your own particular data? Note that if you are trying to protect the threads in the driver, that is unnecessary, since the driver already handles that for you.
0 Kudos
Message 2 of 4
(3,795 Views)
The OS is Win 98 (the problem does not manifest on WinXP).

The main program processes user input which may have to send commands to the
device. There is a dedicated thread which reads data from the device
(real-time, asynchronous).

The critical section protects the higher level functions for sending data
(commands) to the device and the one that reads data from the device. I
think I would have no problem if there was a version of the driver that did
not try to take care of the multithreading. Is there a way to disable it?

Note that I had a similar problem with the Measurement Studio graph
controls. The only way we got around it was by disabling multithread
capability when we created the graph.


"Geneva L." wrote in message
news:50650
0000005000000B2B20000-1031838699000@exchange.ni.com...
> I have some questions for you in order to get a better picture of what
> is happening.
>
> 1) What OS and NI-488.2 version are you running with?
> 2) Why are you using one thread for the asynchronous I/O and
> resynchronizing with another? I mean, does something in your
> application prevent you from trying to resynchronize with the same
> thread that is calling ibrda()?
> 3) What are you protecting in the critical section? Are you trying to
> protect your own particular data? Note that if you are trying to
> protect the threads in the driver, that is unnecessary, since the
> driver already handles that for you.
0 Kudos
Message 3 of 4
(3,795 Views)
I should have asked what GPIB card you are using as well. If you are using the PCI-GPIB or another interface supported by the NI-488.2 version 2.0 driver, then I recommend trying this driver as the next step. You can check at the Current GPIB Driver Versions (http://www.ni.com/support/gpib/versions.htm) page.

This is the latest driver and it implements multithreading in a different manner from the other drivers. Note that for any of the NI-488.2 drivers, there is no way to disable multithreading capability.

I would like to work with you in getting your feedback about what happens when you use the 2.0 version of the driver, or if you have an interface not supported by the 2.0 version. So, could we continue this correspondence through th
e NI e-mail support? Go to the http://www.ni.com/ask page and choose e-mail. Fill in the information about what happens with 2.0 or if you cannot use 2.0, etc. In the description, also reference that you are x@no.email from the Developer Exchange, so we can identify your issue.

Regards,
Geneva L.
GPIB/Serial Product Support Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 4 of 4
(3,795 Views)