Hi, I'm using LabVIEW to build a test program for monitoring the status of 9 switches for a long period of time, and I need to log down the following data: How many times is the switch turned on?How long has the switch been turned on?How long has the switch been turned off?I've built a VI but it looks really huge... So how can I simplify it? Also is there any method to reduce the consumption of CPU resource? Such as using 'wait' function? The data stored in the array is in this format: Cycle counter On-time Off-time BufferSwitch 1 Switch 2 ... Switch 9 Thanks, David

Your method would necessitate repeating the log F->T and T->F routines in every case structure for ever value, which can be a pain if you need to make a change to that routine. Take a look at the code I've attached. The one case structure that I have will contain just one instance of each routine and the row of the 2D array that it applies it to is dynamic and determined by which switch was toggled. Also, you can just index the boolean array at the switch point and read it's value. If True then it was a F->T transition, and if False it was a T->F transition. One other thing, you had wired the stop button to the stop terminal of the while loop. When you have an event structure it just sits there waiting for one it's events to trigger it into action. Since there was no Stop event the Stop button never actually stopped the VI. So I added back a Stop value change event so it would work. Let me know if this makes sense.

LabVIEW

Log down the accumulated on/off time and number of cycles

Solved!

A queued producer/consumer architecture would definitiely be your best bet. I've attached a vi with a couple of suggestions. At the top of the block diagram I show an easier way to make the initialized timing array. The bottom portion shows you what the producer can look like. Everytime there is a trigger it takes the trigger array along with the data array and combines the two to be queued up. On the consumer side you can split the array apart and then run it through the for loop to see which switches need new timing data. Also, on the producer side you can set up your DAQ assistant so that it will control the timing of the consumer loop by setting it up as follows:

The rate will determine how fast the producer loop runs. The code you attached will have the while loop containing the DAQ Assistant running as fast as it can, eating up your computer's processing power. I bet you don't need to be reading it that fast, so it is a good idea to throttle it back some.