Code best practice question LV2013

[Ray.R · Accepted solution]

You would need to put part of the code you have circled in red within a While Loop, where it exits when the correct value is input.

So if true.... exit

If false, the case structure pops up the message.

Remove the nested Case Structure (2nd keypad sub-vi and check algorithm) as it is not needed... the first one will be called again in the subsequent loop iteration.

Since the value needs to be within 750 and 35000, you could do 2 things: 

1. set the input control to be a numeric I32 and set the range value to be 750 to 35000 (right click > properties).  Keep a small message ("Please enter a value between 750 and 35000) displayed.

2. have the input within a loop (inside the keypad sub-vi) and check for correct entry there.  Make a message visible if outside that range and let the operator edit the entry before hitting enter.. To make it foolproof, disable the enter key if the operator enters a value outside the range.  You will need to scan the input control at every keystroke (event structure) to trigger a check of the value.

[Gearmiester]

Thanks Ray let me think about that for a minute.

I see where you are going an I think if I remove the second (inner) case structure and use the retrigger on the message window as a shift register for the first case (outer) then put the contents of the second flat structure inside a while loop that should work? Or do I need the shift register to trigger on the while loop instead?

As far as setting limits to the keypad sub vi itself, I can't do that if i call the same sub-vi in another section of the code where the input values are limited at 0 to 360. Or if I need a keypad on screen to input a passkey or input a value onto a spreadsheet.  I need a generic keypad

[RavensFan]

---

@Gearmiester wrote:

As far as setting limits to the keypad sub vi itself, I can't do that if i call the same sub-vi in another section of the code where the input values are limited at 0 to 360. Or if I need a keypad on screen to input a passkey or input a value onto a spreadsheet.  I need a generic keypad

---

Improve your Keypad VI to allow you to do that.  When the keypad subVI is called, send in the valid limits as an input through the connector pane.  Inside the VI, use property nodes to set the limits of the numeric controls and also display a message relevant to that particular instance.  If you need a keypad that has no limits for a particular entry, then you can have a boolean input.  If true, it sets the limits.  If false, it widens the limits to + or - Inf and/or disables coercion for the numeric control.

[Ray.R]

Ah ok..  I understand..

You don't need a shift register...  Just the boolean output of the range.  Check if it is within the range and exit if true or go into the case structure and display the message if false. 

You could also add "intelligence" to your keypad sub-vi by adding a selector for the type of input that you need and use the appropriate algorithm.  There are other methods, but then we're getting fancy 😉

EDIT:

Just read RavenFan's reply..  He described what I had in mind with the additional intelligence / non-fancy solution..  😄

[Gearmiester]

thanks for the reply Ravensfan. <- (I won't fault you for that) - Seahawks baby!

Thanks for the reply Ray.

So I made sense of what you said Ray and came up with this correction to the code. Tried it and it works like I want it to where monkey finger operators cant input an invalid value because the error now just loops until a correct value is input.

This also resovles the keypad vi issue and I don't have to change that sub vi to make it code specific.

In the true case it just outputs to int front panel indicator and also activates a true constant to shut down the while loop.

Thanks for all the help! seems we made this a hot topic!

Edit - I removed the shift register and terminated the retrigger to the case structure and it works the same so Thanks again all!

[0utlaw]

Hi Gearmiester,

It should be possible to set the default limit control values to +/- infinity, as recommended elsewhere.  If the function is used in a context where limits aren't appropriate, simply don't wire those inputs.  It sounds like you have an alternate solution that works, though!

Regards,

[Gearmiester]

Thanks Tom for the reply.

I think the real issue with the keypad sub-vi is that I didn't write it and I don't quite understand everything in that code. It works as is and I just tuned the front panel to my aesthetic needs.

I am afraid that if I go tweaking on the keypad vi block diagram I will just foul up the code so it doesn't work. I mean sure I could just make a renamed copy and tinker - which I may do anyway as there is no error handling but for now it suits my purpose.

[RavensFan]

I still think you are going to have problems with the event structure buried in the case structure. And two event structures that are operating in parallel.

I'll be routing for the Seahawks in the NFC.  Probably Denver for the AFC.  And the Seahawks for the Superbowl.

[Gearmiester]

Thanks for that Ravensfan I needed a good laugh...

In all seriousness though what kind of issues will I really need to look out for with the event structure inside the case structrue?

The case structure is representative of the front page of the main vi and there are four pages. so I only want what is on the front page active at any given time as there are definitions that must be met to be able to change pages while the program is running. meaning that if you can tab through the pages nothing on the pages is active. and vise versa. if something on the front page is active then the tabs are locked out preventing the case from changing.

I have attached a new picture that shows a different front page selected and the code within that for some clarification maybe?

But I still want to know what you mean, though, so please elaborate a bit?

In so far as how the main vi program runs I haven't had any issues and have been running it as an exicutable on a touchsreen computer for at least 2 months now.

edit - let me clarify that this is only the main vi for the host computer. I am starting to work now on the cRio real-time target program and the FPGA programming. So maybe as I delve into the other two levels this could cause issue?

[Ray.R]

oops  😮

I had not seen that...  You have 2 Event Structures!!  Yikes 😮 😮 😮

Plus one inside a Case Structure!!!  😮

What may happen is if you are within another tab and create an event, when / if you switch back to the tab, you may have unexpected behavior.

Two Event Structures within the same VI is not recommended...  Especially inside Case Structure..

I would have a single event structure within a while loop at the top and pass the events to be handled via a notifier or queue to a consumer loop below it.