11-03-2022 04:29 AM
Hi all,
I have been looking around the internet to solve this problem and I can't find a solution that I can understand. I have to create a VI that when I enter a temperature value that's out of range a dialog box will open to warn the user. However, when answering the dialog box, it immediately opens again because the while loop still sees that the value is out of range.
What I would like is to be able to input the value after acknowledging the dialog box warning.
This is my first assignment in LabView so I am not familiar with all the terms, in other forums I saw people say, 'just use a latch' and other terminology I am not familiar with. I assume there's a relatively simple fix as this is our first assignment, so I am just really trying to understand what I am doing.
Any help will be much appreciated,
Kern
Solved! Go to Solution.
11-03-2022 04:51 AM
Explore on usage of Shift Register where you can hold the previous values and decide based on the Previous and current values.
11-03-2022 07:34 AM
Thank you for pointing me in the right direction.
I think I am close for what I want but it's not running exactly how I want it.
So now it isn't stuck on the dialog box, but I don't want the program to end if the user inputs outside the temperature range. Ideally, the program would end after the correct value is inputted and if outside the value the user will get another attempt to input the correct value.
I think my confusion lies with the boolen and interger values.
Thanks again for the help,
Kern
11-03-2022 08:28 AM
Hi Kernel,
@TheKernel wrote:
So now it isn't stuck on the dialog box, but I don't want the program to end if the user inputs outside the temperature range. Ideally, the program would end after the correct value is inputted and if outside the value the user will get another attempt to input the correct value.
From your description it seems you need to invert (use a boolean NOT) your conditions…
You will get much more and more detailed help when you downconvert your VI to LV2021 (or even LV2019). Many experienced users don't use LV2022 due to license issues…
11-03-2022 10:16 AM
OK, I had a change to look at your code and I really recommend to start with a few tutorials.
11-03-2022 10:34 AM - edited 11-03-2022 11:27 AM
Your "start" button is just silly. Why do you think you need it? (If you really need it, use a simple state machine)
It is also a bad idea to hide indicators inside case structures because it might display stale data. Apparently you want to only display coerced values, so just use that output. I would actually recommend to use the reading of the slider directly so we see the out of range value.
Here's a quick draft to give you some ideas (top). Compare with your code (bottom).
The case structure goes TRUE whenever the boolean changes from TRUE to FALSE (i.e. new value is smaller than old value).
You actually only need a one button dialog (or even a "no button" dialog! Everybody is familiar with the [X] in the upper corner and you get that for free!)
11-03-2022 03:01 PM
Hi, thanks for the in-depth critique.
There were a few things I couldn't do with your example. Specifically, the green forward arrow. As a result, I was having the initial problem with not being able to exit out of the dialog box. So, I wired the message with the stop to end the code.
The reason I put the start arrow in the sequential frame was so when you hit run it wouldn't immediately pop up with the warning message if the numeric control was on the default 0. I'm sure there are probably a million better ways to do that, but as I said before, very much a noob here.
If I have done something egregious with the attached code, please point it out if you have time. I have been watching some youtube videos, but I think your suggestion of a more structured tutorial course is probably warranted. If you have any links, that would also be appreciated.
Thanks again,
Kern
11-03-2022 03:18 PM
I have no idea what a "green forward arrow" is. Do you mean the feedback node?
Did you even look at my attached code (link is below the picture)?
You could also use boolean crossing, but it is overkill here.
Sorry, I currently don't have a computer with LabVIEW 2022 on it. Make sure to "save for previous" before attaching. At least 2020, or earlier, then attach the down-converted version (will be in a folder)
11-03-2022 03:30 PM - edited 11-03-2022 03:32 PM
@TheKernel wrote:
The reason I put the start arrow in the sequential frame was so when you hit run it wouldn't immediately pop up with the warning message if the numeric control was on the default 0.
There is never a reason to have a toplevel loop without any wait. You are burning one CPU core spinning the loop millions of times per second just for polling a button! How fast do you think is the communication chain between your brain, your finger, the mouse button, the OS, the LabVIEW program? All you do is waste electricity, starving all other running processes, and heating your room with the waste heat from the CPU while the program is not doing anything useful.
It is not clear why you think forgetting to set the control to a better value before running is any different that forgetting to set a better value before pressing your button? Seems about the same, but one needs much less code!
In any case, you can set the default for the control to a better value (enter e.g. 20 into the control, right-click...data operation ... Make current value default ... save the VI). Problem solved!
11-03-2022 04:56 PM
Agreed, the less CPU the better. I am currently running labview through the virtual machine on my MacOS 11.4.
The green arrow I referred to is this
I think I attached my updated code with the the 2019 version, but if not here is a screenshot anyway: