LabVIEW Idea Exchange

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

We currently have an AND Array Elements and OR Array Elements.  It would be helpful to also have an XOR Array Elements.  I most often run into needing this when trying to calculate parity.

 

Current Boolean Pallette.PNG

This suggestion is to have an "inverse" Disable Diagram or an Enable-this-part-of-the-code-only Diagram (it would have to have a better name than that :)). This feature would let you disable all your other code except for what's inside this structure. I think it'd be useful in troubleshooting and focusing in on parts of code.

Every time I drag a new VI into a virtual folder in my project, it is placed at the bottom (if the folder was not expanded).  The first thing I do is to right click on the folder and 'Arrange by name'.  This is getting tedious.  I want to be able to set the folder to always arrange by name (or type or path).  All we need is a persistant check mark next to the 'name' option.  Most (if not all) OSes can remember these kind of settings for each folder in thier UI, LabVIEW needs to do this too.

Hi everyone, it's Mike out in West LA Sales.  This one came from one of our customers that we'd like to see added:

 

E-mail from customer:

On input limits for controls, you have the option to “ignore” or “coerce” if you go over/under a limit.  Right now, “ignore” will ignore the limits you enter, not ignore the command that someone types into a control.  It would be nice to have an “ignore” that, if I type a value of 2000, and the upper limit is 200, then it completely ignores what I have typed in.

 

Example:

 

Someone goes to set a pressure setpoint to 70 psi.  The limit is 130 psi.  The way the limits work now, if a [customer's vulgar language removed by Berto :] walks by and I mistype and entered 700 psi, then it would coerce my entry to 130 psi!  It would be nice to have it completely ignore what I have entered if my entry is over the limit.

 

 

Thanks team!  We love the Idea Exchange!

Unless the programmers is pretty familiar with LabVIEW, debugging can be confusing, for example if uninitialized shift registers and feedback nodes retain data. Suddenly the results are different between different runs with the same setting.

 

One might innocently expect that if I do "menu...edit...reinitialize values to defaults", I start again with a clean slate, which is of course not true if there are USRs. There is hidden extra data lurking beneath the surface.

 

I remember that this confused me when I first started with LabVIEW 4.0 many years ago. There is currently no direct way to "reset" a VI to the way it was right after loading (all controls at the defauls, all USRs cleared, etc). The only way to clear USRs is with a "file...revert", which has the unwelcome side effect that we lose all edits, meaning we need to constantly save versions to keep up.

 

I would prefer if there was a menu to clear all internal data structures from a VI without having to save the VI first. Alternatively, maybe this action should be included automatically if we reinitialize a Vi to defaults.

Message Edited by altenbach on 06-11-2009 01:23 PM

One ugly way i usually have to code is  

 

Example_VI_BD-1.png

 

A better way would be to be able to wire, a wire to every function.

This wire will carry data, but it will not pass them in the middle function. It will be a bump input-output, just to determine which function to be executed first. There should be an indicator, when this dump input-output is activated. It can be activated with right clicking on the icon.

Example_VI_BD.png

 This wire should be able to be, a dump wire without any data so you can impliment this

Example_VI_BD.png

The images way not be so nice, but that's the idea..

 

 

Application Builder properties dialog >> Source File Settings >> Customize VI Properties...

 

It would save me a lot of time if it were possible to select/deselect all properties at a time.

 

VI Properties.jpg

In the world of robotics, underwater vehicles, autonomous systems and more...there's a need for a few more UI controls that turn into quite a hack with the current picture control implementation. To quote a few of my new friend (Philbot and PJM_JKI)...

 

We need 1) A Compass (see attached image), 2) A way of displaying Pitch and Roll (like an artificial horizon) 3) A way of displaying thruster control (usually tie to the Pilot joystick)

...quoting PJM_JKI directly..."If there are no new native controls added, I would request improving the Picture Control (this would, in general, be a very good thing for LabVIEW). For instance one can create their own control using the picture control (see attached image of the compass we put together using this technique), but there are several limitations that requires a lot of work to overcome.

 

Picture control improvements:

 

  1. Performance (I think it will make a major difference if the Picture Control would use OpenGL Hardware acceleration for instance).
  2. Support for alpha transparency.
  3. Support for drawing antialiased object (such as lines, rectangle, circle, arc, ....)."

Something as cool as this is possible...but with a lot of work (from PMJ_JKI): 

History probes are a very useful tool in LabVIEW. However, one improvement can be made to them when working with enums. Currently, the values in enum history probes are returned as numbers, as shown in the picture below:

 

Enum History Probe.png

 

It would even be more useful if enum history probes returned values in terms of the enum item names rather than the numeric values associated with them, as shown in the picture below.

 

Enum History Probe.png

cbutcher_0-1644062153495.png

The top For loop + Unbundle is the current method to get the Keys and Values of all elements in a Map as arrays. If you need both, this is ok, but I'd prefer the second option, with a native node.

 

If you only want one (e.g. the Keys), then the For loop and Unbundle takes quite a bit more room than a similar-type of node (here the size is taken from the Collection Size node, and the paired outputs in the second row are from Matrix Size).

Can we have nodes to access the keys in particular, and perhaps the Keys + Values of a Map without requiring the For loop?

In LabVIEW you need to know the number of sub matches at edit time and cannot handle arbitrary regular expressions. It would be nice if there was a regex function that returned sub matches in an array which can be handled much more abstractly than a pre-sized xnode.

 

C++, the regex utilities return a container-like class https://www.cplusplus.com/reference/regex/match_results/

PHP an array of matches is returned https://www.php.net/manual/en/function.preg-match.php

JavaScript returns an array of matches https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match

 

There is a strange asymmetry in the conversion pallet:

heel_1-1628866756838.png

 

I cant see any reason why it is not supported to use the type conversion on an array of FXP when it is on an element. It should be either none or both.

 

When indexing a map on a for loop, the indexing is automatically done by ascending order on the key value.

I like this as a default behavior.

 

Capture d’écran 2020-10-06 103344.png

I'd like to have a context menu option to force the for loop indexation to be done in reverse order.

In LabVIEW we can specify <topvi> as a VI search path when VIs can't be found.

 

I would propose adding <project> as an option (perhaps with a subfolder by default). This would allow for new reuse patterns based on keeping libraries in the project. I expect this would make tools like GPM much easier to develop as well.

 

It could be a first step to something like node_modules in NPM or virtual environments in Python.

 

James_McN_0-1590488521270.png

 

With the advent of the IoT and the growing need to synchronize automation applications  and other TSN (Time Sensitive Networking) use cases UTC (Coordinated Universal Time) is becoming more and more problematic.  Currently, there are 37 seconds not accounted for in the TimeStamp Which is stored in UTC.  The current I64 portion of the timestamp datatype that holds number of seconds elapsed since 0:00:00 Dec 31, 1900 GMT is simply ignoring Leap Seconds.  This is consistent with most modern programming languages and is not a flaw of LabVIEW per se but isn't quite good enough for where the future is heading   In fact, there is a joint IERS/IEEE working group on TSN 

 

Enter TAI or International Atomic Time: TAI has the advantage of being contiguous and is based on the SI second making it ideal for IA applications.  Unfortunately, a LabVIEW Timestamp cannot be formated in TAI.   Entering a time of 23:59:60 31 Dec 2016, a real second that did ocurr, is not allowed.  Currently IERS Bulletin C is published to Give the current UTC-TAI offset but, required extensive code to implement the lookup and well, the text.text just won't display properly in a %<>T or %^<>T (local abs time container and UTC Abs time container)  We need a %#<>T TAI time container format specifier. (Or soon will!)

I've got some calls to low level VIs that rely on windows system dlls within a larger top level VI. To make that application work on Windows and Linux, I've put conditional disable structures around the dll calls. When I open the top level VI in Linux, I have to click through a bunch of "Find missing file" dialogs for the Windows system dlls. If I cancel through all the dialogs, the VI still compiles and runs correctly in Linux, so the Conditional Disable structures are doing most of what they should, but the dialogs are annoying and can cause problems with automated builds and other hands-off activities. Since the code is inside a conditional disable structure, it seems to me that LabVIEW has all the information in needs to know it shouldn't load that stuff, so it would be great to get rid of these nuisance dialogs.

Hello,
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

Unbenannt1.jpg

 

 

and in the Options Menu it can look like this:

Unbenannt2.jpg

 

At the moment the only way (I know) to fill a picture ring with pictures is to copy a picture item to clipboard and paste it into the ring. There is no way to programmatically fill the picture ring and afaik this is not planned to be implemented because the ring has to be recompiled and so there is no way at runtime (maybe with scripting?).

 

To simplify this I'm thinking of a way to convert a picture ring into an array of "2D Picture" items and back. Maybe over right click the ring and select "Convert to picture array" and then same way back by right clicking the picture array and selecting "Convert to picture ring".

 

The picture array can be filled and handled programmatically and with some programming you can create a simple manager to insert, swap, edit and ... your images, show them in a picture array, copy the picture array data in run-time, paste in frontpanel in edit mode and "Convert to picture ring". Done, easy and simple.

Probes are useful for seeing when a piece of code has executed for the first time after clicking 'run' as well as to see real-time values on wires.

 

Currently probes retain their values when the top VI stops, which is useful, but less usefully, keep their values indefinitely, even when the VI is restarted.

 

I'd like them to reset to 'Not Executed' when you click 'Run' again, otherwise I have to delete and recreate each probe in order so that I can tell when they have executed for the first time (unlike the lightbulb which slows everything down, breakpoints which pause the code or adding indicators which may not be convenient on a front panel (and require initialisation code)).

 

If this could be implemented (or could be an option for all probes or for any individually by right-clicking on them) I would find it really useful!

 

 

 

Didn't find this idea posted, I think it's a must.

 

It would be very usefull for MulticolumnListbox Item Names in which we need to change cell values...

inplacepropertynode.png