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.
I would like the option to save data from LabVIEW using the Hierarchical Data Format. This would make it much easier to share data with Matlab and other programs.
This is a real pain point for us at the moment and drives many of our engineers away from using LabVIEW, quite rightly. The tdms import dll for Matlab is slow and the 3rd party .mat export toolkits for LabVIEW are not sufficiently developed or only licensed for single-seat environments.
I use single process shared variables quite often and I am always amazed how much space the take from the block diagram. As they requires room I either make long VIs or play with the wires. Not good...
The current situation:
So why dont we have something similar than what we have with property nodes, but applicable to the variables we have in the project? Each variable can be set to read or write, same as the properties of a UI element.
The proposed solution:
I dont have too much experience with locals and globals, but I guess this idea could be applicable for those as well.
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...
Grouping objects on the front panel is helpful to avoid inadvertently destroying a UI's layout.
Unfortunately it comes at a cost: if you want to access block diagram counterparts of any of the objects in that group, you have to first ungroup them, select the object of interest, right-click and select what you are looking for, go there... and hope you won't forget to regroup the objects when you are done.
Surprisingly, you can actually access an individal's object properties and in fact access pretty much any of the right-click contextual menu items BUT the "Find" one. So no "Terminal", "References", "Property Nodes", "Invoke Nodes", Local Variables" access...
If there is no fundamental reason for this, please consider this as a request.
It would be very handy if there was a way to get the descriptive text 'out' of an error ring constant. It might not be possible on an error control/indicator since it (presumably) involves a (database) lookup of some sort, which may not be available at run-time on certain targets, but for an error ring constant, it should be possible to pass it into a "format into string" just like you can do with enums to get the string.
This is similar to, but not the same as this idea on the format into string taking the error cluster
(Note that currently, there is no way (that I can think of) to get the "descriptive" text that you can read some of above ("Not allowed whil...") from the error cluster/constant, which is rather anoying.)
Currently, there are only modern and silver I/O controls (as of LabVIEW 2011 SP1). This is great if you are developing a GUI with those types of controls but it doesn't work well if you are using system controls for your GUI because of the inconsistent look and feel. It would be really nice if every I/O control had a system version as well as modern and silver versions.
This is pretty trivial and not going to revolutionize LabVIEW, but how about a right-click option on the "Boolean to (1,0)" function that allows you to select the type of the output? It just cleans up the diagram in a case like below by avoiding the coerce function.
it would be useful if the FOR LOOP had an indicator which is set to true on the last iteration of the loop. This terminal could also be set to true if the conditional terminal is used to abort the loop.
My use case:
If have various "channels" (Bits and Bytes) over which I communicate with an external ProfiBus device. These channels are identified by enums. The data values themselves are organized in a predefined numeric array in a FGV, and depending on the enum value I replace parts ("chunks" of bytes) in the array.
In most cases, I have to update more than one parameter in the external ProfiBus device. I change the values in the data array FGV using a for loop, and after the last array subset replacing action, that is in the last iteration of the loop, I actually transfer the new data array via an "update ProfiBus" notifier.
To "detect" the final iteration, I could check "i < (ArraySize - 1)", which means to have this additional (tiny) piece of code in each iteration. Another option - which I currently use - is to provide an addtional array to the loop with just as much boolean elements as in the "channel enum array", in which only the last element is set to true, to set the "update notifier" only once.
To make it short:
Please provide an additional for loop indicator which is set to true in the last iteration of the loop.
Can we include a Temporary File Path terminal to NI_HTML.lvclass: Print Report.vi, and consequently NI_ReportGenerationCore.lvlib: Print HTML Report.vi.
NI_HTML.lvclass: Print Report.vi will merely pass this path down into NI_ReportGenerationCore.lvlib: Print HTML Report.vi.
In NI_ReportGenerationCore.lvlib: Print HTML Report.vi, if Temporary File Path is Not a path, then continue to create a temporary file path. If it does exists, then add some code at the end to clean up the temporary file.
So today it seems that my company has reached a critical enumerator value of 2147483647. It caused some trouble since I'd never expect a "%d" to be restricted merely to 32-bit signed integer! A provided picture shows a solution to a problem, treating a number as 0-precision float.
Also, what kind of idea is to coerce an input value into the range unrelated to input's data type?
I use LabVIEW 2011 SP1.
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?
Just reminds me this story of the google logo. http://www.theguardian.com/technology/2014/may/27/
A version control system is a must these days, but rearranging project files in LabVIEW is a nightmare without integrated support.
The correct way to do things is in LabVIEW rather than the file manager to save creating headaches and conflicts in LabVIEW.
The correct way to do things to maintain subversion history and minimise headaches related to subversion is in the file manager using subversion tools (e.g. TortoiseSVN).
So without subversion integration, we are damned either way.
Please provide a way we can get this support without doubling the cost of all our licenses by upgrading to Professional for this one feature (management will never go for it) . Please consider adding it to cheaper versions, or at least make it available as an optional addon for a reasonable price.
According to Wikipedia:
In some languages a class may be declared as uninheritable by adding certain class modifiers to the class declaration. Examples include the "final" keyword in Java or the "sealed" keyword in C#. Such modifiers are added to the class declaration before the "class" keyword and the class identifier declaration. Such sealed classes restrict reusability, particularly when developers only have access to precompiled binaries and not source code.
The sealed class has no subclasses, so it can be easily deduced at compile time that references or pointers to objects of that class are actually referencing instances of that class and not instances of subclasses (they don't exist) or instances of superclasses (upcasting a reference type violates the type system). subtype polymorphism. Because the exact type of the object being referenced is known before execution, early binding (or "static dispatch") can be used instead of late binding (also called "dynamic dispatch" or "dynamic binding") which requires one or more virtual method table lookups depending on whether multiple inheritance or only single inheritance are supported in the programming language that is being used.
I have previously made appeals to allow for certain classes to restrict the ability to load new ancestors at run-time, thus restricting possibly allowing for inlining of dynamic dispatch VIs. A similar request has already been made in order to facilitate ilining of DD VIs. I believe that ultimately, it is support for a "Final" or "Sealed" class what I am looking for.
Such a modification on a class would effectively prohibit instantiation of any new version via factory method and would declare to the compiler that the code defined at compile-time is actually the full extent of code which will be available at run-time, thus allowing for the aforementioned optimisations to take place.
Questions would have to be answered regarding type propagation and some loopholes may remain regarding dynamic loading of new classes (only dynamic dispatch methods which are visible as instances of the "final" class can actually safely be inlined for example). Especially for a specific RT application of mine, this would be a great benefit as the natural progression of this idea is indeed the ability to write code such that dynamic dispatch VIs are actually inlineable.
Very often there is the situation that I have to insert an illustrating drawing my front panels. Most of the time I have the problem, that those graphics does not have a transparent background. It would be great if the Coloring tool could be used to change the colors of the bitmap to transparent but also to other colors. If you integrate such a function please also think about a local / global option in the color dialog.
What I'm suggesting is a combination of an textring and a string control (BD-terminal is a string). The idea behind is, that I like to offer the user a list of pre-defined values (e.g. the values from the five latest program runs) but also the ability to enter a new string.
Of course I can get this functionality by adding two separate controls or by combining those in an XControl but I feel the combination would look better, is much easier to handle in the code and needs less space on the UI.
Please see the picture for better understanding.
First of all - if there's a QuickDrop shortcut or any other feature within LabVIEW that already does what I suggest here, I'll be glad to be pointed the way to it. Thanks.
During testing of programming appoaches I often code a bunch of stuff that should simply work and then break it down later into several SubVIs for better readability, maintainability and reusability. Doing so leaves me with the fact that LabVIEW determines
of controls and indicators of the newly created SubVI by itself, e.g. like this:
So now, to get things organized, I open up the new SubVI and start renaming all the controls and indicators and repositioning their respective connectors to my heart's desire. This can get a little tricky as LabVIEW generally chooses quite ambiguous names for the connected FP elements, as can be seen in the picture above. So what I do now is open the caller of the SubVI and the SubVI side by side to identify the in-/outgoing wires with their respective names and connectors and modify them to get everything straight.
My idea therefore is to insert additional shortcut menu entries for renaming and swapping position of SubVI connectors, just like "Create >" or "Replace >" (see picture below)
The renaming could probably be done via QD - type the new name for the connected control/indicator in the QD text field, press the desired shortcut - done.
The swapping could possibly be easier to get implemented using the functionality the connector block of a VI (and several function nodes) features natively - CTRL+mouse click activates swap mode.
Glad to hear your opinions on this.
When hovering over a global variable in LabVIEW, the IDE doesn't really give us much information at the moment. What I would like is to have the context help show me the path and filename of the global in question within the context help. This would help debugging a lot.
And while we're at it, at least show the datatype of the global in the context help. At the moment, the only thing shown in context help is the name of the global item selected, but I already see that ont he BD. D'oh.