LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Code best practice question LV2013

Solved!
Go to solution

I am still fairly new to LabVIEW programming and I have been learning from the online self paced classes. I started in June of 2012.

 

I am currently working on a new program front panel (host) vi and I am trying to determine a better way to implement a certain section of my code so that it works the way I would like it too. This vi is being designed for a touchscreen interface so all user input is touch screen input.

 

What I want the code to do: the code is designed so when the user presses the command button on the front panel vi it creates an information pop-up window explaining the parameters for input. The user pushes the OK button (closes the info pop-up) and opens a new sub-vi that is a numeric keypad. If the user input is within the accepted parameters then when 'enter' is pushed the sub-vi closes and inputs the value to a numeric indicator. If the user inputs an incorrect value, then the keypad sub-vi closes and another info window pops up informing the user 'incorrect value - re-enter value' user hits the OK button and closes the info box and reopens the keypad sub-vi. This cycle should continue until the operator inputs a valid value.

 

What the code does as written: when the user presses the command button on the front panel vi it creates an information pop-up window explaining the parameters for input. The user pushes the OK button (closes the info pop-up) and opens a new sub-vi that is a numeric keypad. If the user input is within the accepted parameters then when 'enter' is pushed the sub-vi closes and inputs the value to a numeric indicator. If the user inputs an incorrect value, then the keypad sub-vi closes and another info window pops up informing the user 'incorrect value - re-enter value' user hits the OK button and closes the info box and reopens the keypad sub-vi. If now on the second attempt the user still inputs an incorrect value and presses 'enter' the keypad sub-vi closes and I have had to defer the value to output '0' (or some minimum allowed value).

 

So the question I am trying to figure out is this. Is there a better way to implement this section of code to work like I want it to, maybe using shift registers or something and where would they go?

 

I am using the most current version of LabVIEW 2013.

The code as pictured works great outside the fact that I have to stop it after two attempts otherwise the code would have to be rewritten for each failure and it would look like staring off into oblivion between two mirrors.

 

Thanks,

0 Kudos
Message 1 of 24
(4,114 Views)

Hi Gearmiester,

 

Welcome to the forums!

 

I don't know that it's the *Best* approach, but a simple way to implement this would be to move the in range check inside the keypad popup itself.  Initialize the keypad VI with a valid range and reject entries outside of that range.  This avoids the need to launch and re-launch the keypad. 

 

Regards,

Tom L.
0 Kudos
Message 2 of 24
(4,095 Views)

Thanks for the reply Outlaw.

 

I would do this except the keypad sub-vi needs to be an 'unrestricted' vi as it will be used in other parts of the code to impliment values that would fall outside the range of this particular calling.

 

Remember, this is a touchscreen aplication and as such there are no external peripherals such as keyboard and mouse to input values. All of these peripherals must be programmatically called for input as required buy the user. So I can't restrict the sub-vi's to specific callings.

0 Kudos
Message 3 of 24
(4,086 Views)

It also looks like you may be abusing the event structure. In general, you use only one event structure and you do not place an event structure inside of a case statement. The event structure is always capturing events and not just when the case it is in is true.

0 Kudos
Message 4 of 24
(4,080 Views)

Gearmiester wrote:

What I want the code to do: the code is designed so when the user presses the command button on the front panel vi it creates an information pop-up window explaining the parameters for input. The user pushes the OK button (closes the info pop-up) and opens a new sub-vi that is a numeric keypad. If the user input is within the accepted parameters then when 'enter' is pushed the sub-vi closes and inputs the value to a numeric indicator. If the user inputs an incorrect value, then the keypad sub-vi closes and another info window pops up informing the user 'incorrect value - re-enter value' user hits the OK button and closes the info box and reopens the keypad sub-vi. This cycle should continue until the operator inputs a valid value.


Why do you check for valid entry outside the sub-vi that allows the operator to input a value?  You could simply monitor each keystroke (every character entered) and have a small algorithm that checks for a correct entry on the fly (while it is being entered).  You could change the color of the text to red and make a brief description appear below the string control which describes valid entries.  Keep it simple.

 

 


Gearmiester wrote:

What the code does as written: when the user presses the command button on the front panel vi it creates an information pop-up window explaining the parameters for input. The user pushes the OK button (closes the info pop-up) and opens a new sub-vi that is a numeric keypad. If the user input is within the accepted parameters then when 'enter' is pushed the sub-vi closes and inputs the value to a numeric indicator. If the user inputs an incorrect value, then the keypad sub-vi closes and another info window pops up informing the user 'incorrect value - re-enter value' user hits the OK button and closes the info box and reopens the keypad sub-vi. If now on the second attempt the user still inputs an incorrect value and presses 'enter' the keypad sub-vi closes and I have had to defer the value to output '0' (or some minimum allowed value).

 


Why is the 2nd attempt different than the others?  It does not matter how many attempts are made... since it is not an automated process, but human interaction.  Surely, the operators are trained and would have an idea of what should be entered.  Additional instructions can be provided within documentation that accompanies the application.

 


Gearmiester wrote:

So the question I am trying to figure out is this. Is there a better way to implement this section of code to work like I want it to, maybe using shift registers or something and where would they go?

 

I am using the most current version of LabVIEW 2013.

The code as pictured works great outside the fact that I have to stop it after two attempts otherwise the code would have to be rewritten for each failure and it would look like staring off into oblivion between two mirrors.



Do you absolutely want it to work as described within your first paragraph?  There are always "better ways" to do things, that's a personal preference..  Maybe you should ask the people that will be using the application to get their feedback (operators).  That's what I usually do.

Using the latest LabVIEW version is fine, but has little or no impact on the implementation decisions.  😉

 

If all you really want is to fix the code to prevent it from stopping after 2 attempts, then show us a code snippet of what you have done.

0 Kudos
Message 5 of 24
(4,077 Views)

you have to read my reply above out of context...  I had not seen the other replies, yet..

 

Show us the code snippet

0 Kudos
Message 6 of 24
(4,072 Views)

Thanks for the reply Dennis

 

This main vi is tab controlled pragmatically via a set of radio buttons. When the vi is running on the touchscreen the 'tabs' are not visible and only on page is accessible at a time. When the top page is open the other pages are idle and do nothing. If there is activity going on on the front page (user inputs causing things to happen) then it pragmatically locks out the other tabs until the 'default' setting are resumed.

 

The event structure (labeled as MODES) only controls the tabs of the main vi

 

The case structure (labeled MAKEUP) incorporates all controls and I/O for the front page marked MAKEUP. So far there are four pages controlled in this way with a fifth page that operates as a full screen pop-up without interfering with operations of the current open page.

 

The other thing is that I am not done building this code and as I learn better ways to write the code I will do my best to implement them. I am not sure this satisfies the stated concern you made but maybe it help understanding?

0 Kudos
Message 7 of 24
(4,055 Views)
the code as described is in the attached photo...
0 Kudos
Message 8 of 24
(4,050 Views)

photo?

😉

 

Using tabs do not prevent you from verifying the correctness of the input as entered by the operator.  I would still do it in the sub-vi which offers the numeric keypad.  If the numeric keypad is the only means of entering the information, then you can limit the valid inputs to numeric 0-9 and period.  Are there other characters?  By catching the invlaid input, you can ask to correct it even before they hit the enter button, thus eliminating the need to "retry" in the other VI.

0 Kudos
Message 9 of 24
(4,043 Views)

Thanks for the detailed response Ray.

 

Perhaps I am missunderstanding you question about the code.

 

 

Download All
0 Kudos
Message 10 of 24
(4,037 Views)