Rif.: Problem with timing a driver

[moderator1983]

---

@Norbert_B wrote:

1. It is not common to include "(SubVI)" as part of VI names. As there should only be a single top-level VI (rule of thumb) in an application, EVERY other VI is automatically SubVI. Marking that additionally seems to be overhead.

---

---

@inuyasha84 wrote:

1- I haven't understood what you want to say here... 

---

The ZIP file you attached contains 5 VIs, and 4 of them are subVIs, Norbert_B wants to say, you need not add 'SUBVI' to their name, as in a program, generally only single VI is a top-level (main) VI and all others are subVIs. Instead you can place all subVIs in a separate folder.

[inuyasha84]

Ok thank you 🙂 

Today I have learnt a lot of things. 

[Norbert_B]

---

@inuyasha84 wrote:

[..]10- I haven't understood what do you mean here...[..]

---

This refers to

10. Do not hide state transition code in a functional subVI. Either you have a specific "Transition" VI or place the code directly in the state machine.

I now understand why your transition code is hidden in those subVIs as you marked existing code and used the Edit >> Create SubVI functionality to generate the subVIs.

The point is, you also selected the transition code of the individual states to put them into the subVI. You shouldn't do that.

Make it a rule:

A subVI has to be as "genereic" and simple as possible. Focused on one functionality.

When following the rule, chances are high that you can re-use the same VI over and over again, even in different projects!

Norbert

[Norbert_B]

---

@inuyasha84 wrote:

[...]
8- yes is costant, that's the reason why i haven't put a control as you suggest..because it was boring to set it everytime 😛
[...]

---

That's why i wrote you should define a good default value.

If the value is correct you entered manually, select Data Operations >> Make Current Value Default in the context (right-click) menu.

Norbert