I've included a snippet of something that happens 8 times in a program I'm using. We are using NI to monitor bearing test stands and switch to shut off motors when certain criteria are met (High temperature, etc).
The boolean in would be a true/false from one of those inputs. Each time the main loop executes, as you can see from the snippet, it's going through the motions of setting the switch topology and setting the connection - even in the false case when nothing happens. I noticed that my main loop was running painfully slow (6.2 seconds or so) and did a tools/profile/performance and memory and found out that the switch modules were taking an extraordinarily large amount of time to execute.
I'd like to improve my main vi execution time and, in accordance, would like to come up with a better (or rather faster, the functionality is fine) way to go about it. I've set up this small VI and played with shift registers and all sorts of things and can't quite get the simple on/off functionality that I have in this method.
For those looking at the graphic and not the VI, the false case is identical to the true case except with a connection to nc0 instead of no0.
Thank you for the input in advance.
Why are you setting the switch configuration on every iteratation? That belongs outside the loop prior to the start of the loop.
What do you mean by "nothing happens in the false case"? You said the false case has nearly identical code, so obviously something is happening in the false case.
If the cases of the case structure are nearly identical, don't duplicate the code. Put common code outside. The only thing that belongs in the cases are what is different. If the only thing that is different is a given constant, then use a Select statement to choose which constant to apply.
Since the switch is a normal toggle switch, is there a reason to keep iterating the loop even if the boolean value of the front panel switch doesn't change? If not, then you should use an event structure that causes the code to run only when it detects the value change event for the boolean switch.
If I only knew exactly what all that meant.
I seemed to have a problem where if I set the switch once outside the main loop, it wouldn't reset after the condition was cleared. Of course this code is 5 years old now so I could be wrong.
In the false case, of course something is happening in the case, but what I mean is that nothing has 'happened' to trigger a true, yet the code is running in each iteration even though it isn't needed. Add that across 5-8 different switches and it adds up.
I have no need to continue to set the switch each iteration other than I can't seem to write code that effectively turns it 'on' (true case condition) and leaves it there, then allows it to reset to 'off' when the boolean changes.
This is as much as I got out of your post thus far; The set switch is absent from the false case as well. Thank you for the input so far.
Which parts of what I said you don't know what I meant?
If you only want something to happen when the value of the boolean switch changes, then maintain the value of the boolean in a shift regsiter or feedback node so that you can compare it between the last iteration and the current iteration. If the values are not equal, put your switching code in the case structure. Then use the current value of the boolean wire to determine whether to send one constant or the other to the DAQmx Switch function.
See the modified VI.
I think those DAQmx functions for the switch are rather odd. They say they are DAQmx, but generally DAQmx functions will output a task wire to string along to later functions. It allows you to have multiple functions operating on different equipment at the same time without the the DAQ functions getting confused. I don't know why these Switch functions don't have this.
Now that I see what you're referring to, it makes a lot more sense.
I'm going to be brutally honest, I've been at this for quite some time but never been really trained or given time to develop myself as a programmer. It's been 'get it done and get it working and now' with no development time of any sort.
Essentially, if the code worked, it was good enough, now let's move on to something else. Verbal descriptions of things do me little to no good and quite honestly I don't know what SOME of the bits in your example are, but I think I get the gist of the functionality. It is sort of what I was working on with the shift register -- Get the case to be false so the code is dormant until needed, use the boolean to turn the case true THEN pass the boolean through to the code inside. I wasn't able to work back from it to get a predictable 'off' state. I think I see how your example works even though I don't know what all the preceding items do (But I'll dig in and learn).
Hopefully I'll have a chance to test this later today when the fixture goes down for a bit. It's hard to prove out code with no development hardware and only machinery with billable hours being used. Thank you.