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:
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.
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.
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.
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.
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?
Sometimes I do dumb things. One example is that I often forget to stop running an executable before attempting to rebuild it. The AppBuilder eventually fails because the file is locked--it can't delete & recreate the *.exe file if it is actively running--but sometimes it takes several minutes before the AppBuilder gets around to checking that. It would be nice if it did the file permissions check earlier in the process, so my foolishness doesn't slow me down excessively.
Also, since the "cancel" button for builds doesn't actually do anything, even if I notice it immediately, I'm still stuck twiddling my thumbs for a few minutes until the AppBuilder *realizes* it can't complete the process....
When working with DVRs, i find it always a little cumbersome to create the DVR control and indicator for subVIs or data container (cluster, class).
I suggest to have a "DVR shell" available for front panel with no data type contained in the DVR. Dropping the DVR shell on the FP would break the VI, just like cluster and array shells already do.
The main reason for this suggestion is that dropping a data type in the DVR control/indicator already changes the DVR, so it is easy to "adapt" it to type.
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.
Could NI please consider automatically including all the items from the "Execution" category of the VI Properties editor in the help window documentation. This would make it much easier to determine if priority/execution/thread setting is correct, and greatly help with reentrancy/INLINE status. That would be really useful for FPGA development, which selects reentrant by default, when other platforms do not. Currently, a LOT of mouse thrashing is required to confirm status of all subVIs.
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!
After you selected a shared var, local var, ... it should be possible to use a shortcut (ctrl+x) to switch between the read and write option
I find myself constantly tweaking my wire labels so that they look like they are exactly vertically centered on the wire, rather than a couple pixels higher or lower. They are not always created that way, and of course when you move the wire around they don't stay that way like I wish they would.
I'd like to propose an option to have LabVIEW automatically force wire labels to stay vertically centered on the wire (similar to other "snap-to" label positionings). I know that other programmers prefer other positions, such as immediately above the wire, therefore having it snap to that position would be another option. I'm not sure if it makes more sense to select one position that it always snaps to, or have it snap to one of a few options (like labels on controls do now). I always use them consistently in the one vertical position, myself.
It may make sense to have the default be free-positioning as it stands today, but it would save me a non-trivial amount of time to have the option for it to be always enforced to what I think looks nice. Hopefully I'm not the only one!
Initial vertical position when I select to make the wire label visible (looks terrible!):
The vertical position I always want it to stay in:
An alternative snap-to vertical position:
Currently on a functions palette item (when you edit the palettes) you have the option of placing the VI contents as an alternative to the default behavior of placing the VI itself on the block diagram:
I suggest two additional options in this menu: 'Open VI' and 'Run VI'.
Two such options will enable us to bundle help-VIs, scripting VIs and examples directly in a sub-palette of toolsets, instead of going the long almost impossible way of building bin3 files for the Example Finder.
One of many current use cases we have at GPower is the ExpressionTester in our Expression Parser toolset:
The ExpressionTester is a utility, a small application actually, that lets the user investigate different mathematical string expressions before committing them to code, and it has no use as a subVI. We feel it has the highest chance of user discovery when positioned just with the toolset functional VIs (i.e. in the palette), instead of being buried either on disk available through a link in the detailed help file, or in a Tools menu item. But to use it from the palette today, the user has to drop it on a block daigram, open the subVI and run it. And then remember to delete it again from the block diagram, preferably with CTRL+Z to avoid contaminating the undo-stack. If we could mark that palette item as 'Run VI' then clicking it would just start the ExpressionTester utility.
Perhaps palette items configured to being opened/run/content-dropped instead of the default action should have some sort of indication on it, that clicking it executes a non-default behavior?
Today, when you change a numeric control not to use the default limits, it allows you to enter your new limits, but it doesn't actually respect them unless you change the response control on the right side, which can be easy to forget.
I propose that the default value of the controls should be "Coerce", not "Ignore":
This makes sense, because if the user unchecked the check box, they probably want the limits to coerce and in case they don't, the limits already default to the maximum range of the data type, so they can't be coerced unless the user changes the limit value anyway.
I would also suggest considering that if the Response control is set to Ignore, the value should be disabled and greyed, to inform the user that changing it won't actually do anything. I would suggest getting rid of the Response control entirely, but it can be relevant if you only want to change some of the limits.
I would also consider changing the coercion of the Increment to Nearest by default, since it's probably the most common option, but that could be debated.