LabVIEW Idea Exchange

I would like to have an option to export a simplified image of a graph directly into png. The image formats available in LV2010 are bmp, eps, emf and pict. Png is superior to bmp with rougly 100-50 times smaller file sizes. At the moment if I want to export a simplified image of a graph to png then I have to use the extra code below or alternatively export the image to clipboard, paste that into a graphics editor an save it to png. It would be much more simple to have an option to directly export to png. My suggestions below:

When I connect something to the output of a Select node, I would like the input types to be updated to the connected output type.

For example, if I connect an enum to the output of my select node - if I "create constants" on the inputs, it should create the same enum type instead of a double. Similarly, when I connect a string to the output, I would expect the inputs to be strings as well.

If there is a conflict with the compiler, perhaps it could use whatever was connected first (input or output).

Help! I need a way to pack more Classes onto my Block Diagrams!

This idea is simple and quite subtle- reduce the size of the Class Constant on the Block Diagram. The majority of the footprint belongs to the Class Icon, which cannot be sized smaller, but the additional border graphic that creates the "Object Cube" effect can be reduced to give a total footprint of 42x42 pixels down from 48x48 pixels. (If you're counting, that's a 42% reduction in "fluff", discounting the 32x32 that must remain!)

If you're not crazy about the first-draft artwork, feel free to post a new rendition in the Comments section!

Many or most VIs that ship with LabVIEW have their protection set to Unlocked (no password). The screenshot below shows a selection of such VIs.

It would be much better if the protection of vi.lib VIs was set to "Locked (no password)", to prevent accidental modification.

It seems very risky for built-in VIs to be open to modification, especially to accidental modification.

Scenario 1: Developer A is developing an application on their machine which contains modified vi.lib VIs which were accidentally modified as part of work on previous projects. They build an application which passes validation and starts to be used in production. All of the developer's source code is committed to a source code repository. Developer A leaves the company. Six months later Developer B is asked to pull the code from the repository and add a minor improvement. The application behaves very differently when Developer B builds it on their machine. A long and complicated troubleshooting session later, Developer B concludes that the different behaviour was likely caused by modified vi.lib VIs on Developer A's machine. Developer B cannot be sure, because Developer A's machine was wiped when they left, so there is no way to unequivocally prove the conclusion.

Scenario 2: A team of developers builds a test system for a defence application. The code is completed, and the test system is put through a thorough  commissioning and validation process that involves testing dozens of known good units and known bad units. The validation process takes three weeks to complete. Management plans to not have to run the whole validation process for future minor changes. Instead they will ask the development team to perform code reviews and record notes for each minor change. Revalidation is not necessary if the code reviewers agree that the changes are non-functional, for example, the wording was changed in a dialogue message, or a logo was added to the UI. This sounds like a great plan, but is technically unsafe. Strictly speaking the whole revalidation process would have to be rerun, even for minor changes, due to the fact that not all of the source code is visible in the repository (there is uncontrolled source code in vi.lib that could have been modified in between builds).

Essentially I don't think it's safe for an app to contain source code that is not visible or tracked in a repository.

I can't think of a simple, quick solution to the concerns above, but having all vi.lib VIs set to "Locked (no password)" could be a quick first step towards reducing the likelihood of this issue. Developers would at least have to consciously edit vi.lib VIs, rather than doing it accidentally which can happen now. Of course, a malicious actor could still wreak havoc by editing a few inconspicuous vi.lib VIs.

The risk would be reduced further if the vi.lib VIs were password-protected. This would come at the expense of not being able to view the source code of native VIs, something which I find useful. Therefore, I personally would prefer "Locked (no password)" to password-protected, but I might prefer password-protected to unlocked.

Similar concerns apply to non-NI third-party libraries that install in vi.lib, user.lib or instr.lib, for example the extremely useful OpenG libraries. These too are examples of uncontrolled source code. For this reason some developers I worked with preferred to copy the OpenG and other libraries into the project repository (this involves a tedious job of opening each library VI and relinking it to the other library VIs in their new location).

This idea is similar but potentially easier to implement than the following idea: Make the VI's from the "vi.lib" Read-only - NI Community

Thanks

I think the Array Element Gap should be sizable. This would facilitate lining up FP arrays with other items on the FP, or simply as a mechanism to add more apparent delineation between elements.

The size should be set in the Properties box, not by dragging the element gap with the mouse - that would add too much "cursor noise".

A new Property Node for this feature would complete Idea.

Hello,

Being able to rotate some indicators, controls, graphics or anything else would be great in my opinion.

Indeed, for example, when you have to represent an electrical circuit in your HMI, you must have several images of the same component with an angle of rotation of 0°/90°/-90°/180°.

So allowing a LabVIEW user to rotate some elements with an angle which could be set, would be more convenient.

  Four images for one element. If we have 2.000 différent elements we must store 8.000 images.

 For Example