08-22-2005 08:07 PM
08-22-2005 08:12 PM
Hello everyone!
I've been working on a program that tests truck cabs. Things have been going well as of late, thanks to all of your guidance. Unfortunately, I have another problem. The program is a queued state machine that consists of basically three types of VIs:
1) The first type of VI uses a string control to print a question that prompts the user to type a number into another string control. Then the user presses the "NEXT" button to enter the data. At that point, the data is validated. If the data is good, a green LED lights up at the bottom right corner of the window, and the program moves on to the next window. If the data is bad, a red LED lights up at the bottom left corner of the window, and the same window repeats.
2) The second type of VI uses a string control to print a question that prompts the user to either press the "YES" button or the "NO" button depending on whether the user agrees with the question or not. If the user presses the "YES" button, a green LED lights up at the bottom right corner of the window, and the program moves on to the next window. If the user presses the "NO" button, a red LED lights up at the bottom left corner at the window, and the same window repeats.
3) The third type of VI uses a string control to print some sort of message or instruction. The user is prompted to press the "NEXT" button to acknowledge either understanding of the message or completion of whatever he or she was instructed to do. Upon pressing the "NEXT" button, a green LED lights up at the bottom right corner of the window and the program moves on to the next window.
08-22-2005 08:13 PM
Each of these three types of VIs has a "BACKWARD" button at the top left corner of the window and a "FORWARD" button at the top right corner of the window. These buttons were included to allow the user to skip forward or backward to any test at all times.
The problem is this:
When the user skips back through tests that have already been completed (right or wrong), the data that was entered is gone. The data that should be displayed after entry will vary depending on the type of VI used in each particular case:
1) The first type of VI should remember and display the numeric value entered into the string constant. Also, the LED that lights up after the data is entered should still be lit. The only time the numeric value or the LED should change is if the user goes back to that particular frame and reenters the data.
2) In the second type of VI, the LED that lights up after the "YES" button or the "NO" button is pressed should still be lit. The LED should only change if the user decides to go back to that particular frame and press the "YES" button or the "NO" button again.
3) In the third type of VI, the LED that lights up after the user presses the "NEXT" button should still be lit. This should only change if the user decides to go back to that particular frame and press the "NEXT" button again. Since there is only one LED, this shouldn't be a problem. This LED should probably just go off and on if the user decides to repress the "NEXT" button just to acknowledge that the user is repressing the button, but if it would be easier to just leave the LED on continuously, I could live with that.
08-22-2005 08:18 PM
There is only one other type of VI and that is the front panel of the main VI. It should work much like the third type of VI only it doesn't have a "BACKWARD" button, and the "FORWARD" button is at the bottom right corner of the window along with the LED.
Below is my entire program as it stands so far. I wouldn't mind some good advice. If you would like to modify the code and send it back to me, that would be OK too. This code may need to be completely overhauled to make these the above possible. Be brutally honest like always.
I hope you can help.
Thanks,
08-23-2005 08:37 AM
08-24-2005
12:43 PM
- last edited on
11-29-2025
04:21 PM
by
Content Cleaner
OK, your program has a lot of cases, so it's kind of hard to give a definitive answer, but it basically boils down to this - the front panel retains its information as long as the VI isn't called again. Once it is called again, the new information overwrites the previous information.
One way to work around this would be to make the subVIs VI Templates (simply renaming to *.vit should do) and calling them dynamically. This will create a new instance of the VI in memory which can hold its own data. You will need to manage the references that come from opening the VIs and use the reference if you need to "reopen" it.
Another tip - your code has endless repitions, which you can get rid of. For example, every frame has an Enqueue at the end and a conversion to string. You can get move these out of the case. Some of the inner frames also have a duplicate conversion to string. You can move that out of the frame as well. As a matter of fact, you can get rid of them entirely if you just use the number as the case selector.
Even more so, you can probably create an array with the numbers of states and the strings and search each of the arrays for the current number to know which subVI you need to call. Then, you extract the string from the array and wire it into the subVI. This way, you only have 3 states instead of 112. I'm not sure how well this would work with the vit approach.
Another point, you don't need the queue - simply use a shift register.
One last thing, if you have an error, you should probably do something about it. You can add an error handling case to your machine.