LabVIEW Idea Exchange

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

Add a confirmation dialogue when changing type definition to control. I just experienced changing a type definition to a control by mistake and was scared until i realised that if i just kill LabVIEW at this moment that it would work as an undo. Of course undoing all the other changes also.

 

A simple are you sure dialogue wouldn't be so annoying as this happens rarely and don't believe that it would require lots of resources to implement.

A value change for the autoscale setting of a graph / chart scale is currently not registered. It can only be detected by polling for the scalefit value. The range of detectable events on charts and graphs is currently incomplete. The scale range change event and the autoscale range change event trigger at the same time in unpredictable order. This makes it hard to detect whether a user manually adjusted scale minimum and maximum or adjusted the autoscale settings value in the scale attribute. Different user actions all trigger a scale range change event without any way to discriminate the cause of this event. 

I wish there was a simple check box or rotation option for the Y-Axis name label on charts/graphs rather than having to do it programmatically.

 

Here is what I mean:

 

Y-Axis.PNG 

 

I emailed tech support and they confirmed there is no direct way but sent me a workaround which I've attached for reference.

 

Regards

 

Mitch

>90% of the time when I need a File Path Control I never need it in the default Selection Modes "Files" and "Existing". My idea: change the default state to the more generic "Files or Folders" and "New or Existing". Or at the very least make it an option.

In response to another post, Darren suggested someone start a new topic about how to more effectively spread information about new or esoteric features (sometimes referred to as "tribal knowledge").

One idea is to have a database of these gems and display one at random during the splash screen.  So, while we are waiting for LabVIEW to start, we can learn a potentially useful "trick", if we care to.

 

Example:  "Control-click on some primitives will reverse the order of the inputs.  By also holding Shift, any inversions will follow the connections."

(Note:  the second have of this example is not actually implemented yet.)

If an error occurred inside a case/event structure, it should include the case/event name in the error source for easy tracking.

It'll save tons of time for large applications with a lot of cases in the process loop.

 

I know I can do it myself.  Just something better to have with a right click.

 

Untitled.png

 

 

How often do you find the need to orginize data into a table format while documenting your vi?  I for one, could & would use it all the time!  Creating a resizable table free label we all use in word & excel seems like a simple task and would aid in organizing and documenting data into a more readable format.  A ctrl+double-click or shift+double-click could serve as an easy access method, tab through the contents, and resize rows and colulmns vis a cursor change while hovering at the specific borders.  Free Label, New type, table format, organize data, rows, columns. 

 

Free Label Table.png

I sometimes need to add (paste) text documentation to the block diagram. This often results in a single line of text that can stretch, as a single line, for what seems like miles off to the right of the text-block insertion point.   I then need to make multiple drag-edge/shift-block/repeat adjustments to beat the text block down to something that will fit on the screen.   It would be nice to instead be able to select the text block and either specify a width or else say to make it the same width as something else on the block diagram.

 

Scroll bars in text blocks would be nice too, as long as I am wishing.

I find the new Channel wires very useful things! However, I really miss one type/variation which would make a real many-to-many lossless message sending possible, but also with total control over where the msgs end up in case of multiple readers! Imagine that we have a Channel wire which can be branched, and you can also specify a "destination label" (could be a number, or string, etc.) at the Write nodes. This new Channel type would allow multiple Write and Read nodes. At the Read nodes, we could also specify the "destination label", so ONLY those Reader nodes would get the actual message which are subscribed for that particular "label".

 

I can program this functionality, but it would be great to have such features in a single Channel wire...

What do you think? Is this a good idea or you see some caveats/downsides of such Channel?

It would be great to have possibility to change/edit the code when a VI is running in "Suspend when called mode".

 

This would be a code developer ultimate dream when you are into development of new code or just fault finding in old code.

 

During development or fault finding when/if you are using "suspend when called"-functionallity for a sub VI in your code.

I mean when the sub VI is "paused" and waiting for you to press the "run" button, right there, possibility to edit the code for that VI and run it ones, change the code (perhraps changing some timing or changing a formula of an calculation or both or change execution order for some settings of the DUT etc etc) a little bit and run it again, tweak it a little bit more and run it again... AND THEN exit the sub VI (with "suspend when called") and CONTINUE with the rest of the CODE like nothing have changed!

 

A kind of possibility to change the code during execution, just for  VI/s that you have chosen "suspend when called" for.

 

What a functionality when you are into fault finding and testing out of new developed code! ! ! !

I think that this functionallity would make a big difference between text-based coding and using LabVIEW in matter of how easy development or fault finding can be done.

 

 

 

 

FPGA code allows I/O references to be used so that code can be re-used/abstracted, like this

FPGA-SubVI.PNG

This could/should be extended to cRIO C-modules so that code can be re-used on multiple modules. This would require the 'cRIO Device' property node to return an array of I/O Refnums that could then be passed to subVIs or other modular code.

 

For example, if I have code for an analogue input module (say, NI 9205) which filters and processes the data, and I wish to re-use that code in multiple experiments I have to manually change the module name in each IO constant or node (Mod1/AI0 to Mod3/AI0) if the module moves or I need more than one of the same type.

 

Conversely, if the cRIO Device property could provide the I/O references, the code could accept a cRIO Device constant and the reusable code extract the I/O references. The code would then adapt from Mod1/AI0 to Mod3/AI0 as the cRIO device was changed from Mod1 to Mod3.

 

It would be added to these properties.

FPGA-cRIO-Prop.PNG

 

Thanks,

Richard.

 

Capture.PNG

User Colors 1-16 are now pre-defined by the default LabVIEW.ini file  that leaves us developers with only two.  Why 18 total?  This needs some adjustments IMHO!  It should be easy to implement but, can't be done without hacking the ini editor

There doesn't appear to be any proper place for posting Data Dashboard product ideas, so I'll leave this here and it can be moved if necessary.

 

Data dashboard is a great application that makes portable and continuously monitoring of remote systems more easily accessible. However, Data Dashboard on Windows platforms must be running in the foreground to display shared variables. It would be convenient if Data Dashboard could pin live tiles to the start menu, while periodically poling for variable updates. In this way users would no longer need to constantly launch or switch to the Data Dashboard app.

 

The nature of Data Dashboard seems to mesh well with the "information at a glance" mantra of the live tile interface. Seems like a missed opportunity to me and I would love to see this implemented in the future.

Am I the only one annoyed by the missing pixels on the increment arrow button?

 

The left one is original, on right I fixed it in paint, does it make any sense? Any clue why it's actually like this?

 

System Numeric.png

 

Just reminds me this story of the google logo. http://www.theguardian.com/technology/2014/may/27/google-pixel-perfect-logo

 

 

Why is the property to read the default value a scripting property?

 

If you'd ask me reading the default value should be a normal property...

 

Writing it is scripting, so maybe it should be split up.

My 2 cents: would be nice to have optional tabs on the case structure similar to what we have in modern browsers like chrome. If dont have gazillion cases then this would be a very comfortable way to switch between cases. Arrows at the side shift the cases. The active case is color coded and slightly overlapping the surrounding cases.

 

Warning: MS paint artwork below! 🙂

 

case.png

Aren't you tired or seeing Labview, or LABview or LabView online?

 

NI Certifications (CLA, CLD, etc) should be stripped off people engage in miss-spelling LabVIEW.

 

And those who aren't certified should handwrite "LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench" 10 thousand times!

I'd like to see added to LabVIEW  a 'Retain String Formatting' option for the concatenation operator. This would cause string formatting (the stuff you set with the CTRL-0 shortcut) to be preserved when concatenated. See the example below. This could be added to the right-click properties of the concatenation operator "Preserve String Formatting". An alternate symbol for concatentation would need to be provided so that you could visually tell that this option was enabled when looking at the concatenation operator on the block diagram. Maybe the NBC peacock sitting on top of it?

 

Sometimes setting string formatting attributes programmatically is a lot of work, and inappropriate to the application; simply not changing/removing the attributes would be sufficient... Note that the string formatting attributes are preserved across a cut-and-paste - if you copy the contents of a formatted string and paste it into another string, the attributes are retained. I find the current behavior of the concatenation operator  (NOT retaining string attributes) to be at odds and inconsistent with LabVIEW. After all, it is a GRAPHICAL programming environment, is it not?

 

If I remember correctly, you also lose string formatting attributes when changing a string constant to a control or indicator - perhaps that also could use some thought...

 

NewConcatenate.jpg

Hi Team,

 

Would be Great to add or Delete Input in Array [ Insert Into Array ]. Bit difficult to manage when used for reporting. Rearrange all input nodes if to add or delete a input inbetween.

 

Idea.png

 

 

Many Thanks

Anbu

Hi !

 

Often dealing with old code it's always a pain to install old versions of LabVIEW to get the code compiled the newest LV version.

For example, porting code made in LV 5.0 implies converting first to LV 7, then convert to LV 2009, and finally convert to LV 2013.

You then have to install these version, licences, ...

 

It would be nice to have a service on NI.com website from which we could send a zip archive containing the project to convert.

Then selecting the target LV version, a could service could unzip and compile the code across all versions of LV to have the code matching the requested version.