Numerical indicator and validation

[fabricio19]

Hello,

I'm working a new project and I have a question regarding numerical indicator.

It's not so easy to explain but maybe it's the answer is too easy 🙂

When I want to change a value on an indicator, for example Init time, if I use the top or bottom arrows, after pressing APPLY, there's no problem.

If I put the cursor inside and change it with my keyboard and keep my cursor inside the indicator and press Apply, the modification not taken into account.

It's a bit annoying to have to click each time next to the indicator to validate.

Strangely enough, I have other identical functions that don't have this problem and I can't find any difference.

My version is labview 2015 32bits

Thanks a lot for your advices.

[GerdW]

Hi fabricio,

---

@fabricio19 wrote:

When I want to change a value on an indicator, for example Init time, if I use the top or bottom arrows, after pressing APPLY, there's no problem.

If I put the cursor inside and change it with my keyboard and keep my cursor inside the indicator and press Apply, the modification not taken into account.

It's a bit annoying to have to click each time next to the indicator to validate.

---

When you can change values at runtime then you are using controls and not indicators…

When you use the arrows then you create a "value changed" event for each mouse click.

When you place the cursor inside the control and change the value using the keyboard (either numbers or up/down/left/right keys) you don't create "value change" events: that event gets toggled once you press the ENTER key or click outside the control.

BUT: when you immediately click the "Apply" button then the value change of your numeric input might "come too late" to be processed before your "apply data" operation…

How does the block diagram look like? Do you use the event structure?

[fabricio19]

Yes, you are right, it's not indicators but controls...

Yes I use some event structure like following : 

I use an event structure because I have lots of button to check in my front panel :

[Bob_Schor]

I really should let @GerdW explain this, but the problem is the "Apply" button, and the (improper) use of Local Variables inside the Event Structure.  Your Event Structure should "fire" every time you change one of your Front Panel Controls.  Your Event Structure needs to be inside a While Loop, because it needs to be updating whatever the output of the "Levels" sub-VI is doing and saving it in a Shift Register (inside the Event Loop's While).  You need a separate Case for every Control whose "change" you want to capture.  Indeed, if "Levels" is simply taking all its inputs and bundling them into a Cluster (which is the way I handle these things), then you don't need the sub-VI at all.  Here's how I would do this:

1. Create an Event Structure inside a While Loop (which endows the Structure with "memory".
2. Put a Shift Register near the top.  Initialize the Shift register by wiring a Cluster (blank, probably) of all of the elements that you are going to stuff into the Cluster.  [If you are using an Array instead of a Cluster, I strongly advise that you consider a Cluster, instead].
3. For each Control whose new value you want to "capture", create a Value Change Event.  Either put the Control, itself, inside the Value Change Event or use the "New Val" element present in the Event inputs on the upper-left side of the Event Structure.  Drop down a "Bundle by Name" function, break the Shift Register wire running across the top of the Event, bring the left side into the top of Bundle by Name, find the name of the Control, and wire the Control (or "New Val") to immediately update the Cluster of Controls.  Finally, wire the output of Bundle by Name to the right terminal of the Shift Register.
4. Now when you push "Apply", instead of using the "Level" sub-VI and who-knows-what values of the Controls, you use the Shift Register (which is updated every time you change a control).

Bob Schor

[fabricio19]

Thanks a lot for your answer.

It's very interresting. I understand the concept.

Do you think, it's possible to find an example online or on the website ni.com.

It could help me a lot to save time. 🙂

Best regards

Fabrice

[altenbach]

As has been explained in other words, controls have their own space data that gets read asynchronously by the code via a transfer buffer. Changing an entry without hitting enter or clicking outside will not push the value to the code side.

I would love the see the rest of the code, but it seems to greatly suffer from "chronic localitis", possibly due to prior experience in mostly text based code. I am sure some simple rearchitecting would greatly improve overall behavior and make things more rigorous and predictable.

For example a single typede'f cluster connector to the subVI would significantly simply the current spiderweb of wires entering from all sides.

[fabricio19]

This is the rest of the code.

With each test bench I develop, I try to improve parts of it, and it also helps me to progress even if I don't do Labview every day.

It's always interesting to talk to specialists.

[GerdW]

Hi fabricio,

---

@fabricio19 wrote:

This is the rest of the code.

---

You're kidding, the block diagram is WAY TOO big (navigation window):

• Clean up to decrease block diagram size!
• Replace each local with wires or use their terminal!
• Use shift registers to hold data instead of abusing locals!
• Use clusters to bundle related stuff instead of placing arbitrary decorations around them…
• Think about what you are doing: do you really need a DBL local variable to define the (U8!) TermChar of your serial port??? Why not connect that LF (aka 10) directly???

Then re-attach the VI…

[fabricio19]

Hello,

I'm in the process of taking over the work of a trainee and it's not easy.
It's been a war to get him to reduce the size of the VI during his whole internship.

You made a very good point about the size of the variable. In fact, on embedded boards, we pay attention to this to reduce program and memory size, but not necessarily in my case. When programming with labview, you don't necessarily pay attention to this kind of thing, and that's a mistake.

Concerning the end-of-string character, we tested it with a variable because this character is used in very many places.

Thanks for your advices. I will work on it.

[altenbach]

I am so sorry you have to deal with this code! I think it is beyond repair.

This code should get tossed and rewritten from scratch. It is not salvageable. It shows a complete misunderstanding of graphical programming and the magic and power of dataflow. Whoever wrote this was probably a text programmer unwilling to even look at the LabVIEW documentation. It's not just the size of the diagram (which has nothing to do with memory use), but mostly the logic and architecture.

• This entire things is written like text based code with all terminals lined up disconnected (probably trying to mirror variable definitions!), then everything (everything!!!!) is bounced around via local variables (Huge probability of race conditions because nobody knows who wrote to them last! That's like herding cats!). This increases the memory use, because many extra buffers are needed behind the scenes.
• You cannot have seven (!!!) event structures, each in a separate case of the same case structure. It shows a complete misunderstanding of event structures and UI handing. All you need is exactly one event structure containing all event cases from all event structures. The idea of hooking the tab terminal to the case structure, each containing events for that tab is silly and unnecessary micromanagement. If a certain event fires, we already know what tab is currently on. In most programs, the tab terminal is not connected to anything and it does not need to!
• The program does not really do that much! I am sure, properly written, this diagram can fit nicely on a 1080p diagram and would be easy to debug and expand in the future. currently it is an unmanageable hairball.