LabVIEW
shift register resets
Solved!
You don't supply the value to the output tunnel. And since the tunnel is setup to Use Default If Unwired, then the default value is going into the shift register. Two suggestions here:
- Right-click on the output tunnels of your event structure and uncheck the Use Default If Unwired.
- Right-click on the output tunnels and go to Linked Output Tunnel->Create & Wire Unwired Cases. Then select the input tunnel that should correspond to the output tunnel you are using. This will automatically wire up the input and output tunnels for every case that you don't already have an output value for. It also automatically wires them up in any new cases you create.
Some other comments:
- You don't need the wait in the while loop. The event structure will limit your loop rate for you.
- DON'T USE THE ABORT BUTTON!!! You need to stop your loop somehow. I would recommend passing out a TRUE value out of the Stop Logging event and wire that to the conditional terminal. This way your VI will stop gracefully instead of acting like a car stopping by running into a tree.
In addition, the three latch action booleans belong inside their respective event cases, else the don't reset to false when the event is handled.
... and yes, add a stop button and an event for it.
Even better would be to replace the "start logging" and "stop logging" buttons with a single switch action button that has two different boolean texts. Use a single event case that has a case structure it it so the start or stop action is executed depending on the the new value. Half the number of buttons and you no longer have a need for all these property nodes to change visibility.
@vakost wrote:
I had the impression that it is better to use seperate event cases in the event structure rather than case structures inside the event structures. The code looks more elegant to me this way (of course, I am new here so I don't have any experience to judge).
The fact that you can eliminate one button and six property nodes is reason enough. I have no idea where you get your "impressions" about what is "better"? Micromanaging two booleans with six property nodes is significantly less elegant than dealing with a single button that requires no property nodes at all. Do a side-by-side comparison on code and diagram complexity and the ease of code maintenance.
vakost wrote:Is there any specific reason we do not want to use property nodes? Because my program is full of property nodes.
Property nodes should be used sparingly, because they require significant effort and resources. They typically require a switch to the UI thread. What do you mean by "full of property nodes"? What kind of properties? How many?
You did not attach anything.
There is nothing wrong with property nodes for front panel properties, but make sure you don't write the same values over and over in a tight loop. They only need to be written when the property actually changes.
Value properties should typically be replaced by local variables. Often they are both not even needed if using proper dataflow. (Value property nodes are only required to target individual elements in clusters or to change proertyies from within a different subVI).
@vakost wrote:
But I want to prevent what you said, to not stop the car by crashing on a tree.Any other way to do that?
What I typically do is use the Application->Panel Close? event. Notice the question mark on that? That is because it is a filter event. This means that I can get LabVIEW to discard the event (meaning, tell LabVIEW not to close the panel). So I discard the event and tell the while loop to stop. You could also put any cleanup code inside of the event case, but I prefer putting that code after the loop since I could have other events stop the loop (like a stop button, error, certain key commands).
