Where's the wire going?

[LHarris]

I have "inherited" a LabView program with a large main vi which has a number of wires that cross, split and merge or disappear behind various case structures/for loops etc, or even are positioned exactly on the borders of them, making it really hard to track which wire goes where. I have tried using the "clean up wire" function but this doesn't help in many cases.

Is there any easy way to either automatically find the terminals of a given wire, or to select the whole wire rather than just the current straight-line segment?

[Cat]

Is there any easy way to either automatically find the terminals of a given wire, or to select the whole wire rather than just the current straight-line segment?

Double-click on the wire and the entire thing will be highlighted.

[Tim_S]

Is there any easy way to either automatically find the terminals of a given wire, or to select the whole wire rather than just the current straight-line segment?

Double-clicking on a wire will select the whole segment. Tripple-clicking will select all of the wire.

Tim

[Cat]

I have "inherited" a LabView program with a large main vi which has a number of wires that cross, split and merge or disappear behind various case structures/for loops etc, or even are positioned exactly on the borders of them, making it really hard to track which wire goes where.

Oh and I feel your pain. BTDT...

BTW, if you don't already know, you can right-click on a subvi and select Visible->Terminals to really see where the wires are going.

[Grampa_of_Oliva_n_Eden]

Double-clicking on a wire will select the whole segment. Tripple-clicking will select all of the wire.

Tim

I asked that same question when I took LV basics I and the answer I got was "tripple-click". Outside of LV the "triple-click" is not used often in user interfaces so it is not something someone would just guess.

Ben

[Cat]

Outside of LV the "triple-click" is not used often in user interfaces so it is not something someone would just guess.

Yeah, I thought about that a second after hitting the "reply" button. But whenever I attempt to edit a post it either ends up looking all garbled or just blows up (IE6). Tim_S had already beaten me to it anyway.

[LHarris]

Thank you all - that'll save me a few hours. I guessed it had to be something simple, but I just wasn't finding it.

Oh and I feel your pain. BTDT...

BTW, if you don't already know, you can right-click on a subvi and select Visible->Terminals to really see where the wires are going.

Cool - thanks.

[LHarris]

Next newbie question - In some places there's a property node with miles of branching wires coming out to use the value in three or four different (faraway) places.

My immediate temptation is to copy the property node to the places it is used, and just have really short single wires for each one. As long as this is within one sequence so there is no chance of the value changing between different instances of the property node, is there any overhead or issues associated with splitting it up this way?

Or any stylistic reasons as to why one way is preferable to the other?

[Aristos Queue]

LabVIEW 2009 has the "Clean Up Diagram" button -- shortcut key is ctrl+u. It is designed to help solve inherited code problems like the one you describe.

Next newbie question - In some places there's a property node with miles of branching wires coming out to use the value in three or four different (faraway) places.

My immediate temptation is to copy the property node to the places it is used, and just have really short single wires for each one. As long as this is within one sequence so there is no chance of the value changing between different instances of the property node, is there any overhead or issues associated with splitting it up this way?

Or any stylistic reasons as to why one way is preferable to the other?

You do create performance overhead with the copies of the nodes. Each property read makes a copy of the data in the property. For many properties, like "height" for example, this isn't a big deal. But if it is something like "Value" and the value is a large array, you might be duplicating a significant amount of data. Also, every property node has to switch to the UI thread where as computations can be done in the VI execution threads. The more times you go back to the UI thread, the less LV's compiler can help improve performance because all the parallelism is lost to serialization in the UI thread.

In short, running a wire from the read of the property to all the places that need it is the most efficient and preferred solution. But if that diagram becomes completely unreadable as a result, sanity and code correctness are often worth more than a marginal performance improvement.

[Cat]

You do create performance overhead with the copies of the nodes. Each property read makes a copy of the data in the property. For many properties, like "height" for example, this isn't a big deal. But if it is something like "Value" and the value is a large array, you might be duplicating a significant amount of data.

But even if there's only one property node, every time the value out of it branches, isn't there a possibility (probability?) that a data copy is being made anyway, depending on how the value is being used?

Either way, AQ's last point about readability is an important one. With code this bad, a good intermediary step can be to put the property nodes right by where they are used so that you can get a better sense of program flow. Then, once you have it all cleaned up, take a step back and see if you can consolidate all those property nodes in a logical way. It is stylistically "better", and a good habit to get in to, since it's an absolute necessity if writing code where a particular value might be changed in between property node reads by some other part of the code.

[Grampa_of_Oliva_n_Eden]

But even if there's only one property node, every time the value out of it branches, isn't there a possibility (probability?) that a data copy is being made anyway, depending on how the value is being used?

Either way, AQ's last point about readability is an important one. With code this bad, a good intermediary step can be to put the property nodes right by where they are used so that you can get a better sense of program flow. Then, once you have it all cleaned up, take a step back and see if you can consolidate all those property nodes in a logical way. It is stylistically "better", and a good habit to get in to, since it's an absolute necessity if writing code where a particular value might be changed in between property node reads by some other part of the code.

In all cases except those that screamed "bug" LV will schedule all reads on that wire to happen prior to any operation that changes the data. Of course if the wire branches too two functions that mod the data, then we have the classic "Data copy on wire branch" situation.

The UI switch technicality is of particular concern if GUI update performance is an issue.

Another thought...

If those property reads are just looking at stuff the code already could have known (property set by code in the first place) then looking to the control for that info is a problem in itself.

Ben

[LHarris]

If those property reads are just looking at stuff the code already could have known (property set by code in the first place) then looking to the control for that info is a problem in itself.

Ben

So is there a way to just set the value into a code variable that is not something on the UI so it purely exists in the execution threads? I looked at Local Variables but they seem to be UI-objects as well. Or is a wire in effect the variable on the block diagram?

The Clean-up-selection is useful for some areas, but there are some tweaks I then want to make. Once I have a section 'clean' is there any way to lock it? I see I can mark structures to "Exclude from diagram clean-up" but these are not structures, just sets of icons performing one function.

Also, is there any way to change the color/look of a structure? I see that if you wire an error to a case structure you get red/green borders - it would be useful to do this sort of color-coding on other structures where I have error cases based on bools or variable values. It would also help distinguish the structure lines where I have cases within sequences within loops within sequences within cases.

[Grampa_of_Oliva_n_Eden]

So is there a way to just set the value into a code variable that is not something on the UI so it purely exists in the execution threads? I looked at Local Variables but they seem to be UI-objects as well. Or is a wire in effect the variable on the block diagram?

The Clean-up-selection is useful for some areas, but there are some tweaks I then want to make. Once I have a section 'clean' is there any way to lock it? I see I can mark structures to "Exclude from diagram clean-up" but these are not structures, just sets of icons performing one function.

Also, is there any way to change the color/look of a structure? I see that if you wire an error to a case structure you get red/green borders - it would be useful to do this sort of color-coding on other structures where I have error cases based on bools or variable values. It would also help distinguish the structure lines where I have cases within sequences within loops within sequences within cases.

"I think she's got it!" (Proffesor Higgen, My Fair Lady)

IN LV all variables live in wires (or shift registers).

I believe you can select code to exclude from the clean-up.

You can use the paint brush tool to color your code.

Ben

[Aristos Queue]

Or is a wire in effect the variable on the block diagram?

Exactly. For a "variable" to be thread safe, we have to know all the places that are going to use it. We (LV R&D) could create a named thingamajig that is usable only on the current diagram, and only allows a single writer but many readers, and thus get knowledge of all the places it is used, but the representation that is most effective for saying "this data, generated here, is used there, there, and there" is a wire which visually shows all its branches. The "local variable" is for communication back to the front panel.

The Clean-up-selection is useful for some areas, but there are some tweaks I then want to make. Once I have a section 'clean' is there any way to lock it? I see I can mark structures to "Exclude from diagram clean-up" but these are not structures, just sets of icons performing one function.

Throw a "Sequence Structure" around the section and lock that structure. Remove these structures when you're done cleaning the diagram.

Also, is there any way to change the color/look of a structure? I see that if you wire an error to a case structure you get red/green borders - it would be useful to do this sort of color-coding on other structures where I have error cases based on bools or variable values. It would also help distinguish the structure lines where I have cases within sequences within loops within sequences within cases.

Yes. Use "View>>Tools Palette" to show the tools palette and then select the paint brush tool to paint the background of structure nodes. When you're done, click on the green LED to turn the autotool back on so you can continue doing selection, wiring, etc. There are some other specialized tools in that palette for other less common actions.

[LHarris]

You can use the paint brush tool to color your code.

Ben

Paint brush? Oh, _that_ paint brush

Thanks

[Yair]

Yes. Use "View>>Tools Palette" to show the tools palette and then select the paint brush tool to paint the background of structure nodes. When you're done, click on the green LED to turn the autotool back on so you can continue doing selection, wiring, etc.

Or Shift + right click in an empty area to bring up the palette and Shift + Tab to go back to the auto-tool.