Case Structure Confusion

[gjacob]

I have started making a program to monitor some measurement devices which continuously measure: water flow, temperature, and pressure. There are a lot of limits for the user to set. For each measuring device (there are 3) the user can set soft limits for the 3 parameters. If the data goes above the max or below the min, I would like the indicator box to turn yellow. The user also sets hard limits, which are the same idea, but when these are exceeded I'd like the indicator box to turn red. When the data is fine, I want the indicator box to be green.

When I run the program, it seems like responding to a case structure causes the program to stop, even though it is in a while loop that should only stop when I press a button. I'll attach the code, and hopefully someone knows how to remedy this.

P.S. If you know a better way to do the comparisons and change the color, I would be more than happy to hear it!

Thanks!

[RavensFan]

I don't know what you mean by "responding to a case structure causes the program to stop".

But the way you built the case structures feels backwards to me.  I would put the property node after the case structure (instead of having 3 identical ones in different cases).  Then I would have the color boxes inside the cases.  So with the logic determines what color to write out rather than having the logic determine which wire coming in to send to which copy of the property node.

Beyond that, I would go one step further and make a subVI, where the inputs are the current value and a cluster of the conditions you are comparing to.  Let one copy of the subVI do all the work.  The output is the color to be written to the property node.

I myself would go a step further and put that subVI into a For loop.  Since you are starting out with an array of 9 elements, I would auto-index off of that along with references for each of the indicators you want to change the of.

[tbob · Accepted solution]

I removed the DAQ stuff because I don't have a DAQ installed, and I put in a random number generator to create the data array.  It ran fine.  It continued until I pressed stop.  Maybe you have a DAQ error that is stopping your vi.  You should include Error In and Error Out in your code.  Also, you should put a DAQmx Clear function at the end of your code.  Your method for changing colors is what I would use.  The fact that you have so many controls makes the code cumbersome.  Instead of using greater than and less than, you might simplify your code by using the In Range and Coerce function.  You can code soft limits into one In Range function and the hard limits in another In Range function.  You would have to make the hard limits override the soft limits, as you are doing presently.

To simlify the code, you could also create arrays to hold all the limits.  Pass your data array from the DAQ read into a Foor Loop with indexing enabled.  Inside the loop, you use the loop index to index the limits arrays, then use In Range functions to determine hard and soft limits violations.  You would need a case structure to dictate which indicator to update.  Wire the loop index to the case selector.  This wold process one channel at a time, but its so fast that I don't think you would notice a difference.  The code would certainly be smaller and easier to read.

[F._Schubert]

You are right that your code can be made much better. I don't have the time right now to look into the logic more deeply. I suggest you to look at the breakpoint forum for the 'Rube Goldberg Code' thread. You will see many 'bad examples' that show a similar code and some solutions to improve it.

I think the best way to get cleaner code is by the use of arrays (maybe the threashold function can work some 'magic').

For the simple request of a better function: 'In range and coerce' will reduce the size of your code by at least factor 2.

Instead of nested case structures you can use 'boolean array to number' and then use case 0,1,2,4,...

Felix

[tbob]

Each nested case structure can be replaced by using the Select function.  This would simplify the code somewhat.

[JÞB]

What version of NI-DAQ are you using?

It seems like your task is not properly configured.  You should be specifying the task acquisition mode (in your case it would be one sample on demand)  but you are depending on the default task settings.  You may not be able to depend on the AutoStart property unless you are using NI DAQ 9.1.1( that read vi instance has a bug) so you will need to start and stop the task in each loop iteration

[gjacob]

Well, this is a lot to take in all at once. I have not modified the code yet, but I think that I am using version 9.0.2 of NI-DAQ because when I got into MAX it says I have that version of NI-DAQmx device driver installed.

[JÞB]

I usually just "cheat".  I develop my task from MAX and make sure it does what I want.  Then just Drag and drop the task from MAX to my Block diagram Right-click the task constant that dropped and select "Generate Code">Configuration and example.

DAQmx 9.1.1 can be downloaded from here and the release notes claim that the bug reported in CAR 185781 "NI-DAQmx auto start doesn't automatically stop task when reference triggering is enabled" is fixed.

[gjacob]

Well, I have tried to take as much of this advice into account as possible. Here is the work so far.

[gjacob]

The problem that remains is that only the first box's color gets updated, and the program seems to stop updating after a while... Hmm...