Yup, Upgrading LabVIEW versions takes a day.
The "Process" today is:
Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......
"MyLabVIEW" would find all of those customizations and import them to the new version!
If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.
Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.
The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.
This is a rather non-technical request. When classes are created from Project Explorer, a color is assigned by default. If that's a color you're fine with, you hastily modify the icon and move on to more important matters.
While the color assignment works well enough to serve its mundane purpose, I've noticed several weaknesses:
My suggestion is this, and maybe there's a better way to do this:
In the class properties dialog, why not allow the user to simultaneously assign a color scheme to the icon and the class private data ("cube") icon, in one quick step?
This would adjust the hue of the "cube" icon and the VI Icon Template at the same time. It could also optionally modify the wire color accordingly.
Leave everything else on the UI as it is - this would be a new feature in addition to that pre-existing methodogy.
Thank you as always,
Note: For the sake of simplicity I chose the color picker dialog that LabVIEW uses everywhere else. Any of several other methods could be used, such as a pulldown menu with predefined color names and swatches. (Say, a dozen selections)
Related ideas I came across:
While some ideas like this suggest that we should be able to open block diagrams without opening the front panels, and others suggest that we let go of the front panel as the primary part of a vi, the front panels will probably be around for quite some while yet. But the block diagram is where we primarily work, and closing a vi requires clicks on two different windows. Using ctrl+w twice is not working since the second last window is not always the FP (if it's your very large project this may be annoying).
Let us have the possibility to close the entire vi including FP from the BD by ctrl+click the panel close 'x'. Similarly, remap ctrl+shift+w to close the entire vi.
The LabVIEW menu has two entries with somewhat overlapping functionality that can lead to confusion
(1) "New..." let's us create many new things, from a blank VI to complicated design patterns and project templates.
(2) "Create Project ..." lets us create a new project using a wizard.
Since the results of menu (2) is invariably something "new" too, it seems odd to have things scattered across two different menu items. I think the "New..." dialog should simply add all the "create project" items under the "project" category. (e.g. "new project using a wizard" or similar.).
(Case in point: I recently attended a myRIO hands-on seminar and was looking for the myRIO template wizard in the "New...." dialog by accident. While there were some other myRIO related projects listed, I could not find what I needed until I looked in the "Create Project..." area. Very confusing!)
What I'm asking for is an optional indication of reentrancy in the context help window.
This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.
I realize that Greg Freeman suggested something similar. My intent here is to narrow down several ideas from that conversation down to a single suggestion.
(I hope I still didn't manage to post a duplicate. Apologies if I did.)
I find myself making a lot of VIPM packages for code re-use. As we re-use more code we increasingly want to protect the code so that we can more freely share such packages with e.g. sub-contractors/licensed users without sharing the block diagram. (and the first person to suggest we use VI password protection gets to wear the donkey ears for the rest of the year.)
When you remove the block diagram from a VI, you also remove the ability for that VI to recompile which means that it can only run on the same version of LabVIEW and on the same hardware as it was compiled on/for. This makes it a giant pita if you have code that is used (and works) equvally well on e.g. vxWORKS cRIO and "Windows". Currently VI's consist of 4 parts (Front panel, block diagram, code and data) and without the block diagram, the code section cannot be recompiled.
I wonder, if it would be possible to extend this to either allow the "code" section of the file to be essentially an "array" or at the very least let there be two "code" sections? -It would tremendously increase the usability of the "remove block diagram" feature if we didn't need to maintain a copy for each hardware platform.
I'm not sure how technically possible this would be, but since deployed code (at least to RT) typically gets compiled into (rt)exe's the extra and un-used code section(s) could be stripped during exe build, and the slight performance hit during development/debugging runs that might come from this along with larger VI size seems to me to be a decent trade-off.
So my suggestion is to investigate this and if possible allow some extra choices during the "strip block diagram" from VI process where you get to select an extra "target platform" or two.
A much less savy alternative would be to modify the existing tool to automatically pre-fix and output multiple "versions" of the same code distribution, one for each selected target platform. This would at least speed up the process of maintaining and creating all the variations.
I suggest adding a jog-wheel (unlimited range knob) to the palettes:
The current knob you set the minimum and maximum range, and can then select inbetween those values by turning the knob from one endpoint to the other.
A jog-wheel you configure with only the range for one complete revolution of the knob, but you will then be able to turn it as many revolutions as you wish and it'll continue to increase or decrease its value (depending on if you turn it CW or CCW). This'll work like the jog-wheel on a video-player; configure it for a range of 10/revolution for instance, if you then want to move 30 upwards, you just turn the knob three full revolutions CW. It should support the mouse scroll wheel on top of it of course, for "quick jogging".
Would it make sense for the "Save All (This Project)" menu option to appear on all VIs that are members of a project? Obviously it's on the Project Explorer window, but it's not on the VI panel or diagram windows.
I noticed that I frequently (subconsciously) select "Save All" from a VI's panel or diagram, only to get warnings that another project I have open is read only due to source control. Sometimes my Project Explorer window is buried under several other windows, and it's nice to be able to quickly save the whole project.
If I've missed something obvious or there's a good reason for this feature not to exist, I'm all ears.
I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.
As mentioned above, LabVIEW should add an Options>>Block Diagram or Environment setting of "Name Format" for property nodes. Currently you start off with short names (default) or whatever the previous designer of the VI set as the name format of a specific property node. This can lead to confusion if you are used to seeing it one way or the other; and it can be annoying if you want to change the name format of all property nodes in a VI.
LabVIEW should have four options to select as default.
Listed below is an example of the different "Name Format"s of the same property node.
This should be an item in Options as shown below.
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
Connecting to remote panels using LabVIEW is difficult if private networks, local private and external public IPs (under NAT), and firewalls, etc. are involved. It requires significant knowledge as well as external networking configurations (port forwarding, etc.), and possibly admin privileges to modify those.
There are plenty of companies that have found a way around all this. The prime example is chrome remote desktop, which seamlessly works even if target computers are in hidden locations on private networks, as long as each machine can access the internet with an outgoing UDP connection. The way I understand it, each computer registers with the Google server, which in turn patches the two outgoing connections together in a way that both will communicate directly afterwards. All traffic tunnels inside the plain Google chat protocol (udp based). Similar mechanisms have been developed for security systems (example) and many more.
Since the bulk of the traffic is directly between the endpoints, the traffic load on the external connection management server is very minimal. It simply keeps an updated list of active nodes and handles the patching if requested.
I envision a very similar mechanism where LabVIEW users can associate all their applications and distributed computers with a given user ID (e.g. ni profile), and, at all times be able to get a list of all currently running remote systems published under that user ID. If we want to connect to one of them, the connection server would patch things together without the need of any networking configuration. Optionally, users could publish any given panel under a public key, that can be distributed to allow public connections by any other LabVIEW user.
This is a very general idea. Details of the best implementation would need to be worked out. Thanks for voting!
Currently we have File >> Save then File >> Apply Changes.
I would like save and apply changes for typedefs in one operation. So either replace Apply Changes with Save and Apply Changes or add this as another option to the menu.
The error ring is a handy tool I've just learned about. It would be fantastic to be able to create an error ring for a project that can be type defined to easily distribute with applications. This way all custom error codes for a project may be easily stored with all the project files without having to worry about including a file from the user.lib. Other ring controls/constants/indicators can be type defined, why can't the error ring?
Whenever I place a Bundle By Name (or Unbundle By Name) function on the block diagram, it is configured to Show Full Names. But while creating the cluster, I provide descriptive names to each element and so I want that every time when I place the Bundle By Name (or Unbundle By Name) function on the block diagram, by default it must be configured as Hide Full Names.
I know, my wish is not what everybody else wants to have, so better solution to this could be a selectable option (perhaps categorized in Environment setting).
I really like the new arrow feature with block diagram comments. But in many cases, I have a comment that applies to more than one BD object. So, I would like the ability to link my comment to multiple objects instead of just one.
This would allow me to turn this:
I use Unflatten from string (UFS) a lot. Most of the the flattened data, however, comes from outside LV and as such does not use an I32 to encode the length of strings and arrays. That leads to a lot of branching and bending of wires.
I would like to make the boolean input (Includes length?) polymorphic to accept numeric types to specify the number of elements in an array or the length of a string. I was too lazy to draw it, but I would also like it to promote the type input to an array if the count is wired so I only need a simple scalar constant to specify the type instead of the array constant (think Read from Binary File without the cluster of array business). Allowing a cluster of N numerics to specify ND arrays would be very welcome and permit compile time error checking. 1D arrays for dimension sizes could work as well, but the error checking would be runtime only.
I desperately want the boolean input to be overloaded since it is a straight shot from the output of the previous UFS.
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?