LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Unlike the scales of numeric controls, graph scales don't support text labels (wouldn't that be cool! :smileywink: ) *(see footnote)

 

It could be handled very similar to the way text labels are handled for the scales of numeric controls, so most of the code is already there.

 

This would come in very handy for e.g. histograms or bar graphs, where each bar needs a text label, or for cases where we have arbitrary units.

 

Examples for integer scales: 

  • "January", "February", ...
  • "LabVIEW users", "CVI Users" ...
  • "Europe", "Asia", ...

 

Examples for floating point scales (x, or y):

  • "Too cold", "cold", "warm", "hot", "too hot"...
  • "small", "medium", "large", ...
  • "min", "max"...
  • "high frequrency", "low frequency"...

 

*My quote from this old discussion . See also Ben's example further down.

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:

 

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

tools palette buttons in the toolbar.png

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

It would be useful if QuickDrop supported a way of dropping multiple instances of the same item in one go. It is sometimes desirable to do so. For example, we may want to drop three numeric constants in one go.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The QuickDrop action above would result in three numeric constants being dropped, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

Selecting an error wire, then executing the sequence: Ctrl+Space >> typing "rn" >> increasing the Number of Items to x3 >> Ctrl+I would result in three property nodes being inserted into the error wire, as seen below.

4 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It would be great if the multiplier could be typed as part of the QuickDrop search string. For example, typing "rn x3" or "x3 rn" would then drop or insert three property nodes. This would mean that the whole action can be done from the keyboard, which would be quicker. However, it seems difficult to implement due to the search string needing to be intelligently split into two parts.
  • Perhaps a much easier implementation that would be almost as quick would be to type "rn" >> press Tab (this would tab to the "Number of Instances" control) >> type "3".

 

Thanks

The array "Startup/Always Included" carries these Vi's into pre/post build action VI's.

The order of the vi's in this array depends on the order they have been added to/created in the project when, not the order they can be seen on the project window itself.

Here's the project window:

GICSAGM_0-1718176051948.png

Here's the order within prebuild vi:

GICSAGM_1-1718176157393.png

 

The order is NOT the same. "startup" is the first but if you delete from the project and then re-add it, it will become the last.

 

I suggest that the order in pre/post build VI should be:

first - startup.vi

following: always included vi's in the same order they appear in the project window.

 

Also, the always included list should have a 'mechanism' to change the order of the vi's in the list - be it up/down arrow buttons on the side that would move the selected vi or a similar command in a "right click" drop down menu.

 

In this way, any pre/post build action that may involve any of these vi's can be clearly defined and remain stable during the lifetime of the project without running into the risk of getting the wrong vi to "work" on or having to edit the pre/post build vi to add or edit the vi's names every time there is a change in the startup/always included list.

 

I think it would be a good idea to enable running code formatter, like Darren's Nattify VI, automatically when saving a VI. Currently, most IDEs have built-in formatting tools which promote a unified, clean code style, and programmers don't have to worry about it because the code is automatically cleaned up before saving. I think a similar function would be a great addition to LabVIEW.

 

In Visual Studio it is called "Run Code Cleanup profile on Save". You can also configure different profiles (different styles or flavors). This option would be nice to have.

 

It would be great if it were possible to reduce the amount of time spent cleaning up LabVIEW code while keeping the code in decent visual condition.

TL;DR: the idea is please make building as fast in new LabVIEWs post 2023 Q3 as old ones when you have a clear compiled object cache and when your file timestamps have changed.

 

LabVIEW 2023 Q3 includes a major change to the app builder: 

 

LabVIEW 2023 Q3 has improved cache behavior for packed project libraries and applications.

 

The first build will populate the cache, and then the subsequent builds will be much faster.

Great! It is pretty easy to confirm this and it works! Unless...

 

1. File timestamps change - such as when you clean a directory and clone project files in your CI job

  • Git does not make file timestamps match "commit date" - when you clone fresh all the timestamps are now o'clock, when you change branches all the files that change are reset to now

2. The cache is cleared prior to the build - such as when you want a repeatable build unaffected by prior state so you set your CI jobs to clear it before each build

3. You are doing a "first build" on a new project - such as when you use a container or VM disk image to reset the entire environment to a clean state prior to your CI job

 

In all my testing, any of these conditions pretty strictly cause builds to be slower in LabVIEW 2023 Q3 than in earlier versions: with a clear cache by typically ~60%, with new timestamps and a persisted cache depends on how much of the code has new timestamps.

 

In other words, I expect most everyone using CI will find building slower in 2023 Q3+ than later versions. So, the idea is: whatever optimizations were done, include an option to revert to the old behavior - build spec, config ini, editor option, whatever.

The Search Results window should contain a “Remove” button. When the button is pressed, the selected item(s) would be "removed and rewired" using the exact same implementation that operates behind the QuickDrop Ctrl + R shortcut. This functionality would be useful when refactoring codebases. Currently the quickest way to remove and rewire n instances of a subVI is to navigate to each instance (perhaps using Search Results Ctrl + G) and perform the QuickDrop Ctrl + R shortcut on each instance. The "Remove" button would enable n instances to be removed in a single bulk operation.

 

Combined.png

 

 

When I connect something to the output of a Select node, I would like the input types to be updated to the connected output type.

For example, if I connect an enum to the output of my select node - if I "create constants" on the inputs, it should create the same enum type instead of a double. Similarly, when I connect a string to the output, I would expect the inputs to be strings as well.

If there is a conflict with the compiler, perhaps it could use whatever was connected first (input or output).

When hovering over Typedef / Custom Control (*.ctl) in the Project Manager, the Context Help only shows the Icon and ev. a custom VI Description.

It would be very helpful if the Information and the wire pane image of the contained Control was also shown in the Context Help of the Typedef.

 

codelux_1-1673360690644.png

codelux_2-1673360796469.png

 

This improvement would reduce the needed effort to write VI Description or avoid opening several Typedefs until the right one is found.

So the request here is to have an option wherein the array indicators (or controls) can be linked with another array indicator (or control) and can be scrolled synchronously.

 

There could be a property node for that (or invoke node or may be some other way), which will accept the reference of another array and thats all.

 

Sync Scroll

In above example, Array 1 is linked with Array 2, so whenever the user will scroll (or change the index of Array 2, the same change will reflect in Array 1.

The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

 code example.jpg

 

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported.  For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

 

code example2.jpg 

 

The Find Items With No Callers dialog box in Project could use a Remove From Project feature. Currenly, we have to use Go To, then remove the VI, then generate a new  Find Items With No Callers list.

 

remove_from_project.png

Allow the user to right-click a given test result on the Results Window called "Retest", which re-runs the selected test, and if the test now passes where it previously failed, it clears it from the Results Window.

 

Start with this:

Ozfarmboy_0-1654068733860.png

 

Right click on the selection, and select "Retest":

 

Ozfarmboy_1-1654068909415.png

 

The VI Analyzer just retests the selected tests.  And then once complete, it returns to the VI Analyzer Results Window, with the selected tests cleared from the list (assuming they passed):

Ozfarmboy_2-1654069263041.png

 

 

If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.

 

idea1.png

 

Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂

There is a strange asymmetry in the conversion pallet:

heel_1-1628866756838.png

 

I cant see any reason why it is not supported to use the type conversion on an array of FXP when it is on an element. It should be either none or both.

 

Have VI in the project windows behave like SubVI so when you CTRL + Double Click on one the SubVI FP and BD opens (and the BD is frontmost).

(This is different and less controversional than  this related old idea)

 

Arrays of timestamps only contain legal values and can even be sorted. We can use "search 1D array" to find a matching timestamp just fine.

 

As with DBLs, there might be a very close array value that is a few LSBs off, but well within the error of the experiment so it is sufficient to find the closest value. We can always test later if that value is close enough for what we need or if "not found" would be a better result.

 

If we have a sorted input array, the easiest solution is "threshold 1D array" giving us a fractional index of a linearly interpolated value. For some unknown reason, timestamps are not allowed for the inputs, limiting the usefulness of the tool. One possible workaround is to convert to DBLs, with the disadvantage that quite a few bits are dropped (timestamp: 128 bits, DBL: 64bits).

 

Similarly, "Interpolate 1D array" also does not allow timestamp inputs. In both cases, there is an obvious and unique result that is IMHO in no way confusing or controversial.

 

 

 

IDEA Summary: "Threshold 1D Array" and "Interpolate 1D Array" should work with timestamps.