LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Code Review

Hi all,

 

I would like you to give me some advice on the code below.  I have that case structure in my subvi with 10 cases.  For each case, only the polymorphic subvi and the indexing code are different (only slightly).  Is there a way to further modularize it (one subvi for each case)?

 

Yik

 

Code.JPG

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 14
(3,174 Views)

Slightly may mean one thing to you and another to someone else, and in either case it is difficult without seeing the code.  You will either need to post your code, or show a couple of more cases.

 

One SubVI for each case?  That is only a cosmetic change and since your BD is not so big I don't know why you want that.  On the other hand, one SubVI for all cases (or several) would be just what the doctor ordered.  For this, we need to see more code.

 

Final note from picture:  For very interesting reasons you may want to get into the habit of putting your array controls and indicators on the top level diagram (not inside the case structure).  In some cases, not necessarily this one, it will save you needless data copies.  Just a good habit to adopt, mostly applies to times when you are passing data through, but why think about it?  I think searching for "Clear as Mud" explains a bit more (ironically).  

Message 2 of 14
(3,151 Views)
This is a continuation from an Idea on the Idea Exchange. Could you upload Multiple Convert.vi?
0 Kudos
Message 3 of 14
(3,130 Views)

Just a thought, what if the sub vi also does the type -> variant? If so, you can wire the Type to the sub-vi and skip all the cases (maybe) as you'll just add variants to the array.


Would that work?



/Y
G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 14
(3,125 Views)
Here is the code.
------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 5 of 14
(3,090 Views)
Interesting comment, Darren.  I thought about that question in regards to leaving the control/indicator in/outside of error case structure.  For some reason, I thought it would be better to put them in, but I will take Darren's word for it, and leave them out.  I like them out, actually, since it make the error case structure smaller. 
------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 6 of 14
(3,087 Views)
Hi Yama, please explain.  I am not really familar with variant, and I am trying to get better at ti. 
------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 7 of 14
(3,082 Views)
Missing a few pieces, but I wouldn't create any subVIs I would simply move everything outside the case structure except for the polymorphic VI and To Variant function.  The rest looks identical and would be a nightmare if (I mean when) you screw something up in there.
Message 8 of 14
(3,083 Views)
BTW, why would putting the control/indictor outside case structure save memory? 
------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 9 of 14
(3,068 Views)

jyang72211 wrote:
BTW, why would putting the control/indictor outside case structure save memory? 

In this case it won't make a difference since you are not passing through data.  When you are working with arrays (or strings) or other large data structures it is useful to pass data through subVIs as opposed to branching wires.  When you pass through data, the compiler needs to know if the operations can be done in-place, and if there is even the slightest doubt, it guesses no and makes a copy.  One pattern the compiler will recognize is data being passed through when the control and indicator are on the top level of the diagram (not in a case or loop structure).  If one or the other is inside the case, a copy is made.  My point is that it is almost always a good idea to put controls on the top level, seeing that control and indicator inside your case structure rang a bell with me.  A similar idea holds with loops, unless the control is meant to be read during the loop, it should be placed outside.  Sometimes a little extra wire can save a lot of time and memory.  (Again, more of a general statement not a comment on this particular VI).

 

After a few reads of the Clear as Mud thread and some headscratching it makes sense, in the meantime it is better to build good habits and good style.

Message Edited by Darin.K on 02-25-2010 04:24 PM
Message 10 of 14
(3,059 Views)