LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

conditionally read/write terminals on the connector pane (Core 3 training)

Solved!
Go to solution

Hello,

 

during my practice toward CLD exam, I review the Core 3 online training material too. I was just reading some "best practice" advices on the forum, for example this post:

http://forums.ni.com/t5/LabVIEW/Community-Nugget-Wired-Terminals-in-Subdiagrams-Clearing-up-the/m-p/...

 

It is emphasized there, that we should not use terminals (which are on the connector pane) inside any while loop or condition structure. Neither controls, neither indicators (read/write terminals): "Conditionally read/written terminals on the connector pane are BAD!"

 

I can find many examples in the online training material, when indicators and controls are placed inside in while loop and case structures in a subVI.

I guess I should not do this way during my CLD exam, since they will run benchmark on my project? Should not be the Core traning material get updated sometime? Or it is just not too important to have terminals outside? Would I lose points during CLD exam doing my project like in the Core 3 VIs?

 

1 example: Core 3, Exercise 4-6 Design an Error Handling Strategy:

 

TLC_Cue module.png

 

EDIT:

What is even more ugly in this project is that, in the "Get Empty Cue" case, the Cue Output indicator is updated via a local variable, since the indicator is not reachable via wire "outside":

 

tlc_2.png

 

 

 

 

 

0 Kudos
Message 1 of 9
(3,166 Views)

Conditional Terminals do affect runtime performance. That is why it is recommended to avoid these.

As a second point, it could be a disadvantage during debugging.

 

That being said, conditional terminals itself aren't "bad" (just like variables). There are applications and code segments where the usage of those is NOT "bad".

Regarding conditional terminal: Is it really suitable for code where only a single case writes a value to an indicator, that the indicator has to be placed outside the case which in return requires all other cases to write proper values to that indicator?

But the other question is: What happens exactly, if you do not write new values in all those other cases?

 

It is recommended to avoid conditional terminals, but some algorithm are still fine using them.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 9
(3,147 Views)
Solution
Accepted by topic author Blokk

Nice catch on the training material.  that implementation would take a hit from the test graders if submitted on a CLD exam.  

 

As noted in the nugget: the perfomance penalty for conditionally reached terminals is a fuction of data size.  so it is sometimes acceptable for simple data.  The bigger point being to know about the tradeoffs and make the correct choice for your code.

 

Preping for the CLD on the other hand means knowing that VI Analyzer will be run on your project.  Just like any other code review you walk into - know the review guidelines and code to "pass review" as well as "meet spec."

 

I have not seen an instance where a shipping example (2013 and later) would fail that VIA test (there are some vis deep inside vi.lib that may predate adoption of this style recomendation) 


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 9
(3,142 Views)

Thanks Norbert and Jeff!

 

I will keep in mind that, if I have such a situation in real application, it is ok to have such "inner" written indicator, and maybe an additional local variable (in the above example we have 6 cases, and 2 of them writes data to the indicator, one is via local variable).

However, I think during the CLD I will just try to play safe, and put everything "outside". In this way I feel it is also more clear that we explicitly write some default (zero, etc.) value to indicators.

+ some upper level wrapper subVIs could be benefitial, and then there is no danger using terminals non related to the required action, but of course this requires some more work, and as many wrapper subVIs as many action cases we have...

 

EDIT: by the way, if I need to use ActionEngine(s) during CLD exam, do you advice to use wrapper subVIs (encapsulation)?

I mean, wrapper subVI for every action (with descriptive icons), and put these subVIs together with the core AE and the typedef enum into a lvlib inside the project tree. Also, the scope of the core AE subVI and the typedef enum could be set as private, so only the wrapper subVIs are callable from other project VIs. Is it worth to do this additional effort (more time spent) during CLD exam?

 

0 Kudos
Message 4 of 9
(3,134 Views)

You have 4 hours.  A naked AE with good documentation would be my choice rather than risk the penalty for failing to document a set of wrapper vis.  In practice, If the scope is large and the development team >1 body.  Ill wrap them every time.


"Should be" isn't "Is" -Jay
Message 5 of 9
(3,105 Views)

Blokk wrote:

I will keep in mind that, if I have such a situation in real application, it is ok to have such "inner" written indicator, and maybe an additional local variable (in the above example we have 6 cases, and 2 of them writes data to the indicator, one is via local variable).

However, I think during the CLD I will just try to play safe, and put everything "outside". In this way I feel it is also more clear that we explicitly write some default (zero, etc.) value to indicators.


That is the way to go.  I had a good state machine wear only two states could update an indicator and I used a local for one of them.  That was one of the points I lost ("use of local variable).  Keeping the terminals outside of the case structures is a really good rule of thumb anyways and you should be in the habit of doing that.

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 6 of 9
(3,093 Views)

thanks again for all the advices!

I just feel I learn as much in these weeks during practicing toward CLD exam, as in the whole previous 2 years... Even if the exam will be failed, the practice itself worth it 🙂

Message 7 of 9
(3,086 Views)

Just for the reference:

In the tlc_Error Module.vi (Core 3, lesson 6), there are non-default usage of type def cluster constants (the correct method would be using the bundle by name to set the enum typdef value). This would also yield minus points during CLD exam, yes (and not to mention that again some input terminal controls are inside a case structure.. )? Smiley Mad

So a question just started to rise. Why NI is still having the Core 3 online training material in this form? Exam takers could argue after getting minus points in CLD exam, that the online Core 3 training is misleading, no? I heard that actually the Core 3 classroom training (which is not free) is nowadays totally different, and has a different example project. I feel this is not really fair toward the people...What is your opinion?

 

edit.: of course, the exam takers should not rely solely on the Core 3 training, but still this is a bit problematic point lets say 🙂

 

example_typedefs.png

0 Kudos
Message 8 of 9
(3,016 Views)

@Blokk wrote:

 

I just feel I learn as much in these weeks during practicing toward CLD exam, as in the whole previous 2 years.


We like to help, and part of the way we help is by helping point out where improvements could be made.  Feel free to post your practice CLD over at the certification board, where people can go over your source and give their opinion.  We can't say if you would pass or fail, but it is useful to get real feedback on something as subjective as a practical exam.

0 Kudos
Message 9 of 9
(2,995 Views)