After installing a few word processing and graphics editing programs, my font list in LabVIEW is about 6 screens long and all I see without scrolling are some really useless fonts.
To select the ones I typically use (tahoma, courier, etc.). I need to scroll many pages, keeping a close watch on the alphabetically sorted names flying by when scrolling). Of course I could spend a day cleaning out my fonts, but I am never sure if something actually uses one of these.
Like most other applications, LabVIEW should maintain a short list on top, containing favorite fonts. This list could be auto-populated by the fonts used on the current front panel or just be a short history of recently selected fonts. There should also be a configuration option, allowing us to "pin" certain really-really favorite fonts to that area.
It could look as follows:
Of course what we really need is a modern text toolbar, but this idea would apply there equally.
One of the nice features in the last few versions of LabVIEW is the Shared Variable. Unlike global variables, they can be programmatically created, which would appear to open up a range of new applications for LabVIEW.
Unfortunately, they cannot be assigned default values unless the customer purchases the onerously expensive DSC module. Making matters worse, there is a run-time license associated with distributed copies of an application which uses the DSC.
Naturally, this severely limits the usefulness of shared variables.
This is not the first time that we have seen NI take a key feature which a customer would expect to be part of the PDS, and put it into an optional module. I'm sure that this is intended to “encourage” customers to purchase optional modules.
Our corporate experience has been the opposite - we have seen one of our clients blacklist NI as a supplier, after they were burned by another instance of NI's callous feature bundling.
The probe watch window is a great way to have all probes gathered in one place.
However, it could be much more powerful if we could display the values with complete flexibility, as in: creating a front panel with graphs, arrays, etc with indicators linked to the listed probes and a custom VI to handle their behavior.
In other words, what is needed is a way to go from this:
to (for instance) this:
Note that I know that you can create custom probes, but as for the default types, the side panel of the probe window only shows one at a time.
I guess you could obtain the same functionality by creating a global variable containing all the probes you want and drop it in a VI polling their values on a regular basis. It would be so much easier to have access to the "global variable" in which the probes are stored (this is probably not the mechanism used, but for the sake of the discussion, I will used that term) and use them as such.
The main problem with this added functionality is of course that if you removed a probe and that probe was used in some advanced part of your custom probe display VI, that VI might become broken. So maybe the best would have to have a separate "Custom Probe Watch Window" that COULD become broekn without preventing the standard window to function just fine.
My 2 cts,
We use shared variable libraries containing many (sometimes hundreds) of shared variables. Within the library, we use virtual folders to organize the variables by type, function, etc. The multivariable editor does not work on shared variables in virtual folders. They can be viewed but not edited. They are locked. This is a major inconvenience. We have to move variables out of the folder to edit them and then move them back.
Also, when you rename an I/O server in a shared variable library, the variables that are bound to that server do not get updated. LabVIEW should automatically update the Network Published Project Path associated with the variables linked to that I/O server. It is a hassle to have to manually edit the variables, especially in light of the problem mentioned in the first paragraph.
Idea is while loops with time out condition. That means if the maximum duration is exceeded, loop stops executing the code inside and gives a time out error. So we don't have to check the maximum iteration number or time passed inside the code and it prevents unexpected long execution timing.
All right, due some technicalities of the LabVIEW Idea Exchange forum, I am reposting this idea with the attachment I was planning to add in part 2 attached to the first part (why is it possible to insert images in a comment but not an attachment is beyond my understanding). There will still be 3 parts to it (assuming each of them fits in the maximum allocated size per post), plus an appendix.
This post is intended to present a solution to a problem that I was struggling with using LV2 global variables in my applications.
I don't claim that this is a unique or elegant solution or even the first of its kind, but I'd be curious to hear comments and suggestions about it.
Since it might be a long post, I will split it into 3 parts. Part 1 will discuss the intended functionalities. Part 2 will present my current implementation. Finally, I will try to summarize all this into Part 3, opening the discussion.
So you may want to wait until that part is published before posting your comments (if any).
Part 1: What do I mean by Generalized (LV2) Global Variable?
The LV2 global variable (or functional global, FG in short) is a well known structure (see for instance the beginning of this thread). It is a subVI which can store data locally in between calls. Usually it comes with a "Write" (or "Set") action and a "Read" (or "Get") action and a few inputs (and the same number of outputs). The inputs are the variables you want to update and the outputs, their corresponding values. The advantage of this design over the standard LV global is that there is only one copy of your variables in memory. If you are only using scalars or string, etc., using LV globals might not necessarily be a big problem, but if you start storing arrays of large data structure, it could result in a significant performance penalty. Note that there are other ways to pass data from VIs to VIs (queues and notifiers). Here, I am concerned with long term storage available from many parts of an architecture (e.g. subVIs or dynamically launched Vis).
To begin with, there are two major limitations with any design based on FG (at least that I am not happy with):
1) First, as emphasized above, due to the limited connectivity of a VI's connector pane, a FG cannot store a large number of variables. You can use clusters, but that is not always very practical.
2) Second, if you try to cramp as many variables in a single FG, you will probably run into the issue that you don't necessarily want to reset all variables at once, but maybe just one or two. That calls for a more sophisticated set of actions (Write Variable 1, Write Variable 2, etc, and possibly Write All, Clear All, etc).
In practice, if you use a lot of those FG, you will encounter a third problem:
3) In which FG did I store this @$%&! variable?
Some of my applications contain many of these FGs and I figured that this had become impractical to handle when I started duplicating them, having forgotten that I was handling variable "X" in an existing FG.
The obvious solution (apart from NOT using FGs) is to have a single FG that is designed such as to handle an unlimited number of variables of ANY type that can be modified at ANY TIME from ANYWHERE.
I first looked at the WORM (Write Once Read Many) design of tbob (you’ve got to go to the end of the thread to download the final version of the WORM VI). It is a very clever and compact solution to store different types of variables within a single variant.
Two of the limitations I saw in this design are that you need to know:
1) the NAME of the variable you want to access.
2) the TYPE of the variable that you are WRITING or READING.
Let me clarify those two points.
It seems obvious that you HAVE TO know the name of the variable you are interested in. Well, that’s maybe true when you are designing your application. But after a month or more doing other things, it is not obvious anymore whether you’ve stored the number of components as “# Components” or “Component #” in that other part of the program that…where did I save it, BTW? You get my point…
The second point is apparently taken care of by tbob’s solution of outputting the variable (as a variant) as well as its type. The problem is that this “type” provides a very limited description. For instance, what do you do with a “cluster” type?
Finally, since I want to be able to modify any variable at any time, the “Write Once” feature is not cutting it for me. This is could be easily modified, but considering the previous comments, I decided to change the architecture some more. I will describe my solution in the next part.
The append table to report.vi for excel now sets the font to 10. Even if the current cell in the excel report has another fontsize specified.
The idea is to add an option to keep the tables fontsize, in stead of changing it to 10.
See the attached vi for the current behavior.
It would be very convenient to assign the Terminals to the controls and Indicators in the front panel by the following way while creating a sub vi.
1. Align the Controls and Indicators to the Left and Right
2. Place the controls and indicators in the order in which the terminals should be assigned.
3. Select the controls and indicators for those the Terminals should be assigned
4. Right Click after the selection is made
5. Select the Assign Terminals Option (Idea Proposed)
6. LabVIEW should have the Intelligence to select the type (Pattern) of connector pane depending on the number of controls and Indicators selected.
When the option is selected the Terminals will get automatically assigned to the selected controls and Indicators as shown below.
Am sure that this Idea would certainly save enough time for assigning the terminals to the controls and indicators.
If you are going to call it a developer suite, put the developer tools in it. The following toolkits need to be added:
Of course this will increase the cost of the developer suite. I find it easier to convince my boss to approve a cost increase versus purchasing a new toolkit.
When you edit a VI, you may likely move the origin of the pane and not know it. Next time you run it, your controls are not centered. There are several ways to work around this:
How about an option which sets the panel origin to 0,0 every time we save?
.... i.e., an Option which does this for us.
LabVIEW allows classes to use the IPE structure via the cluster unbundle/bundle pair. Generally I avoid this because it's poor form for object oriented programming: it bypasses any logic I've put in place in the get/set methods. If I use the IPE on classes, when time comes to change my get/set logic, I no longer have a singular bit of code to modify.
With the advent of properties for classes in LabVIEW 2010, I propose that the IPE structure should be adapted to allow the use of any properties a class has defined:
The IPE structure should:
I kind of think this one is more important than my variant post. I contest that LabVIEW currently has no support for objects in the current IPE since using unbundle/bundle on the class is generally a bad idea.
The LabVIEW project window has two tabs: (1) Items (2) Files. The "Files" view is very useful to me as a quick check to make sure all subVIs are loaded from expected locations.
I am not aware of an equivalent view into the current Vi hierarchy if we don't use a LabVIEW Project. Maybe I haven't found it yet.
My Idea is to have an optional window that show the current VI hierarchy in a layout very similar to the "Files" view of the LabVIEW project, even if we currently don't use a project.
(Image for illustration stolen from this article)
This idea got triggered by this other idea but this here is a significant variation and deserves it's own entry.
There is possibly some need to graph multiple XY plots on the same xy graphs, all sharing the same X values. One problem with the current XY graph implementation is the fact that the x-values need to be duplicated for each plot, unecessarily inflating the data structures.
One possible workaround has been suggested here, but I think we can do better!
Remember, that in this scenario, all plots have the same number of points, thus the data could fit in a plain 2D array. Why not?
Currently, xy graphs don't accept 2D arrays, so this will not clash. (Of course downconversion will be problematic).
I suggest that we should be able to directly wire a plain 2D numeric array to the xy graph terminal. In this case, the first row (or colum as set by a property or other configuration) is taken as X-array, while the remaining rows (or columns, resp.) are Y1, Y2, Y3, etc. arrays.
(Of course an xy graph should also accept a 1D cluster array where each element is such a 2D array. This is useful if there is more than one set of multiplot data, each with a different x-range or number of points.)
Hallo @ all.
I hope NI will implement a new head-controlled while loop in Labview 2011. This is a very useful function and I hope that many users will vote for this feature.
TestStand has a great feature when quickly jumping between directories called Directory History. I think this would be a great feature to implement in LabVIEW, and it has already been done in TestStand, so it should be a quick port.
If you are developing in several directories, such as using a common SVN directory and a custom development directory, it is quick to jump from one directory to the other when Opening, Saving, etc. files.
It would be really cool if I could drag and drop a polymorphic VI from its icon on the the block diagram of a VI, just like a standard VI would do it. The other ways include via the LabVIEW Project or from disk, but I would find this new method quicker when I already have the Polymorphic VI open.
Whilst I am at it, some other things that could be supported include better context help - I get this when really I want the description of the Polymorphic VI to show:
Important disclaimer: I am sorry, this is not my original idea, because it is (together with many other nice features!) already implemented in the LabVIEW UI builder. Credits go to the relevant NI developers.
This Idea posted here tries to see how much interest there is in such a feature and to show support that we want this also implemented in plain old LabVIEW. Personally, I really like it!
The Unused Items Tray (see also e.g. Christina's Blog entry) is an area on the diagram that contains terminals or FP objects that have not yet been manually placed or are currently only "used" on the BD "xor" FP, i.e. not on both.
The current problem in LabVIEW is that if you place a new control on a complicated VI, the terminal will end up on some random place, typically piled well camouflaged on top of some other diagram structures and possible a scroll away from where it is actually needed. Similarly, if we create a control or indicator from a terminal on the diagram, the control will typically be outside the carefully placed visible area and there is no way to grab it without first messing up the FP alignment by either scrolling or enlarging the window.
In all these cases, it would be nice if the objects on the "other" window would land in a predictable reserved floating location for quick and easy manual placement where they belong. During development, there are probably a few terminals that are not yet used or connected, and we should be able to place them back into the unused items tray of the diagram so they never scroll out of view or get misplaced.
On the front panel, we might have some spare controls "parked", and they would not show in run mode at all. This could even be abused for "local variable zombies" (=hidden controls with the sole purpose of making a local variable) along these lines, which might be OK (=better than hidden controls!). Front panel items in this tray would look like their palette entries. We don't want e.g. full-sized graphs in there!
Now, how should all this look like? In order not to cover valuable diagram space, it should be something that collapses to near nothing when not used and would only expand to show the current contents when hovering or clicking in a special area. Of course there should also be an option to pin it open. When minimized, it should look different when "not empty" vs. "empty".
Currently, when opening a command window with the System Exec function, the "wait until completion?" option performs two operations. It causes the VI to wait until the command is completed, and it suppresses the output in the command window. The output becomes available on the standard output terminal after the command has completed. This causes problems if you need to see what is happening in the command window, and you need the VI to wait until the command has completed.
It would add more functionality if these options were separate. One option, "suppress output?", would suppress the output in the command window and put the output on the standard output terminal. The second option, "wait until completion?", would make the VI wait until the command has completed.