I really like having two different default locations for my terminal labels. What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control. I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed.
You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved. And I am not interested in the Quick Drop shortcut here. I do not want a quick way to clean up the mess I do not want the mess made in the first place.
When using extensive numbers of property and invoke nodes (for example, using the TestStand API) it's very common to end up with many references that need to be closed. This leads to structures like this:
It would be very convenient if we had a Compound Close References node that we could wire multiple references into. Since order often matters with closing references, the node could execute top-down once all references are available at the inputs. This would substantially clean up block diagrams and make API code a bit easier to follow. For example, the above code could just be replaced with:
Currently, the markers of intensity graphs are left-aligned with the intensity pixels. This is most noticable when graphing small arrays, but is a general problem. Have a look at the left picture (x0 and dx are at the default). There is one too many markers on each axis and it is errorprone to read out the coordinates of a certain pixel because it is always betwen two adjacent markers.
(If we graph a 1D array with 10 elements on a plain graph with the same size (loose fit off), the axis will go from 0..9. It is misleading to show another marker at 10 in the case of the intensity graph!)
Correct would be to center the axis markers on the pixels as simulated in the image on the right. Now the limits are correct!
The problem is even more severe with cursors locked to the plot. The cursors align with the markers and thus fall right between four adjacent pixels (left) while they should be smack dab in the middle of exactly one (right). Currently, we have a 25% chance of picking the right pixel with a cursor unless we are very carefully!
Idea summary: The markers of intensity graphs need to be centered on the graph pixels. Same for cursors.
(...of course the same applies to intensity charts and similar)
Not so much an idea, as a wish/plead/rant:
Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.
2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right! Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).
I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:
Graphs and charts
1. You cannot stack plots in any of the graph indicators, only in charts
2. Number of plots stacked cannot be varied at run-time
3. Annotation properties are only partially available programmatically
4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way
5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample...
6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues
7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible
8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming
9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...
1. You cannot set the group names programmatically
2. The number of plot areas is not configurable at run-time
3. You cannot assign plots to a given group programmatically
4. You cannot show the visibility checkbox of each plot etc.
And then you have the additional 2000 ideas...;-)
As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.
Would that not make everyone's day?
If you have a local variable and you either rename it's control/indicator, or you click it to change it to refer to a different variable, all local instances resize based on a centre justified behaviour, which can have undesireable layout issues.
For example here is a what happens when it's made longer next to the bounds of a case structure.
(The Boolean is provided to show how it's aligned, and also to show it resized the case structure).
If the local variable were Left justified as a 'Write' type (expands to the right when changed) or Right justified when a 'Read' type (expands to the left when changed) it wouldn't make such a mess of things!
tl;dr There's a summary at the bottom if this is too long for you.
Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.
What I don't like about QD, however, is the keyboard shortcuts. These allow you to perform custom actions in LV and the concept itself is great, but the implementation QD uses has some issues which other similar tools like the right-click framework and LabVIEW Speak don't have, such as the items in the following list.
So, what can we do about it?
I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:
There are a few things to point out in this image:
OK, so that's step one and it solves the first issue - the actions are discoverable, accessible and not limited in number.
Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:
This area shows the details of the currently selected action and allows selecting options for it.
Here's what we see in this example:
The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.
Of course, once we have this panel, the next logical step is to also have it show the help for standard items, similar to this idea:
So, to sum up:
I have an evolutionary project which has many VIs and CTLs on disk which are no longer called by the project.
It would be fantastic if there were an option in the project manager to highlight or list files which are in the project but which were not called by any other component of the project.
For my application, for example, there would only be one single top-level VI and any other "parentless" VIs should be deleted from the project (or, even better, they could optionally be deleted from the filesystem).
One might even be able to compare all the components in a project with all the components in a given directory structure and highlight the differences such that unused files could be removed.
The discovery of Auto-populating Virtual Folders in the project manager was fantastic, in that I no longer had to file my VIs in the file structure AND the project, but and extension to this might be the ability to highlight files which are not called by any other VI in the project.
I'm developing code, and like most people I know, I have multiple VI's open at once.
If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption. I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog.
I scroll through the sub-diagrams with "CTRL+mouse wheel",
The problem is that the selector label is no longer visible.
The selector label should always be in the middle of the visible part of the Case structure.
I've often produced VIs with non-array controls and indicators only to find that by changing them to arrays I can increase the power and functionality of my VI. When this happens you have to create the array element, drop in your control and then if it is connected to a VI input or output pin, rewire the pin.
What would be nice is to simply have the Add Dimension capability available for a non-array control to instantly convert it to an array and conversely the Remove Dimension to convert a 1D array control back to a non-arrayed control.
When a build is in progress (Application Developer or FPGA*), the entire LabVIEW IDE is blocked.
Since some builds can take a long time, it would be far more productive if users could continue working in parallel with the build. Example use cases:
To prevent accidents, LabVIEW could reserve all the VIs/libraries that are part of the Build Specification:
*At least the FPGA build only blocks at the preparation stage, but that takes a while too.
The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.
Yes, you can make custom probes for this behavior. But it should be native.
I tried searching for a similar suggestion but couldn't find one but I would bet that this has been suggested several times.
Why is the routing to multiple adjacent array terminals (or similar) so terrible ? The top Build Array shows the standard routing chosen by LV when wiring from a group of refs starting at the top. Starting from the bottom isn't any better. The lower Build Array is what I always change it to !! Why is this not the standard routing ?
I'm sure all of you VI meisters with OCD can sympathise.
Hi there is a cool addition to LabVIEW 2013, it's now possible to open a VI Clone of a reentrant VI with this menu:
But it's not possible to get this list by VI server.
In the past Version of LabVIEW the Clone number start with :1 so that way it was possible to guess the Clone name and get reference on it. As you can see the number is now very big so there is no more way to guess the clone name and get reference on it.
I have a tool that depend on this capability of retrieving the list of cone in memory but since the old way don't work anymore, I have to find an other way.
So I propose to add a Property in the VI Class that return the List of Clone In Memory of the specified VI.
The Message Box from LabVIEW doesn't look very nice. On Windows Systems user32.dll provide a better Message Box.
See also MSDN entry at: http://msdn.microsoft.com/en-us/library/windows/de
It is possible to set the Buttons
and many more ....
LabVIEW should support this MessageBox on Windows Systems as additional MessageBox beside the existing.
Three graphs contain the word "waveform":
(... and equivalent graphs in the classic and silver palettes )
This is misleading because these don't just work with waveforms, but with a rich selection of other datatypes. Then the word "waveform" is very long and the default label invariably gets in the way of structure borders and other code elements.
I suggest to drop the word "waveform" from all graph types that contain it. Now we simply end up with the following labels:
(... and equivalent changes in the silver palette.)
Ahh, so much more concise and compact!!! I feel better already!
Idea Summary: Drop the word "waveform" from the default label of all graph types that contain it.
Thanks for your support!
The shortcut menu should launch the new type def.'s front panel when 'Make Type Def.' is selected. You will need to save it anyway, and if you find the need to edit it right away, then it is already open and ready to go.
I want to start discussion about how to enhance Loop Conditional Terminals in LabVIEW. Generally my idea is to have an easy way how to monitor Conditional Terminal of user-defined "primary" loop. Under the hood there can be for instance notification triggered from the "primary" loop and one or more "slave" loop(s) equipped with "Wait for notification" (with timeout = 0) with predefined logical operation on the terminal input.
So this allows you to have one STOP source loop and one or more listeners.
Anyone wants to expand this idea?
I started a discussion here
Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project. I never use the default icon provided by NI. -- N-E-V-E-R -- That's a personal choice.
So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless. Let's see how many users of LabVIEW also find the default icon useless.... (Kudos would be a way to take a poll).
A nice feature would be to allow the developer to create her / her own default icon. The default icon is probably somewhere in the ini file (I have not checked). One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.
In my case, when creating a new VI, it ends up with a icon like this:
I would be happy to have a default icon that looks like this:
The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.
And may plenty of kudos adorn this thread..