LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Do Not Save Option

View All (1)

When debugging an xcontrol it is annoying to constantly go back to the xcontrol .xctl window and to unlock the library for editing by right clicking on the .xctl icon and selecting it from the drop down menu. I usually have lots of windows open for debugging and finding the control window, and then right clicking and selecting can get tiresome very quick. It would be nice if vis that were a member of the xcontrol had a button, perhaps next to the context menu button, that you could click on for unlocking the control for editing, and similarly the converse, applying the changes to all instances.

View All (7)

The current setup in Labview maintains the original spatial layout of front panel and back panel controls/indicators when copying and pasting to a new vi. Although this behavior might be useful for some, I would prefer that all controls/indicators be grouped together on copying and pasting, as I am going to rearrange them anyways, and I would prefer them to be closer together. To compromise, it would be nice to have a special paste option (not to just get rid of the current behavior) that would group the controls and indicators together with the copied code.

The first picture below shows the result of copying and pasting some code into a new vi. The back panel controls/indicators weren't too far from the code, however the front panel objects were very far away from each other as seen in the navigator window.

The second picture shows the result of the new pasting option. As a secondary point, having an option that would attempt to convert local variables to controls/indicators based on the current connection direction would also be useful. In this case the result of that operation would remove both local variables, and switch the direction of both the indicator and control.

CURRENT BEHAVIOR

BEHAVIOR WITH NEW PASTE OPTION

View All (4)

Remove Window Tile Feature

I sometimes find it easier to understand a block diagram if I colour the background:

Which got me thinking... what if I had something like this:

It is not immediately obvious to me the levels of the structures... so perhaps I should colour the levels progressively darker:

Now it looks like you have multiple layers of tinted glass stacked up, and gives it an almost 3D look! I can now immediately tell which structure is innermost.

I think the enviroment should have the ability to specify colours of structure depth:

What do you think?

View All (3)

Many-To-One Notification

None of the existing synchronization VIs work for "instantaneous" many-to-one notification, (or do they?)

Notifier is one-to-one or one-to-many,
Rendezvous is many-to-many
Occurances is one-to-many
Semaphore handles a different sync issue!

In many cases, one VI may need to wait for several other VIs before performing a task, simple example is on closing,

Even more specifically, other VIs could do the "notification" and continue, but the one VI must wait until those VIs have met (and passed) the "notification" point.

Although the mechanism can be built easily, it could be defined by NI as a standard VI.

Sia

Pointers in LabVIEW

When I need to pass a data from a loop to another I need to create an indicator and local variables which create copies in memory for each variables. So we have at least 3 copies in memory for the same data. One for the wire itself, one for the indicator and one for the local variable. Why there is no kind of pointers which LabVIEW could handle from under the hood with the wire's memory adress. Imagine something like that. Then we don't need to use a hidden indicator only for data passing.

This example doesn't look very clever but you can see what I mean.

XYZ Graph

View All (5)

It would be very useful to have a way of automatically create subvis when a single vi become too large. What we usually do is :

1. Select the portion we want ton encapsulate in a new vi.

2. ctrl-X.

3. Create new VI, save as, chose name, change icon.

4. ctrl-V.

5. Connect the front panel.

6. Add the new vi to the original diagram.

7. Connect the new vi.

8. Debug mistakes.

I think steps 2 to 8 could be automated with a single function (e.g. 'transmute selected code into a single vi'), saving a little time many times.

Case Tunel "Variant to Data"

I give an example to explain what I mean:

1.) Create a big array, eg 200x 200 x 200 3D-Array.

2.) Create a sub-VI with a 3D-Array input and output. Inside the VI, use the replace element function to replace one elemente of your choice.

3.) Connect the big array with your sub-VI and check the timing.

With LV8.5 I get about 200 ms for running the sub-VI. Checking the replace element function gets delta t of 0 ms! It looks like, that the output of the sub-VI has to allocate new memory for the array, even if I do not change the size of the array.

It would be cool, if I could create sub-VIs, which reuse pre-allocated memory for the inputs and outputs, therefore allowing a similiar effect as the inplace structure. As of how to configure this in LabVIEW you can be creative 😉 Perhaps do this with the conector pane.

Regards,

Marc

Installer creation for LV on Mac

I haven't checked out LV2009 on Mac yet, so please let me know if this has already changed.....

When creating an installer on Windows, we have control of everything within the Project. Cereate EXE, then create Installer with all options within the project.

On the Mac we have the options for the Application but not for the installer. I know (After I spent a day looking for products) that Apple has an installer packager which ships with the OS (On the developer CD) but why can't we automate this from within the Project shell? As it is I need to create the Application, then switch to an external program, create the installer (luckily it's relativel easy o use) and then to finish things off go to ANOTHER pogram to create the dmg file.

Please give the Mac the same Installer creation options as Windows.

Shane.

Sometimes I accidently click on the conditional terminal of a loop and accidently change its stop condition. Then I may need to look at the code to figure out which condition it is supposed to stop on. If that conditional terminal had a label, that label could be set by the programmer to say which state is desired and quickly ensure the proper state is set. This would also help someone else who came along and looked at the code.

I currently set the label for Boolean constants for this same reason.

enumerated typecast vi

Type casting from a number to an enum will use only the first (highest) n bytes that it needs to do the representation. In most cases I would argue this is contrary to what most people would expect to occur. To remedy this case, a casting needs to be done on the numeric input before hand so that for example, the number 1 goes to the enumerated value with a number 1.

My suggestion is to have a vi that is specifically designed for typecasting to an enumerated value. This vi would be free to cast the numeric input, so as to match the enumerated input. It could also take in an input string, and try to match the string to the strings values of the enumerated type. I could implement this myself, and might, however it seemed like it might be useful to have that in the same panel as the typecast so that one would be more inclined to use it than the typecast, for enumerated values, and subsequently avoid the problems that come with this unexpected behavior.

View All (3)

(This is a preemptive idea posting to make sure it is out there and does not get any significant votes.)

Don't vote for this!

(Now we will see who is paying attention :D)

The seasoned text programmer has problems adapting to LabVIEW because of dataflow. The concept where sections without data dependency can execute in any order really messes with the mind. We don't really want to think that way. It would be so much easier to do a literal translation of text based code to LabVIEW if we had a vertical stacked sequence!

Now order is restored, code executes "line" by "line", top to bottom, and all race conditions are eliminated. It also saves energy because we only use one CPU core at any given moment. Keep it green! 🙂 This structure is even Energy Star rated and might qualify for a rebate from your local utility!

Look at the picture! Now we have LabVIEW code that even a text programmer can understand. 😄

Look ma, no tunnels... no branched wires! 😮

Sounds good, right? Please discuss below and prove me wrong! (... and please remember the bold red text above!).

Did I mention that this is a bad idea? Oh, yes I did... In the title!

Create Bundle by name constant

The idea here is to have the option to create not just a constant when connecting to a property node or indicator, but instead to have an option to connect up a bundle by name with the constant connected to it. This would be invoked by the usual right click menu, but with extra options if a cluster is present. I'm not exactly sure how to handle the bundle or bundle by name, but as I am partial to the arrange horizontally arangement of a cluster, it might be nice to have the option to have the constant that is created be either horizontal or vertical, via different options in the selection menu.

View All (4)

LabVIEW Idea Exchange

Time Control and Indicator display option to ignore time zone.

Do Not Save Option

unlock library of xcontrol from member of the control

paste option to group copy/paste of variables to new vi

Remove Window Tile Feature

property nodes should accept arrays for the reference

Colour Differentiation of Structure Levels...

Many-To-One Notification

Pointers in LabVIEW

XYZ Graph

Automatically create new vi from selection

Case Tunel "Variant to Data"

Property Nodes Should use Enums

Default value of "Restrict references of this class type to member VIs of this class" should be FALSE

Allow the creation of "Inplace"-VIs

Installer creation for LV on Mac

Label for conditional terminal of loops to know its desired stop condition

enumerated typecast vi

VSS: Vertical Stacked Sequence (Bad idea, don't vote for it!!!)

Create Bundle by name constant