I am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.
Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.
For instance, here is the Event Structure list:
Same goes for the list of controls in a Local Variable (and other objects, I am sure).
There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:
Or is there?
Suggestion: All long pulldown lists should have a vertical scrollbar
Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!
In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.
Here is a simplified example to illustrate the problem (see picture).
In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.
However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course ). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!
What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.
The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.
Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.
(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)
Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.
99% of the time when I use a Diagram Disable Structure, I am disabling code with an error cluster wired through. I don't want to lose the errors coming in, just the single operation, so I manually wire the error cluster through the empty case each time.
I've talked to others in the past about this and it would be nice for LabVIEW to be all-knowing and wire all datatypes through that match, but that would definitely lead to conflicts and mistakes. Error clusters, on the other hand, are simple are nearly always a single wire in and out.
Simply auto-wiring the error cluster input to the output would make the debugging process much easier.
Code with disabled operation:
It would be useful to have something like a referenced comment. You can place this comment in the block diagrams of several VIs of a project, and by editing one instance of this comment, it will change all instances at one time.
The comment describes the channel list of an application:
AI_00: Torque [Nm]
AI_01: Pressure [bar]
AI_02: ValvePosition [%]
You place this comment in the DAQ-VI. But it would be helpful to have the identical comment in the MeasFile-VI and/or in the VI that combines the channel and scaling informations to a 2D-string array, so you can present all these informations together (e.g. in a multi cloumn list box or something else).
When you later add some new channels e.g., it will be annoying to edit all these comments step by step, something like a 'comment type def' would be a practical solution.
Want to have graph display a certain scale unless values go outside scale min or max and then do autoscale but only in direction which scale bounds were crossed.
Normally want graph to display X scale 0 to 10 to display to user:
If set same graph to autoscale would get the following graph that user could interpret as values are swinging all over the place but this could just be noise and I do not want to display this format to user:
So I want a solution that incorporates manual scale and autoscale by autoscaling only after scale limit is exceeded. Asume get a data point of 13 which is above the max scale range of 10, graph would do a single autoscale only in direction above 10 to change max to 13.
Would be Graph Scales property. Option disabled if Autoscale was selected.
I know can use property nodes to programatically do this in my program but it is much more involved having to constantly check to see if values have gone outside range and then issue a single Autoscale.
I know hyperlinks in free labels have been implemented in LabVIEW 2015 and that the idea has been marked as implemented:
Kudos to that and I love it.
However, there was another idea:
that was closed as a duplicate of the hyperlink in free labels, except there is a small difference in the second idea that was not really implemented. The hyperlinks do not let us insert links relative to the project, the poster of the Documentation links on block diagrams even says: "The risk would be moving the document and the link becomes invalid. This risk could be minimized by placing a documentation folder in your labview project."
So this new idea is to let us either use relative paths on the hyperlinks on the free labels: i.e. file:///C:/ProgramData or use environment variables such as %userprofile%, %programdata%, etc. For example, file:///%userprofile%/documents. This would make it possible to put links to documents in our machine that will be in a different path than the rest of the team working on the project. The documentation might be relative to the project file, but might not be exactly in the same location in each machine due to differences such as %userprofile% = C:\users\<user name> where <user name> will be different for each team member.
I faced to delete multiple elements form the array which is having 20 steps.
if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.
Tired of resizing an event structure and having to relocate the timeout constant?... Simply double-click on the hourglass and type the timeout value!
Of course, the option of wiring to the event structure timeout input should still exist. Just like the timed loop, where you can double click and set the period, etc.
When selecting block diagram items from the "search results" screen, the resulting highlighted area on the block diagram always seems to be on the extreme edges of the screen. This requires a finite amount of time scanning all four corners of the screen for the item. Recommend that the "found" item always be positioned in the exact center of the screen to eliminate this issue.
NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
I believe many of you had already the problem that you accidentally changed a VI's from the vi.lib and saved it.
There should be an option to use the complete vi.lib Read only!
I do not want to change the VI's in the vi.lib at all! Never!
Thanks for your support.
Excuse for my bad English.
Sample of an open VI from the vi.lib
and in the Options Menu it can look like this:
Updating a value within an array of cluster is too complicated compared to other programming languages.
In my application I hold an (global) array of jobs to do, each consisting of its name and an array of (different) parts belonging to this job. One element of the part's description is the number of parts already done. If I want to update this value, the code looks:
Note the calling function has to update the global variable after updating or JobFilesIn and JobFilesOut can be replaced by reading/writing the global which does not make the code more visible.
Within C code the update would look
which will not raise the need of making it a function (VI) at all.
A solution might be similar to Replace Array Subset if the compiler is parsing the data type on the input and accepting indices and cluster element names as shown below
Of course this should work with any data type selected from the initial variable by the selectors similar to C code
It also should accept a cluster as top level element as well, e.g. to replace an element within an cluster of clusters similar to C code
or an element within an array which is part of a cluster.
All the C code examples above expand to LabVIEW code which is hard to read.
An RT program can be ran either from a host PC (what I call the "interpreter mode"), or as an exe in the startup directory on the RT controller. When running from the host PC (for debugging purposes), it allows front panel "property nodes" to execute properly as you would expect. After building, and transferring to the RT app to the startup directory on the RT controller, the program errors out on the first occurance of a front panel property node. The reason is obvious; a front panel is non-existent in an RT application, hence the front panel property nodes are rejected. Of note, no errors or warnings are generated during the RT app build operation.
Recommend that the build application simply ignore the front panel property nodes as it ignores the front panel in general. This would allow the programmer to retain the same version of the source code for either mode of operation.
I have a Red-Green colorblind coworker. When he looks at the Silver Error Cluster, he actually cannot tell if there is an error. Why? Because NI decided to make green the false state and red the true state of the boolean. So he updates his error clusters to use black for the false state.
Simply put, that boolean display needs either icons (like in the Modern Error Cluster) or different colors to help these people.
LV currently allows you to swap wire positions (on BD) or terminals on the connector pane just by clicking on connection point while holding Ctrl key.
So why to not implement this also for the Case Selector Terminal?
Then you would be able to wire Case Selector Terminal in two clicks:
Of course swapping cursor will only appear if you select terminal that is considered as compatible/valid input of the Case Selector Terminal (based on auto-proofing which will exclude arrays clusters images, references and so on).