Switch Hardware and Software

[Ben]

Hi BigBen,

I just had the chance to download and look at your .zip.

Have you tried using virtual channels yet?

The example you provided is repeatedly creating IVI sessions and then closing them. There has been talk about memory used for references not being free'd-up when released. How about building an array before you enter your main loop that has the four IVI references you need to pass to the read fucntion. Inside the loop, iterate through each of IVI references passing them to the read function as you go. Then close all of the references only after everything is done and the codes is ready to exit.

If the freeing-up is the issue, you may be able to duplicate the problem without doing the actual read. Just put a case around t
he read and wire a constant to keeps the read from occuring. If the problem still occurs try the scheme I mentioned above.

Just trying to help.

Ben

[BigBen]

I will modify my application to create an IVI session only once at the beginning and close the session when everything is done.
So I will put the "Initialize" and "Close" VIs outside the loop.
Thanks for pointed that out, a memory leak might be the problem.

Benoit

[Ben]

You are very welcome.

If the restructure works NI should be notified so they can fix the bug.

Ben

[Revilo]

I'm running into this problem also!
My problem is intermittent but it doesn't take long to make it happen.

My application is in an ATE system. I've customized a command interpreter that keys off words in a text file for running tests. In the measurement routine it opens the device and closes it each time. After about 30 iterations or so I start receiving this error. I've tried resetting, re-initializing and closing the device but once it hangs I also have to shut down power on my chassis to clear the error.

Has there been any corrections on the NI Vis?

[LuI]

Hi,

the very same is happening to me now. I have two NI-PXI4070 DMMs running here with the most recent drivers as of January 2005. The very same problem. I even have to power-off-reset the PXI-1010 chassis and to reboot the PC in order to get it working again.

The DMM-related part of my app is build on the example 'acquire & graph multiple samples.vi'.
I've just replaced the direct wires 'IVI-session' between the different subVIs with read/write to a global.

The whole app initialises my DMMs and creates a session for each of 'em first. Than it initiates several different processes that do their measurements (of course the access to the DMMs is restricted using named semaphores). When all those processes are done, the DMM sessions are closed.

Updating all drivers to the most recent versions (as of January 2005) did not solve anything. It even introduced some more trouble with a service called nidevldu, that did no longer start. I had to repair MAX in order to fix this.
I'll keep this thread informed

Greetings from Germany!
--
Uwe Frenz

[drkovrlord]

Uwe,

I can't say for sure why you might be seeing the problems that you are, but when you say:

"I've just replaced the direct wires 'IVI-session' between the different subVIs with read/write to a global."

Do you mean that instead of wiring your VIs together, you have instead used global variables to pass the refnums? This strikes me as a bad idea, as it seems like it could lead to all kinds of problems with race conditions. If you go back to just wiring VIs do you still have this problem? I would suggest trying that.

<-*DrkOvrlord*->

[LuI]

DrkOvrlord,

you are right in a global manner, but there are situations when this kind of coding is usefull.
This is a kind of 'one parent process with several child processes'. I create a session in the parental VI and pass its refnum to any of the child vis. These use the session in combination with a semaphore. When all child vis are done, the parental vi closes the session.

The very same problem occured as well in the example meanwhile, at least once now. So it looks to me like a weekness in the driver.
Thanx anyway!