How can I avoid hardware crashes in reentrant vi's

[dacad]

I have an extensive testing application that tests a pneumatic device and I read and write to a single multi-channel power supply (Sorensen/Xantrex), and read from two pressure transducers (std 0-10 vdc output)

The station has two test 'cradles' that I have configured to run completely independent by using several reentrant vi's.  While doing my best to make it break, (as the operator surely will) I have two conflicts that have shown up.  First is in reading the pressure transducer on one side only.

I started with the two transducers connected to AI0 and AI1 but since moved the second transducer to AI2 just to see if it would help (not sure what I was expecting but tried it anyway)  On the second transducer, I am subject to get an error that won't allow it to read and indicates the resource is reserved.   I use the same (reentrant) vi to read both transducers and never get the error on the first transducer, only the second one.

Any thoughts on this would be appreciated.

Second conflict is in addressing the power supply, again, same (reentrant) vi but sending commands for channel 1 or channel 2.  After the first conflict, I lost the resource and could not read or write anything. Stopping and re-starting the application fixed this as it re-established the resource but this won't be an option once the system goes live.

Any thoughts on this one would also be much appreciated.  I can post code as needed.

For ref, running on Win7 32 bit with a USB-6221 Daq

Thanks

Doug

[johnsold]

Doug,

I am guessing since you did not post any of your code.

Reserved resources usually indicate that you are trying to do two different things with the same hardware device.  The 6221 has only one A/D converter which is multiplexed among the available channels.  So you cannot define two different tasks to do AI, even if they do not both run at the same time.

What I suggest you try is to make a parallel loop which reads all the transducers and sends the data to the separate VIs which test each cradle.  This way you have only one palce in your code which attempts to use the resource.  This is a variation on the Producer/Consumer architecture wher you have one producer and two (or more) consumers.  You will need separate queues for each consumer.

The same approach applies to the communication with the power supplies. Create one message handler VI which communicates with both devices and, thus, does not have a resource conflict.  You may need two more queues (or maybe 4) to pass the messages.

Lynn

[Mark_Yedinak]

I think you should avoid using reentrant VIs. You have a single piece of hardware yet are trying to have two systems access it at the same time. You might want to consider creating a hardware task that handles all of your interaction with the DAQ. Use queues for messaging. Each of your test cradles would send messages to the hardware task requesting it to perform a service. Anyway you look at it the single device will be a source of a bottle neck in your system and therefore you need to manage access to it.

[dacad]

I understand the approach(es) suggested but am concerned I may lose the integrity of the timing within each test sequence by using queues as once a test is started, a specific sequence of routines if followed and timing is important.

That being said, It will be easy enough to try and see what the results are.

I am not clear on the limitation you indicate on the AI's for the 6221 though. I have always set up multiple tasks for the various AI's on a single device but am only now am running into trying to read in a true parallel mode.  If I were to combine the two channels into a single task, would that resolve the conflict possibly?

If I have 16 AI channels but can only touch one at a time, that is a huge limitation if I were to have many AI's running in parallel loops.

Will try the mentioned approaches and see what happens

Thanks....    Doug

Semi-related: I had considered using a vi template for the two different test sequences as opposed to two loops in the top level vi but am thinking this would not really do anything to address the issues I am seeing as this would still require the same sub-vi(s) to be called on independently.  Plus I would have to feed a buttload of variables in and out that are depend to one side or the other.

[johnsold]

Doug,

Read all 16 AI channels (N Chan, N Samp) in the DAQ VI. Split out the data for each device (Ch 0, 1 to Device A, Ch 2, 3 to Device B, ...). If the test for Device B is not running at a particular time, simply discard the data.

Designed properly you should have no data timing integrity problems.  In fact because the AI process will run continuously, this approach might produce better timing than using separate VIs for each channel.

Lynn