LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

It would be very handy to be able to probe a queue refnum wire and get generic information about it besides just the refnum number. It would be nice to see the same information that is returned from the Get Queue Status function:

 

  •  Max Queue Size
  • Queue Name
  • # Pending Remove
  • # Elements in Queue


The probe could also show the Queue Refnum. If possible, it might be nice to have a boolean control on the probe front panel to select whether to show the elements in the queue as variants, but it would still be helpful enough just to probe the number of elements in the queue.

 

To do this now, you have to manually create this probe for every different queue type, since they're all technically different data types.

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon: raphschru_0-1665514290538.png

instead of a library control icon:       raphschru_4-1665514883384.png

 

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

 

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

 

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:

 

The In Range and Coerce function is frequently used to determine whether a value is within range of an upper limit and lower limit values.

 

But when it is out of range, you often also want to know whether the value is out of range too high, or out of range too low.  It is easy enough to add a comparison function alongside and compare the original value to the upper limit.  It's another primitive and 2 more wire branches.  But since comparison is one of the primary purposes of the In Range and Coerce function, why shouldn't it be built into it?

 

The use case that made me think of this that as come up in my code a few times over the years is with any kind of thermostat type of control, particularly one that would have hysteresis built into it.  If a temperature is within range (True), then you would often do nothing.  If it is lower than the lower limit, you'd want to turn on a heater.  If it is higher than the upper limit, than you'd turn off the heater.  (Or the opposite if you are dealing with a chiller.)

 

Request Add an additional output to In Range and Coerce that tells whether the out of range condition is higher than the upper limit, or lower than the lower limit.

 

(That does leave the question as to what should the value of this extra output be when the input value is within range.  Perhaps, the output should not be a boolean, but  a numeric value of 1, 0, and -1, perhaps an enum.)

It is common, in writing reusable code, to handle arbitrary clusters in variants.  To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items.  After access, one needs to convert the array of variants back into the original cluster.

 

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository.  They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow.   Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

 

The other direction, Cluster to Array of Variants, works like this:

Array of Variants to Cluster.png

But trying to reverse the process breaks:

Array of Variants to Cluster.png

 

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also.  The matching of array to cluster elements can be by cluster order rather than element name.

 

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

Swap Long.jpg

(hope this hasn't been posted before, couldn't find it)

 

Since we now have 64 bit numbers, can we please have a Swap Long function?

 

This is a real hassle to do yourself (convert to byte array, rotate array, convert back? or flatten to string, flatten back with different byte order?). If you have large arrays of "quads", it is a real performance hit without the function.

 

Regards,

 

Wiebe.

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.

 

make type def.jpg

The Cursor Legend pop up menu on graphs has an item: Bring Cursor to Center.  Very handy when the data changes and the previous cursor position is now 4000 screens to the right.

 

I suggest that an Invoke node be made available which provides this action.  This will allow use of a push button on the front panel to bring the cursor back with very simple code.   Obviously NI has already done all the work because the menu item exists.

 

This can be done with property nodes but it is rather complex to examine the scales, check the current position of the cursor, calculate the center, and set a new position.

 

I asked about other ways to do this in this thread.

 

Lynn

I find it annoying to have to wire the User Event Refnum around my entire code loop in order to explicitly destroy it upon completion.  It can get pretty ugly with larger loops and creating/destroying multiple user events.

 

Simple User Event.png

 

 

 

It seems it would be nice to have an Unregister For Events primitive that could return a reference to each of the events that had been registered:

 

Simple User Event with New Feature.png

 

The dropdown might have to include the name of the user event in order to make it clear to the user which event is which, but hopefully the above drawing gets the idea across.

Text, formatted into a control as shown below, is handy, but can be confusing to a user since it is selectable. A user may try to change it - for instance from "mA" to "A". Further, they may triple-click (selecting all) then think that they have to enter the "mA" after the number. Further, there is a bug (in my opinion), where the number can actually change if you try certain entries into the uneditable text. Whether it is a bug or not, if LabVIEW didn't allow you select the text, all would be well.

 

 

text in numerics.png

From my experience, it would be more useful for terminals on the connector pane to default to Required instead of Recommended.

 

terminals.png

 

Here's my thinking:

 

  • Usually You Want It - In general, when you create a SubVI you require all of the inputs, in which case it is a pain to go and change every terminal individually to required.
  • Conscience Programming - If you are creating inputs for your SubVI that are not required, chances are you are very conscience of this, have done it intentionally, and written code to handle that case where the terminal is not wired.
  • Easier Debugging - If Required terminals are not wired, VIs will be broken, i.e. you have compile errors instead of run-time errors.  These are much easier to debug (especially when the errors appear on functions inside your SubVI that did not receive their required inputs).  If in fact the terminal should not be required you are prompted to make that decision, instead of finding at run-time that your program does not work as expected.

I completely understand why we need these three categories.  However, it seems that the usual use-case is and should be Required and therefore the default should refelct this.

 

Chris V

There is one thing I am missing in the Replace menu. It seems logical to have an option there to replace the VI (or missing VI) with a NEW VI.

 

Every now and then I come across code that is missing a subVI and the VI is nowhere to be found so I end up opening the VI with a question mark in the place of the missing SubVI. Now, I can see that LabVIEW knows what the connector pane of the missing subVI was (the used part of it anyway), and I just want to replace the question mark with a VI with the same connector pane. However, no "Replace with New VI" option exists.

 

There are two ways around this already, but none of them are as smart as they could be. The most obvious is to just creae a new subVI and use the replace function, but then I will have to recreate the connector pane manually. The second option (which did not occur to me until I began thinking about this idea) is that you can just click on the question mark and select "Create SubVI" from the Edit menu. LabVIEW will then do what I want - namely to create a new VI with the same connectors as was used for the missing subVI - job done. However, it will also place the question mark inside the new subVI and nag about it being missing. I can cancel the missing VI dialogs, delete the reference to the old VI inside the new one, and I am ready to rebuild the missing VI, but why not just have a replace with new option? 

 

The missing subVI is an infrequent case, so why bother? Well, this is not just handy for missing VIs. It will simplify things any time you want to replace an existing VI by creating a new one. Sure, you can save the existing VI with a new name, replace the old one with it, and then start changing the new one..But with this option it could all be done in one go.

 

 

ReplaceWithNew.png

 

 

 

 

 

The "Wire All Terminals" feature (pressing Ctrl-Space, Ctrl D) is such an awesome feature for quickly adding controls and indicators to a subVI.  However the current implementation makes a spaghetti bowl on the block diagram, as well as a unintuitive collection of controls on the front panel.

 

autodrop1.png autodrop2.png

 

I propose having this feature place the terminals in a cleaner, more organized way, and to logically organize the front panel controls as well.  It could even take the FP placement from the actual subVI, since most (hopefully) already have them in a nice layout to begin with...

 

autodrop4.png autodrop4.png

 

First of all, this is not a duplicate of this, by Case Selector I mean Case Selector and not the label.  It may well be a duplicate of something else...

 

I doubt that I am the only one who uses multiple conditions.  This usually leads to nested Case structures, building boolean arrays, or obfuscated mapping functions between the conditions and some enum.  Other times, the case structure is half-of-a-screen wide just to accommodate the values associated with the different cases.  I would suggest that NI add multiple Case Selectors to the Case structure.  Additional selectors could be pulled down like a shift register, or added via a right-click menu.  Either way, I don't think they should be allowed to cross, so the top-down selectors map to left-right selector labels.  There could be a reasonable limit to the number.

 

The "Save As" dialog does remember the last selection (this is nice). But sometime when going from "Rename" to any "Copy" operation there are one too many click.

 

This is what you have to do if you want to go from "Rename" to "Copy>>Open additional copy".

 

9-29-2010 3-44-02 PM.png

 

Instead this is what you should be able to do.

 

9-29-2010 3-08-58 PM.png

 

This is fairly minor (and a low hanging fruit) but this will improve usability.

A new function that indexes the last element of an array would spare some place on the diagram or avoid to use a subVI !

Or the Index Array function might be enhanced (First, specified Index and Last).

 

21748i0E884F1728A1398B

(I thought something similar was suggested before, but I cannot find it).

 

It is often necessary to deal with "malformed" spreadsheet strings, where there is more than one possible delimiter.

 

One example is discussed here, where a delimiter is either ",", "N", or a combination of the two, but the same has come up before. In my typical case, users sometimes use notepad to edit spreadsheet files, randomly replacing tabs with multiple spaces, multiple tabs, or a combination of tabs and spaces, so it "looks" aligned, but spreadsheet string to array will choke on it.

 

"Scan strings for tokens" has that useful feature to allow the definition of multiple delimiters as an array and (by default) consecutive delimiters are contracted into one (option "allow empty tokens?"=false). This makes it easy to parse lines (delimiters: \n, \r) or fields (delimiters: \t, \s). An example to deal with dirty strings is given here.

 

"Spreadsheet string to array" already accepts arrays of delimiters, but they are treated as alternatives and multiple consecutive delimiters are NOT contracted into one. I suggest to add an option to "Spreadsheet string to array" where multiple consecutive delimiters will be contracted into one for parsing. (or it could be named "allow empty tokens?" as above for simplicity, default=true to keep current behavior)

 

For example if I wire a delimiter array containg a single space element, it would treat multiple spaces as one.

If the delimiter array contains a tab and a space, consecutive spaces and tabs (in any order) will act as a single delimiter. The above quoted example would have a delimiter array containing two elements, "N" and ",".

 

Suggestion: add a boolean input to treat multiple consecutive delimiters as a single delimiter. For example, the two code fragments in the image should give basically the same result (The upper part is slightly defective and would need a little bit more code if lines end in a delimiter, but I think the idea should be clear).

 

The suggestion is at the bottom:

 

 

 

 

I need to detect when a user has released mouse control of a slider, but that is not possible. I would like to see a new event on controls called "User Control Ended".

 

For instance, consider a user grabbing a slider knob:

 

UserControlBeginning.png

 

The user is able to drag the mouse anywhere, even outside the bounds of the window, and still have control of the slider:

 

UserControlOffScreen.png

 

And if the user Mouse Ups outside the window, you can't detect when that event happened. Here, Mouse Up and Mouse Leave are of no use on either the control or the pane. The new "User Control Ended" event needs to be robust like "Drag Ended", detecting events that happen even outside the VI pane.

 

Conclusion: when a user is interacting with controls using a drag-like operation, I need to know when the user releases the mouse button, whether it be inside the pane, outside, wherever. I have illustrated the example using a slider, but the idea I think should encompass nearly all controls (e.g., a user clicks on a Boolean with "Switch when Released" mechanical action, then drags the mouse outside the Boolean and releases to effectively cancel the Value Change event. Well, I'd still like to catch the "changed mind and released mouse button elsewhere event", a.k.a. the "User Control Ended" event)

 

 

EDIT: Attached the VI so you can play with it.

Message Edited by JackDunaway on 02-19-2010 11:24 AM

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.

 

In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".

 

If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.

 

If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.

 

-------------------------- Example ----------------------------------------------------------------------

 size to widest.pngsize to widest2.png