LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

variables without indicators and controls

Solved!
Go to solution

@Viper wrote:

On the block diagram right click on the terminal for the indicator or control and select hide.


Yeah, that's how I've been doing it, but agree with Bill and several of the other posters that this is not good practice...however I disagree with Bills comment: "That's like saying 'I prefer no to use functions because they clutter up my text code with all those pesky returns' in a text-based language."

 

I believe a more correct analogy would be that the "returns" have a literal wire connecting them that is cluttering up the workspace, rather than an invisible 'pointer.' My issue is with the way the data is graphically connected between states (or functions, per the analogy), not the data itself. I feel that I shouldn't have to create and maintain wires for 'variables' in states that do not use those variables (ie. passing input to output shift registers and never using a single passed parameter within that state). When I use local variables, I do not need to worry about this...I use them where I need them, and omit them where they are not needed. Yes, it is up to me to ensure the data is not stale...but to me, that seems like good programming practice anyway...?

0 Kudos
Message 21 of 35
(972 Views)

@R.Gibson wrote:

@Viper wrote:

On the block diagram right click on the terminal for the indicator or control and select hide.


Yeah, that's how I've been doing it, but agree with Bill and several of the other posters that this is not good practice...however I disagree with Bills comment: "That's like saying 'I prefer no to use functions because they clutter up my text code with all those pesky returns' in a text-based language."

 

I believe a more correct analogy would be that the "returns" have a literal wire connecting them that is cluttering up the workspace, rather than an invisible 'pointer.' My issue is with the way the data is graphically connected between states (or functions, per the analogy), not the data itself. I feel that I shouldn't have to create and maintain wires for 'variables' in states that do not use those variables (ie. passing input to output shift registers and never using a single passed parameter within that state). When I use local variables, I do not need to worry about this...I use them where I need them, and omit them where they are not needed. Yes, it is up to me to ensure the data is not stale...but to me, that seems like good programming practice anyway...?


Any time you ask a human to keep track of something, you're asking for trouble.  😉

 

Bundle up your wires.  Use SubVIs - voila!  No more clutter.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 22 of 35
(960 Views)
The shift register is a single wire that you can tuck up next to the top of the case statement and takes up very little room. The unbundle by name is about the same size as the local so I don't see how your approach is any neater. It just creates code that is less efficient and more subject to race conditions. The soft register allows to write/read controls/indicators only when necessary or in states only when necessary and does not require you to create dummy controls and indicators that are just confusing since they are hidden from the operator.
0 Kudos
Message 23 of 35
(957 Views)

@R.Gibson wrote:
I believe a more correct analogy would be that the "returns" have a literal wire connecting them that is cluttering up the workspace, rather than an invisible 'pointer.' My issue is with the way the data is graphically connected between states (or functions, per the analogy), not the data itself. I feel that I shouldn't have to create and maintain wires for 'variables' in states that do not use those variables (ie. passing input to output shift registers and never using a single passed parameter within that state). When I use local variables, I do not need to worry about this...I use them where I need them, and omit them where they are not needed. Yes, it is up to me to ensure the data is not stale...but to me, that seems like good programming practice anyway...?

Simple scenario:

You have a case structure in a loop with 20 cases. in 10 cases, a certain "variable" needs to be modified and in 10 other cases another "variable" needs to be modified..

 

Solution 1: use a single shift register in the loop and linked tunnels across the case structure. The SR contains a cluster of two well labeled elements. Use the "in place element structure" to modify the desired element where needed (or unbundle/bundle by name if you only need to read or write). The name of the element documents the code nicely. All done.

 

Solution 2: Add 2x20 local variables, change half of them to read mode, and sprinkle them pairwise (read from local...modify...write to local) in all cases that need to modify it. Now repeat this for the other "variable". You have 40 local variables scattered all over various cases and tracking them down later, e.g. to modify the code is like herding cats.

 

I have a hard time understanding why you think that solution 2 is cleaner by any definition.

0 Kudos
Message 24 of 35
(946 Views)

I actually learned someting from this thread because I din't do it but will from now on.

 

Always look at the post date of the initial post!

0 Kudos
Message 25 of 35
(925 Views)

Altenbach,

 

Where every case (or many cases) in a state machine requires the same variable, I agree that solution 1 is a far better solution. My argument is that if I have 20 cases, and only 2 of them use that variable, the other 18 cases then have to have a pass-through wire for that variable even though they don't use it...that doesn't seem like intelligent design to me...but perhaps I'm still just not seeing it the way you are.

 

I appreciate the advice about bundling well-labeled clusters though, and will try it in the program that I am just starting and see how it works for me. Like you, I may decide that it is a far superior approach. I'm just not sure it is the perfect approach for EVERY situation...as I stated in the previous paragraph.

 

I will also dig a little deeper into linked tunnels and single process shared variables. Thank you for the references.

0 Kudos
Message 26 of 35
(920 Views)

@Viper wrote:

I actually learned someting from this thread because I din't do it but will from now on.

 

Always look at the post date of the initial post!


...not sure what you meant by that...? I did indicate in my OP that I was aware of the age of the thread.

 

...I typically try to search for similar issues before creating a new thread. Despite the age of the thread, it seemed appropriate to dig it back up.

0 Kudos
Message 27 of 35
(918 Views)

@R.Gibson wrote:

@Viper wrote:

I actually learned someting from this thread because I din't do it but will from now on.

 

Always look at the post date of the initial post!


...not sure what you meant by that...? I did indicate in my OP that I was aware of the age of the thread.

 

...I typically try to search for similar issues before creating a new thread. Despite the age of the thread, it seemed appropriate to dig it back up.


Yes but I didn't see that post untill I read the whole thread. I jumped in with a quick and dirty reply to the old OP that didn't address your resurection point.

 

Norm

0 Kudos
Message 28 of 35
(915 Views)

@R.Gibson wrote:

My argument is that if I have 20 cases, and only 2 of them use that variable, the other 18 cases then have to have a pass-through wire for that variable even though they don't use it.


As I said, linked input tunnels make all this completely painless. Having the unmodified wire across near the edge of the structure us not useless. It is a visual indication that tells the programmer that this particular value does not get modified in this particular case. This is very useful information and self-documenting.

 


@R.Gibson wrote:

...that doesn't seem like intelligent design to me...but perhaps I'm still just not seeing it the way you are..


You need to be careful bringing intelligent design into the discussion. It has very little nothing to do with intelligence, or LabVIEW. 😮

 

0 Kudos
Message 29 of 35
(909 Views)

Norm, gocha. No prob. 😉

 

Altenbech, LOL...pardon my faux pas. 😉

0 Kudos
Message 30 of 35
(892 Views)