I couldn't find a similar topic so sorry if it's already been asked
When adding an VI into a loop, container or select case, I do always trying to reverse-wire the inputs like the error input.
Unfortunately, LV will not recognize the datatype, if you connect an input from the input to somewhere else.
It's always needed to create the element (constant, front panel element) inside of the loop, move it out, and reconnect.
So it'd be great if you could simply connect the wire to the loop entry and then create there the element.
The updated diagram expansion (Ctrl+Drag) and its new counterpart (Ctrl+Alt+Drag) is a definite improvement in 2015.
However, they still both act globally on the diagram:
Shrink and obtain this:
All the objects outside of the case structure have been moved around because the shrinking action acted on the whole diagram, whereas my intent was to only compactify things inside the structure.
It would seem that the next step to improve the functionality of these tools is to allow the user to define their scope:
- define a region of interest meaning: DO NOT CHANGE ANYTHING OUTSIDE THIS ROI
- perform the action (expansion or shrinking)
In this particular case, this would work like this:
There is still some cleanup to do, but this is much less of a pain that fixing the carpet bomb effect of the current approach.
Arguably, this is easier to grasp with the "shrink" tool, but just think of the exact inverse series of steps to get an idea of the difference between the image at the top and this (the result of the current expand):
LabVIEW needs native SSL/TLS support for the TCP primitives. The HTTP functions support it (see \vi.lib\httpClient\ConfigSSL.vi). There are several great LabVIEW native MQTT libraries that could be commercially usable if there was native SSL/TLS support. Not having this functionality for the TCP primitives makes LabVIEW a poor choice for an IoT platform.
When we have multiple Enum values using a same case it is difficult to see what are the values using it. It would be good if we have a Tip strip showing the values handled in that particular case would be more meaningful instead of having "Selector Value" as a tip strip.
There is also an idea on removing the tip strip totally and it got fair response.
Please ignore if already suggested!
We often use multiple instrument APIs in parallel (with occasional sync points). It would be nice if diagram cleanup could recognize that and not interweave them.
Here's a quick and dirty merging of examples from Switch, DC Power, and DMM to illustrate:
Each API is aligned on its own horizontal line. The error cluster is used for sequencing.
This could benefit from some automated squeezing. However, Diagram Cleanup flattens it to a more compact, but argueably less readable form:
If track assignment wasn’t automatic (maybe using the instrument descriptor line), perhaps the user could ctrl-click a set of Vis and assign to a track (track 1 for Switch; track 2 for NI-DCPower; etc.). Then diagram cleanup would place each track on a different horizontal line. If you click and drag a member of an assigned track, the whole track slides up and down together (along with dedicated constants, controls, indicators, etc.), maintaining relative positions.
We spend a lot of time manually wiring our diagrams to keep the APIs in separate tracks. Diagram cleanup is awesome for small pieces or API-homogenous Vis. If it could keep multi-API Vis clean, it would make our code development and documentation more efficient.
Changing the connector pane of a subVI requires relinking to the subVI in all callers. Until we relink (right-click...), the subVI is bleached and the caller broken.
When refactoring old code, subVIs often contain odd connector panes and one might want to change to a more typical pattern (e.g. 4-2-2-4), and reassign connectors to established policies (e.g. error in/out at the bottom corners). Also, sometimes there was poor planning and we need just one more connector terminal.
Currently, relinking to a subVI clears all "subVI node setup" settings. This is unexpected and I suggest that these settings are retained instead.
I was working on some very old code (originally from LabVIEW 4.0 ), and there was a single instance of an interactive subVI that was set to show the front panel when called and close afterwards ((in the subVI node setup of the caller, not in the VI itself). This subVI was interactive and required user interaction to complete. It had some odd connector pane (four horizontal terminals all the way across the icon, top as input and botton as output) and I wanted to change it to the standard 4-2-2-4 pattern. After changing the pattern, I did some switcheroo on the connectors, correctly rewired in the caller, rebuilt the app and deployed it to the PC controlling an instrument. (I could not test run locally because it required the presence of the instrument)
Bam! Triggering the subVI call no longer showed the front panel and since the caller required the subVI to return before continuing, everything was locked up. I had to kill the build executable via task manager. Now the guessing game started, trying to figure out why the app would lock up. Since I also did a few minor changes elsewhere, It took me a while before realizing that I should maybe look at the "subVI node setup". Sure enough, all settings were cleared. These settings were retained during 20 years of version upgrades and I did not expect them to change behind he scene and without warning .
Anyone can easily verify that relinking to a subVI will clear all settings in the subVI node setup. Would anyone expect that? Probably not!
Relinking to a subVI should retain the existing "subVI node setup" settings.
The existing settings are most likely also appropriate after the connector pattern has changed. This is the expected bahavior. There is no reason to clear these settings. Thanks for your votes!
The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.
We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)
I would like to request a feature that allows us to easily and permanently remove any entry in the list.
(...maybe it could even show for pinned entries?)
IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.
It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.
These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.
Strict typedefs and non-strict typedefs differ significantly. There's too much of a gap for me. Sometimes I'd love a control to be somewhere in between.
There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.
It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked. That way we could shoose to long only boolean text, width or colour but leave the other properties free. VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.
So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.
After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go.
We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time.
So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk.
Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.)
In summary, there should be a menu entry that ignores indicators when making values the default.
It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.
With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.
For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.
For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.
[admin edit: Adding animation image at the request of the OP]
Make it easier to find the right product in the uninstaller
If you install a lot of National Instruments developer tools the uninstaller becomes very crowded. You can have 50-100 components, often with similar names and varying name structure. Finding the component you want to uninstall/modify/repair can be difficult.
The fact that things a split into so many separate components is practical, but the components should be organized better:
They could be:
Allow us to specify a new source location
If I want to repair or modify an installation it might turn out that the original source for the installation is gone, or I have a new (identical/compatible) source that I would like to use instead. It would be nice if the uninstaller handled this, instead of insisting on the original.
The Open/Create/Replace file I/O primitive is pretty powerful. It will check to see if the file is there for you, and, if not, create a new one. I use the "Open or Create" option often when generating multiple delimited text files in long term tests. When a new file is created, I need know so I can add a header, and I need to skip the header operation if the file is being appended. Sure, I could check to see if the file exists before trying to open it, but then wouldn't that just make the power of the Open/Replace/Create function redundant? Some operation took place based on my input to the "operation" terminal, and whether or not the file exists. Unfortunately, I have no idea what that operation was, because the function doesn't tell me. Let me know if the Open/Create/Replace function created a new file so I can add my header.
This is not without precedent. For example, the "Obtain Queue" primitive has an option to create a new queue if a queue of the given name is not found. It let's you know if the new queue was created:
The title says it!
It is often confusing "Which is the opposite end in a queue?/What does opposite end mean?", esp for new user of LabVIEW.
Seems here, even the author of the LV Queue primitives was not able to recollect its name correctly.
Also, please see below from the LV Help.
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
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.
Thanks for listening!
Currently, the only object that we have access to in an Event Structure it the control itself:
This is not what I am interested in, most of the case, when I am working on the BD.
Rather, I'd like to either find the terminal, or local variables, references, etc.
Moreover, going to the control using the above shortcut may result in a messed up FP, not mentioning cases like this:
where the control may be hidden or invisible because it is in another tab than the one currently selected.
Now, I know that some will argue that the control terminal is most of the time in the event structure (see for instance this thread)...
But read the thread's comments for counter arguments: we would be talking about the Value Change event, but this is not what I am talking aboutin general: any event for that control should give access to the control's terminal (and BTW, it could very well be an indicator) and, as for a terminal, to this list of related objects:
(The last one courtesy of this shortcut plugin)
There should be an option to fully enable optimization when building an application as to automatically remove performance impacts caused by diagram elements that shouldn't cause any.
As summarily declined by NI, this idea
shows that unless you manually go over ALL your VIs disabling debugging, Diagram Disables (that are supposed to not avoid executing some code!) you'll suffer a performance impact.
It is preposterous to expect the users to manually disable/reenable debugging on every single VI when building an application.
Please add an option to enable full optimization.