I was trying to isolate two versions of code by putting them in a "Version 2.0" and "Version 2.1" library, and then (at run time) calling the appropriate analysis routine from the "correct" Library based on values stored in the data. In the process, I managed to corrupt the .lvlib file, and (because I didn't know better) tried to "correct" this error by deleting the .lvlib file.
What that left me with was a file, formerly in the library, that I couldn't open without LabVIEW complaining bitterly that it could not find "Untitled Library 1.lvlib". In addition, I could not even create a new Project and "Add" anything without such an error message appearing.
After a few weeks of struggle and consultation with NI Support, we found part of the problem -- the file that was formerly in the (now-deleted) Library had "hooks" to the Library embedded in its header. Since this is in a proprietary (NI) binary format, I would like NI to provide a utility that can open a VI (or anything else that can be embedded in a Library) and remove the "hooks" that associate it with a particular .lvlib. If this function were a LabVIEW function, then the user could write a utility using this function to apply it to a file, a folder, or a directory tree, as the situation warranted. This would allow large VIs "corrupted" by being placed in, and improperly removed from, a Library to be returned to a stable, non-Library, state.
When we put a breakpoint inside a repetition structure LV runs the code inside loop before it stops. If we want to break before the 1st iteration we need to add a breakpoint outside the structure. The current way doesn't communicate the actions properly. I propose a slightly different way to communicate it:
The left border acts as the outside border and the other three as the inside current one.
I would like to receive events that are generated by another program in LabVIEW executables. For example if another program tries to close my application with "CloseMainWindow" (see https://msdn.microsoft.com/en-us/library/system.di
It would be great to receive such an event in the LabVIEW event handler to make it possible to ask the user if the application should be terminated, files saved, close openend ressources etc. (like the events "Application Instance Close?" (http://zone.ni.com/reference/en-XX/help/371361H-01
From within the Project Explorer; it would be very useful to have the option to add a text file (*.txt) to the project, class or .lvlib.
At present the options are, as shown below:
Adding text files will give the developer a simple method of creating documentation notes, that can be copied and pasted later.
[admin edit: updated title of idea to make it more clear that creating a new text file is the goal]
Retina displays on macs are really nice to work with, the details quality is a real plus, it would be nice if LabVIEW could take advantage of that, for now LabVIEW look really blurry & ugly on a retina display.
See the difference between LabVIEW and GitHub :
Zoom on LV :
Zoom on GitHub :
In Diagram Disable Structure, if there is an optio
Connecting Enable/Disable as Constant/Control to C
Diagram Disable Structure have unique behaviour if
As programmer myself felt that why do this be cont
In LabVIEW 2014, sbRIO-9651 projects need a FPGA socket CLIP to be selected.
This FPGA socket CLIP can be user defined to select aspects like available FPGA pins.
By default, a user defined FPGA socket CLIP is saved in the National Instruments installation folder
or in the National Instruments user date folder. In other words, these FPGA socket CLIPs are not
saved with your LabVIEW project. This means you can forget to keep them by putting them under
configuration control (happened to me when my PC hard disk was changed) and other users will
not be able to use your LabVIEW project if you forget to provide the FPGA socket CLIP used
(happened to me when sharing my projects with NI engineers).
My suggestion is default behaviour of the CLIP generator should be changed.
This tool is used to select or create a sbRIO-9651 FPGA socket CLIP when creating a LabVIEW project.
I propose this tool should always save the created/selected CLIP under the project folder.
This would help to ensure the LabVIEW project contains everything associated with the project.
Optionally, it would helpful if the LabVIEW project dependencies showed FPGA CLIP usage.
I have unknowingly had a project using another's projects CLIP (especially when the CLIPs have
the same name).
If I have an enum or ring with lots of items, rearranging these items with the editor screen is a pain because it is fixed in size. In particular, the table where we can reorder the items needs to be bigger. Preferably, the whole screen needs to be resizable.
In my experience, it is far more common to write to property nodes than read from them. For example, I often enable and disable controls, but it is much less common to need to check whether they are enabled or disabled. So when property nodes are created, could they be in "write mode" by default?
The upper left corner indicator for type definitions on the block diagram is really useful, but that breaks down a little when you are using type definitions in an array. It's generally better to type define the element, not the array itself, but the array icon or terminal doesn't show anything to indicate that the contents are defined. How about putting the black upper left corner inside the bracket (for the indicator/control) or inside the frame of the icon? That would still show that it's an array, but would make it clear that the content of the array is linked to a typedef.
The Table is an important UI feature allowing cell widths adapted to the contents (a bit like in Excel). That is much better than the rigid array front elements. It is also much more powerful since cells can be coloured, cell fonts can be changed, cells can be highlighted and still more. Some possibilities appear to lack:
1 There is no 1D version of it. This necitates the user to finely adapt the height to see only one row. This makes that no dark grey line is around it and a user can accidently change to lower lines by selecting a cell and some mouse operation. It is hardly possible to return backward, certainly if the user is not aware that the line is in reality a 2D field. Under properties e.g.' 1 row, 10 columns' can be given, but that does not prevent changing to other rows. For arrays dimensions can be added (from 1 to many), for the table dimensions 1&2 would be helpful.
2 Cells can be indicated with help of the properties 'selection start', 'selection size' and 'selection color'. The selections can not be programmatically disabled and re-abled when needed. At least a corner element remains if the 'selection size' is reduced to (0,0). With the right-click menu options a 'show selection' option exists for enabling and disabling the feature. It lacks as a property node.
3 Cells can be coloured with help of property node calls, what is nice. The method to undo all colourings and other settings does not exist. The invoke node method 'reinit to default' has no influence on the individual cell fonts, cell colours, etc. An invoke node to reset these features is wanted as well in addition to the existing reinitialisation. This lack is preventing using these features since the changes should be kept in memory somewhere to undo, or all cells have to be overwritten periodically with a lot of code. If the table length is undefined since e.g. measurement data is put into it, then an arbitrary number of rows have to be assumed. A reset function can take this trouble out of hands.
The same remarks hold probably for the listbox controls.
I have been using unit test framework testing for FPGA code (although you do have to manually bind everything!)
This would be significantly easier if unit test framework would support fixed point numbers, currently I have to not test or create wrappers for much of the logic.
[admin edit: updated title to more clearly reference FXP data type]
I have recently been using more test vectors in the unit test framework.
The principle works well but if you are in a unit test and decide you need a test vector you must:
This seems convoluted and forces unnecessary context switchs.
I propose that at a minimum, you should be able to create a new vector file and launch it's configuration without leaving the unit test configuration window. I suspect that the whole process could be streamlined even further though.
Add a LabVIEW application method or property that would allow us to set the object of the context help so that we can specify a VI from a tree based browser (much like the Project Window does).