Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
I often have a Case structure, where I have all the cases created, but they are empty. I start to work on a case, and to speed up the work, I would like to copy the same content to another case, for further modification. I know I can just use the "Duplicate Case" option, but in this way I have more extra steps to do: either typing in or copy/pasting in the selector label of the target case, plus I need to delete the original case (since in this way I will end up two cases with same selector labels).
If we had an option via right click: "Copy diagram to case", this would make all this just much faster and easier!
I have a project which compiles to 2 different executable for different hardware targets. I have created 2 Build Specifications which specify different locations for the build output. However, between compiling each one, I must go to the target options, and change a Conditional Disable Symbol definition so that the other .exe is generated. If the Build Specifications definition had a tab to specify the value of Conditional Disable Symbols, and which would take precedence over definitions in the project or the target options, then I could build my 2 executables without changing the target properties.
Is there any instance where it's good/ok to overlap objects? It should be prevented by LV. If you drop an object on top of another object it should move it as needed to prevent overlapping.
It'd be similar to the Auto grow, but would apply to all moved/placed objects.
More by chance than anything i noticed a strange look on one VI in an old project and after a short investigation it turned out there were 2 VI's on top of each other! One had no inputs connected and this could explain some behaviours we've seen before, as this results in a race condition where one uses the default values.
At some time this VI was probably moved with Ctrl pressed as part of cleaning up the diagram ... had this suggestion been in place it'd have placed itself to the side clearly showing there were two!
Would it be great to have free labview license that would allow to read VIs and save them to the previous version you have?
Immediate upgrade to new version does not happen in my case. I can not justify it for my boss, it adds a lot of work to upgrade all customers to new version, I hate idea of supporting multiple versions of code.
The main reason I need later version(s) is forum posts, other solutions that I would be able to open, save to the full one for real use. May be I will see the beauty of VIs in new versions and agree to upgrade 😃
I find I often have code where I want to access the property of a sub-class, which requires I chain property nodes. I would like the option to be able to access the properties of properties, like so:
Basic example, one level deep:
I understand some properties may have side-effects (like returning a newly opened reference that needs to be cleaned up), perhaps include an option on a given property whether or not sub-properties can be accessed this way.
Using single-frame-sequences is one (beside other) possibility to keep the code well structured and good readable: - clustering code in logical groups - defined place of description by using sub-diagram label - frame- and background colors - exclude from diagram cleanup option - moving the frame will move the code inside, too
But there is also two disadvantages: - clustering the code in sequences changes the execution order. Especially on high optimized and parallel code this can lead to unwanted performance loss - only code which follows the data flow can be placed within one frame
An alternative is the frame decoration element. But this is not grouping the code, it is just floating over the code. This has several disadvantages: - during diagram cleanup the frame will be moved to somewhere - moving the frame will not move the code - documentation ability - no background color
My idea / request:
The frame-decoration-element shall be extended by a visual code-clustering ability so that it has the same usability like a sequence but without an influence to the execution order. Additinally it shall be possible to place code inside, even if this does not follow the data flow.
The two images are showing the current situation - first with a decoration frame, second with a sequence.
I would love it if there were some way to understand from the block diagram what controls/indicators were connected to the connector pane of the (sub)VI vs which ones were just on the front panel (as constants or debugging information for the current (sub)VI.
I've come across too many different instances where with different coding styles I can't tell without several layers of following double-clicking of whether an item on the block diagram is connected to the connector pane or not. If there were some glyph or outline on the BD terminal it would be most helpful.
Let’s look at it another way, you have a Writer and a Reader and you have channel wires going from a Writer on the right of the block diagram to a Reader on the left. You really should have some way of looking at the channel wire and knowing immediately which end of the wire has the Writer. Curved marks on the channel wire only indicate where the Writer is located in the block diagram. See attached file which shows where every writer and reader is in the sub VIs of this complex block diagram without opening them.
I have just had my first look at some example VIs using channel wires and I have seen channel wires going from left to right and form right to left in the block diagram. It is my undestanding that best prorgaming practice in LabVIEW always has data wires running from left to right. The VI Analyzer actually checks for the occurance of backward wires. If the new best programing practice is going to allow channel wires to run from right to left then the channel wires should indicate the direction of data flow. My suggestion would be to use a chevron pattern on the channel wire, see attached file.
It would be really nice if the Flatten to JSON supported more LV data types. In particular, I find it very annoying that it doesn't support flattening a waveform to JSON since those are very common in most of the measurement APIs.
In the mean time, I have come up with this little work around, but it really seems like this is something that should be natively supported.
See image attachment. I often use array of clusters, there are arbitary number of fields to the cluster. Associating titles to the fields are a bit cumbersome. If I enable the label to the fields within the cluster, the title for every single element of such field within the array appears, which take up too much space. I wish label option for an element within an array only turn on one label and can be displayed at the top of the array. I wonder if anyone ever displays label to elements inside an array, since they are identical for every element.
I would like to see a new vi's suggested name contain the text that was placed in the icon.
Icons have four fields: Line 1 text, Line 2 text, Line 3 text, Line 4 text. Suppose the text in the icon is "parse" "new" "text" "file", I would propose that when saving a new vi instead of suggesting "untitled #.vi" it would suggest "Parse_New_Text_File.vi".
No text in the icon fields? no problem, stick with "untitled" in that case.
If I programm a VI with a statemachine pattern I have to use a type def control. This is stored in a seperate file on the disk. If I copy this VI to an other project I often forget to copy the control file. This often causes problems. It woluld be fantastic to have the opportunity to bond or integrate the control to/in the VI.
Wiring an enum to the selector of a case structure.is a very common activity. You facilitate this by having a function in the right click menu called "Add Case for Every Value", which is a nice feature I use frequently. Very often for enums, however, the contents of case statements is very similar between cases. Maybe one or two things are different between each case.
I propose you add a function that copies the contents (including the wire connection ports) of the selected case to other cases or all cases. If this were available, a base set of code could be made in one case and transferred to others and then modified as needed.
Working with multiple subVI is difficult to handle, and without using alt-tab it's bearly possible. But if we could slightly change the icon on taskbar depending on if this is FP or BD it could make it much easier!