Notifier Question

[_Bryan]

  Currently I have 3 while loops, (1) controls a booster pump, (2) controls a set of digital channels (which cycle valves) and (3) takes accelerometer data.  Currently I have loop 2 send a notifier to loop 3 just before I cycle a valve to arm the daq card taking data, then loop 2 open/closes the valve. 

The problem is that sometimes the card arms and sometimes it does not.  So I am wondering the best way to have loop 3 send information back to loop 2 that it is ready and it can continue.  Can this be done with the same notifier somehow? 

  My original thought on this program was to try and keep each step seperate (pump controls, cycle timing and daq) since they all work on their own schedule.  I can't combine loop 2 and 3 because when I arm my card it stops the loop it is in until it is triggered by an accelerometer that goes outside a windowed range.

[johnsold]

Bryan,

When I need two-way communication between parallel loops I use a pair of queues, one for each direction. Notifiers should work also. I use the queues because I am often sending other data, commands, or status as well. With three loops I may have two or three pairs of queues, depending on whether each loop need to communicate with both of the others or just with one of them.

I often use this for initialization and shutdown so that things happen in the correct order.

Do you know why the card sometimes fails to arm? Perhaps the problem is something other than communication between loops?

Lynn

Message Edited by johnsold on 05-14-2008 02:37 PM

[_Bryan]

Hello Lynn,

  My best guess is that I am not giving the card enough time to get ready before the event happens.  As soon as I send the notifier to the daq loop I trigger the event.  I played with arming the card about .5 seconds before the event happens and it seemed to work fine, I am just looking for a more better way to have them work together. 

I am working with 6 solenoids that are cycling and I can't have any of the open/close events overlap because of the daq card.  So I am using a state machine to basically step through each open/close and track the time to keep everything seperated.  It seemed like the easiest path at first, but obviously now I have to modify each open/close case with the soloution.  I am almost temped to scrap it and try to come up with a different method so changes don't hurt so much.  But of course they want it soon.

[johnsold]

Bryan,

Can you run the DAQ continuously and parse the data as needed? Since you are talking about pumps and solenoid valves, things are probably not running too fast.

Start a continuous acquisition of the accelerometer data for all the channels (to allow for possible open/close overlap). Put the data into separate buffers for each channel. The buffers can be implemented as queues or Action Engines. If you know how much data is important for each test, use circular buffers.

Then run the solenoid valve loop. If you have the bandwidth and extra channels, monitor the logic signals which control the valves through the analog acquisition. This provides the reference timing for the opening and closing of valves.

Two or three loops containing state machines should be adequate to handle what you have described. With some care and planning I suspect that you could handle all the valves with independent timing in one loop (and maybe the pump, too). An 8-bit integer could represent the state of 6 solenoid valves and the pump with a bit left over. With masks it is fairly easily to change one or two bits at a time without affecting the others.

Lynn

[_Bryan]

Lynn,

I am using a PCI-5105 for the accelerometer data.  The pumps are just cycling pressure and the solenoids are on a 70 second cycle with a staggered start to keep them separated while opening/closing. 

I was looking at triggering off the accelerometer because my boss wants consistent data between all the files, so they can easily be aligned and compared after the test.  I told him it sounded like a personal problem for the engineer, but he was not buying into it.  

So you are thinking I could adjust the queue sizes to hold just the amount of data I need and when I change states on the solenoid use that as a trigger to save the data in the queue to a file.  That does not sound like a bad idea at all, if I can get it to work.

Hopefully the data will be consistent enough for them.

Thanks