It is time-consuming that we have to compile all LabVIEW FPGA code even if there is tiny little change on FPGA code.
I understand there is sampling probe, Desktop execution node and simulation tools to reduce such time.
Our customer in Japan, would like to use incremental compile function also on LabVIEW.(Please see below)
I agree his opinion.
What do you think?
Application Engineer at National Instruments Japan.
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...
As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.
The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.
The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.
The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.
and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :
I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea:
"Here is a work around if you want to play around in the Windows registry:
After we have gotten several different new tunnel modes, it takes quite a lot of context menu exercise to change tunnel mode on structures:
I propose a shortcut where we can click directly on the tunnel to toggle between valid modes:
I say valid modes as not all modes are valid for all tunnel data types, for instance the "Concatenating" mode isn't allowed for scalars, but is still selectable in the context menu resulting in a broken scalar wire leading to the concatenating tunnel - the toggle should perhaps skip such an invalid setting? Or maybe not, in case you're preparing to change data type and just want to toggle the tunnel first, I don't know.
Tunnels on different structures have different modes. On case and event structures the modes you could toggle between would be 'Use Default If Unwired' on/off for instance.
Am I the only one feeling there's a long way into the tunnel mode menu now?
This is an elaboration on a prior request by RavensFan:
When AppBuilder reports a file related error, such as error 8, could someone please provide a path?
I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.
I can't probe a path wire in the AB method because the diagrams are understandably locked.
This is so frustrating. No one likes to debug by guessing and it wastes a tremendous amount of time.
Thank you with my deepest respect to the AB team.
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.
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.
When entering debug mode (turn execution highlight on) it can be hard to see what is happening.
With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...
SubVI's get a green arrow when they are executing. So, could structures get them as well?
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.)
If you have open the Bookmark Manager and
you change one bookmark, the Manager gets an "Bookmark Info Change" event and reloads all bookmarks from all
VIs in the project. The event that triggers the update is the
application event "Bookmark Info Change". At this event there is no
info in which vis a bookmark has changed. If the event would provide the info which VIs have changed,
the Bookmark Manager would be able to reload only the bookmarks from this particular vis.
On larger projects the Bookmark Manager needs minutes (Time and CPU
load) to update the whole list. The additional event data node can be an array of vi names or references.
This changes will fixed also the EventQ Problem of the Bookmark Manager. If the Bookmark Manager is open and you change several Bookmarks the manager reloads all VIs for x times because everey change generates a "Bookmakrs Info Change" Event.
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/
Using ctrl + scroll for switching between the cases is somewhat hard to use, because when you have lots of cases its difficult to remember what is the order of them so its harder to ctrl scroll the one you looking for than to go to the case selector. Moreover if you work with bigger sized structures (which happens sometimes) you may not even have the case selector on your screen so if you ctrl scroll, you can only deduct which case you see by the visible part of the code itself. That doesnt work for me, I always go to the selector.
But what if when the user uses ctrl + scroll a small popup would appear at the mouse pointer and when the user scrolls up and down the highligh would move up and down selecting any case in the given structure?
This would highly increase the usability.
Applicable to the Event structure as well.
It would be really cool to have a custom probe that could be placed on any cluster/class wire to view the data in the cluster, but instead of being displayed as a standard view of the cluster, the labels of the items would be listed along with the data type and the current value (works for scalar or small arrays, not so well for large arrays/waveforms). The standard view of a cluster probe is shown below.
I built a custom probe to do this but found that the data type of custom probes is strictly typed and therefore I have to convert my data to variant on the vi block diagram before adding the probe, which isn't great. I've attached the code for my custom probe, and a screenshot of it below.
If variant custom probes could be used on any data type, this would work.
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.
I recently noticed that some of my fitting model VIs were excessively large on disk. It turns out that during debugging long ago I made the current values the default so I can run it standalone. This also meant that the data variant control contained a gigantic kernel matrix.
For some reason it is not obvious how to clear the variant (in order to be able to make the new value default and make the VI small again).
For example for the nonlinear fitting model templates, the data is not shown by default, obscuring the fact that it is the culprit for the excessive size. This also makes clearing the variant tedious (right-click...show data...select all data...delete...right-click...uncheck show data...).
IDEA: I propose a new menu entry: "Right-click...data operations...Clear Data" or similar.
See picture. Thanks!