Is there any drawback of using "Subvi" or "Local variable"?

[MogaRaghu]

Well its a big leap (mentally )  for those migrating from C to LabVIEW. Without variables C is zero and with too much local variables LabVIEW is messy.

Being Sunday I created a VI just for fun and with intentional race condition.

But when I ran it normally,  it was always displaying "100" in the indicator. Always.

The same VI when run with "Highlight Execution"   ON,  produced all the different values.

Why ?

Raghunathan

[altenbach]

---

@Raghunathan wrote:
Why ?

---

The "indicator" actually flickers between 500 and 100 but the display time for the 500 is infinitely short, so you don't see it (even when set to synchronous display)unless you run in highlight execution mode, where everything is slowed down.

You can easily show it better if you use a chart as indicator as in the attached modification.

But yes, you cannot determine what numbers will be displayed by looking at the code, and if you would rearrange things, convert it to a different LabVIEW version, or write the VI once more from scratch, you might get different numbers. There is no way to tell. 🙂

[Camu]

Thanks for your discussions. The original Vi my lab-member made is nice, but it isnot modularized. All the codes are put together and it is difficult to make "updates". That's why I want it redesigned using subvis and local variables.

[DFGray]

I have redesigned large VIs which are in the state you describe.  I would urge you to not rewrite from scratch, since the original does work.  Instead, do the following steps:

1. The program is not modularized, so go through it; identify what the logical subVIs should be.  Don't create them just yet.
2. Look at the program flow and decide on a maintainable, extensible base program structure.  This usually means some sort of state machine architecture.  You may need a producer/consumer architecture, as well, to handle simultaneous tasks such as data acquisition and GUI handling.  <shamelessplug>LabVIEW is great for these sorts of parallel architectures.</shamelessplug>
   
3. Create the base architecture in a new VI.
4. Copy the old code pieces (the new modules) into the new code architecture.  This is the point you create the subVIs, as needed.
   
5. Fix any bugs that remain due to the architecture change.

Good luck.  You can find good examples for all the program structures I mentioned above in this forum or in the LabVIEW examples.  If you need any specific advice, don't hesitate to ask.

[MogaRaghu]

---

@DFGray wrote:

1. Look at the program flow and decide on a maintainable, extensible base program structure.  This usually means some sort of state machine architecture.  You may need a producer/consumer architecture, as well, to handle simultaneous tasks such as data acquisition and GUI handling.  <shamelessplug>LabVIEW is great for these sorts of parallel architectures.</shamelessplug>

---

While on the subject of StateMachines, which I use extensively, how does LV handle that ? Does the whole SM come under a single thread or every instance of the SM gets handled in a new thread ? My SM is inside of a 50ms Timed Loop and thus there is a finite interval between each call to the SM.

While there are different options to step through each state ( shift registers, queue etc ) I think the SM is the only option in LV,  when it comes to writing machine control codes - say for instance a 6 junction traffic signal sequence??


Raghunathan

[DFGray]

Since a state machine is a loop, it is in a single thread.  There may be other things in that thread, depending on how the rest of the code is written.   Two parallel state machines may be different threads or the same, depending on how the code around them is written and the hardware (FPGA, embedded, or desktop).  LabVIEW usually does a pretty good job of separating parallel processes into separate threads and taking advantage of all the underlying hardware can offer.

You can write control code without a state machine, for example, as a simple sequence in a loop.  However, such architectures are difficult to modify and it is difficult to handle such things as errors conditions with them.  That is why state machines are so popular.  They are easy to code and modify.

[MogaRaghu]

---

@DFGray wrote:

 That is why state machines are so popular.  They are easy to code and modify.

---

Thanks for your clarifications.

But since a SM is almost like a stacked sequence, it is a big pain-in-you-know-where

Unless you practice very strict discipline in terms of layout, wiring and placement of functions etc the SM frames are a nightmare....

Raghunathan

[Dennis_Knutson]

I don't think a state machine if very much like a stacked sequence strucure at all. Using proper coding style is not unique to a state machine. It applies to the simplest LabVIEW programs you can write. A state machine can actually make this job easier if you make your states simple and single purpose.

[andre.buurman@carya]

And contrary to the stacked sequence, an obsolete case in a SM doesn't need to be removed to test it. And wiring an enumerated type def to the case selector and deleting the default case even signals you when you miss a case and documents it.

Regards,

André

[MogaRaghu]

---

andre.buurman@carya wrote:
 And wiring an enumerated type def to the case selector and deleting the default case even signals you when you miss a case and documents it.

---

The point regarding enumerated type def is fine - but when my state machine has something over 75 odd states I really run into a problem looking for short and descriptive names for each state  I do agree that  SMs are a great boon for control sequence coding but then complex problems DO need complex solutions. I was just thinking loud when I complained about them...

raghunathan