Similar to specifying the Access Scope for multiple VIs in a library by grouping them in a Virtual Folder and setting the Access Scope of the folder, I'd like to specify locking or password protection for multiple VIs in a LabVIEW library by enabling that on the owning Virtual Folder. The dialog would be the same as if you were setting the Protection on the entire library from the Properties menu.
The IMAQ VIs are great for recognizing barcodes that are scanned.
On the flip side, there's not a really portable way to generate a barcode in LabVIEW (without having to install a barcode font). The nicest approach would be to have a custom control that has string datatype, and then on the front panel, the string gets displayed as a barcode!
Other approaches could involve using a picture control or something as well.
I ask for a general rework for selecting controls and indicators in a menu.
There are several locations where you select a front panel element. And it is done in several ways.
What I dislike is ordered by adding order. The other two depend on the front panel (and on my brain). I would like to choose the sorting and maybe some filtering myself. I do not know how it could look but some ideas will probably come from the community.
How about make a new array function that can insert items at the beginning efficiently?
I've recently run into an issue when using external code (ActiveX to be exact) where I needed to explicitly call garbage collection in a similar fashion to how it's done in C# (C Sharp).
The "Request Deallocation" function isn't true garbage collection.
A C# example would be:
someComObject = null;
There are situations where it is neccessary to explicitly call garbage collection.
My team has been working with LVMerge.exe for a while. I wish to disable "auto-resolve" as a default, instead of unchecking it after loading. Disabling block diagram cosmetic changes would also be nice. Some method to modify these settings, so that on the next VI load, the modified settings would be used instead. My original post is here.
Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.
What bugs me about the VI Profiling Tool is that it is not intuitive. The information it provides is really useful; however, it's so hidden and difficult to interpret that few people actually know where it is to use it. Let's say you are simply acquiring data using DAQmx and writing that data to a file, as below:
You might want to find out how to make this more efficient, but the only way you know is to insert Tick Count VIs and wrap your wires through sequence structures to do it. It's annoying, and there are other ideas from JackDunaway (here) and JohnMc19 (here) which aim to simplify the use of those VIs.
But why re-code your application when the VI Profiler can do it for you? In addition, the VI profiler has more timing information (longest, shortest, average, total, etc) as well of number of runs and memory allocation data.
Good news: VI Profiler makes getting the data easy.
Bad news: VI Profiler makes using the data difficult.
Why Using the Profiler is Difficult
First, you need to know it exists among a number of bland and condensed gray menus (Tools>>Profile>>Performance and Memory).
Next, you have to coordinate starting the profiler with starting your VI (start the Profiler, then start your VI, then stop your VI, then stop the Profiler).
Finally, you have to dig through a TON of VIs to find the ones that are relevant (I assume this is because, for polymorphic VIs, all of the instances are loaded into memory, even the dozens that aren't currently being used.)
When you find the VI you wish to examine, it will look something like this:
Have fun sorting through that! When I finally find a VI that's hogging memory or speed, I'd expect to click on it to navigate to that VI. NOPE! All the VI Profiler does is make the line bold. Not particularly easy to use...
I can't say if it's possible to get rid of VIs that aren't being used, or to make the menu option more visible to the user, but I do have an idea or two for how to make this information easier to understand in LabVIEW.
So here's what I suggest:
Adding a couple of check-boxes to the top of the VI Profiler will view in relation to your LabVIEW VI. Notice the extra check boxes in the top of this image.
One checkbox allows you to color the column you wish to highlight in your LabVIEW code. The other checkbox inserts a text comment containing the highlighted data straight into you LabVIEW code (right next to the sub VIs):
From the above picture, you can clearly see the Write to Spreadsheet File VI is the slowest to execute. Next in line are the Start DAQmx Task VI and then the Stop DAQmx Task VI. So if a developer wanted to find out how to make his loop run faster (and therefore increase the rate data is read from his PC RAM), he would know the VIs that are more red are the ones he needs to focus on first.
Also, if a user wants to highlight the memory usage, he could select a memory column from the VI Profiler.
Then the LabVIEW block diagram would look like this:
In this case, if a developer wants to find out how he can optimize his code for memory usage, he knows where to start.
Side-note: I think selecting multiple colors at a time (one for each column of data you wish to highlight) would be cool, but that would start to get messy on the block diagram.
Other data, like the number of runs, could highlight which sections of code are running more often than others.
If we integrate the VI profiler more effectively into LabVIEW, there are a lot of benefits:
1. Re-coding to find timing specs won't be necessary for Sub-VIs
2. Monitoring memory allocations much easier (some users don't know it's possible with LabVIEW).
3. When there's a problem, it's easier to understand which SubVIs are slowing down code or hogging their memory.
4. Developers can further code development WHILE being wary of inefficiencies.
5. More integrated development environment "feel" for new customers or the experienced G-coder.
Please let me know what you think!
I rarely use boolean operators to solve logical problems. Instead, as I would suppose the majority of users, I use them to respond to a set of conditions and perform actions in response to different cases.
The current set of operators:
is, to say the least, quite difficult to use. For instance, for the third operator, the help window provides the following explanation:
Now if you invert one of the inputs, good luck to figure out at first glance, when you revisit your diagram, what the outcome of the comparison will be.
In fact, what we need is some kind of matrix operator for which we type in the output of the comparison of A (input 1) and B (input 2) for the different cases:
Here I have supposed the inputs are "modified-booleans" with an "undefined" case, and the output of the comparison is an integer value, just to illustrate that operators for non-booleans could be treated the same way.
In the strict boolean operator case, there would be no "U: case and the output would be T or F. It would be a simple matter (I guess) to let the boolean operator icon show the outcome of the comparison in a way similar to something like that:
In general I find useful to have non-boolean outputs (as in the matrix above where integers were used) to be able to handle complex situations. Of course the icon would have to reflect the values selected by the user...
Which brings the issue of the configuration of this operator. Considering that the interface for this operator would be quite sophisticated, it would make sense to provide it as one of the Express VIs (such as the "Formula" or "Comparison" functions).
Typically, when working with classes, one tend to work on one class at a time. Consequently, opening a specific dynamically dispatched VI (from another VI) should result by having the class implementation opened (like if it was opened from the lvclass). The Choose Implementation dialog should not be shown (in most cases).
I did some quick statistic, and in most situation, I care about the class implementation (about 80% of the time). In some instance I care about parent or children implementation (about 10-15% of the time). Finally, in some rare instance (<5% of the time) I care about the sibling implementation. Note: I confirm this with a few of my colleagues as well.
So what I am proposing is that by default we should not see the Choose Implementation dialog. When we specifically want to see this dialog we could use either of these methods:
Comment and improvements welcome.
I often find myself debugging code that seems to have "hangged" and I want to find out which VI is causing the "hang" (maybe it's waiting on some event/queue/message/timeout or maybe it's stuck in an infinite/long loop). There's no really easy way to figure out which subVI (or perhaps a node) is not returning from its call.
The way that I currently do this is to start opening up VIs and looking at their "Run Arrows" (the run buttons on the VI toolbar) to see which subVIs are currently "running" (being called).
Running (Top-Level VI)
Running (Sub-VI of a Running Top-Level VI)
<< This is what I look for
Not Running (Sub-VI of a Running Top-Level VI)
This technique works OK, but it takes a lot of time to track down the running VI (in applications where there are LOTS of VIs), since you have to just start opening up all your VIs a looking at their run arrows.
Question: Is there any way to look at the run state of a VI using VI Server or Scripting? Unfortunately, the VI Execution.State property is "Running" for all three states shown/illustrated above (the "Idle" state is for VIs that are not reserved for execution, meaning they are not in the hierarchy of a running top-level VI). Maybe I'd also add to my feature request that it would be nice if there were a way to interrogate this state using VI Server or Scripting.
What would be nicer is if I could ask LabVIEW to Find all Running SubVIs/Nodes and visualize them by their VI Hierarchy. Maybe we could have an option to show the run state in the VI Hierarchy window. And, maybe there could be a way to only show running VIs (hide all Not Running / Idle VIs).
Now, I realize that the VI hierarchy window doesn't have any way to visualize multiple subVI "instances" of a VI, but maybe that could be an option as well (Show all SubVI instances. Also, it would be cool if we could show "Clone" instances of reentrant VIs... but, I digress.
Also, the VI hierarchy window only shows VIs, it doesn't show nodes/functions that might be running (and what's causing my code to "hang"). It might be nice if we could also include nodes, at least for the purpose of helping me find out which nodes are running.
So, I'll end by just stating that I need some easier way to figure out why my application appears to have hung and I hope that this "Idea" leads to more discussion and maybe some more features in LabVIEW to help me debug and visualize my applications.
Do you have any ideas for how to better debug applications that appear to have hung? Do you have ideas for new LabVIEW features that could help?
If a class is contained in the private data cluster of another class, this is the LVOOP equivalent to an Association (as OOP concept). I'd like to optionally display this relationship of classes in the Class Hierarchy window. It should also work for nested structures (class in array, cluster, DVR).
As used from normal BD programming, different kinds of wire should be used to identify details of the relationship:
The following would be nice to have, but partially difficult to implement:
In addition there should be a way to annotated the associations to indicate when the intended use is restricted to a child class, such as class that contains objects of the type of the same class. Here the association would point to an ancestor of this class. Either we should be able to put a comment on the 'wire' to document this intention. Ideally we could be able to wire classes with recursive associations (which are not possible in LVOOP, hence this should also not have any effect on the code by only be documentation), and link it to the implemented association wire.
I use mouse that has navigation buttons on its side (go back - go forward). I find it very useful while navigating web or windows explorer - it is simply faster and easier.
LabVIEW control and function pallets became quite extensive with many levels of subpalets. Often they require to navigate back and forth a lot to place required elements. It would be great if pallets remembered history of navigation and allow to navigate back and forward with mouse navigation buttons.
What is great to mention is that I am able to scroll front panel and block diagram left and right with scroll roll that also has function to be pressed left and right.
Many times I want to see if a variable equals any one of a group of possible values. There are several ways to code this up now, (one method show below as "OLD").
I would like a single, simple expandable node to save diagram real estate. The top wire terminal would be the item to compare, "equal to.." and all the rest are the possible values. If any of these are a match, return TRUE, else return FALSE. Obviously this should be polymorphic, so that we could compare anything, for example, the current config cluster, with a group of configurations.
For extra credit:
1. Be able to wire arrays into the expandable terminals.
2. Be able to pop up on an input node and designate it and the following node as a Range-Pair, (shown in example above) ie from 7 to 23, or values of an enum or ring, etc, inclusive or exclusive, with those terminals showing solid or outline diamonds like on the the "In Range and Coerce" node.
I've been working 3 days on creating a help file for a production test program. It would really be nice if Labview could export all of the indicators and controls with their descriptions into a help file editor so all I had to do is arrange items and create links, table of contents and indexes. I'm still cutting and pasting my exported descriptions into HelpScribble and still have to add the graphics.
There are express VIs for Analog/Digital/Counter channels.How about express VIs for configuraing and acquiring data from an RS232 port?
Once I set the Polymorphic DAQmx Vi to (for instance) AI Current, why is DAQmx Create Channel (CO-Pulse Generation-Freqiency).vi and a hundred others shown in Dependencies? I stopped counting at 200 DAQmx VI's in my list, and I'm just using 12 VI's.
An alternative to getting the Project list working right would be the ability to convert a Polymorphic DAQmx VI to it's selected VI.
Display VI version in Tools bar For any vi
My use LabVIEW 2010，Often saved a vi(8.5) as high-version .
Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.
Sorry ,My English no good.