LabVIEW Idea Exchange

Have you ever created a cluster like this?

I have. Numerous times. It's fairly easy to create clusters which get out of hand. The magic number is usually around 10-15 elements, assuming some of them are clusters as well, but even if those numbers are manageable, I've also created larger ones, and those aren't manageable.

Using LVOOP mitigates this to some degree, but does not solve it completely.

So, it would be great if we could divide the cluster into "pages" or "categories":

This will allow us to logically divide the cluster into manageable areas.

The names of the pages will appear in the selection list and in the unbundle node, as shown in the example (although you could hide them in the node by unchecking the full names option), but they will NOT actually be part of the element's name. Changing the name of a page or moving an element from page to page will NOT require you to change code which already uses that element.

Notes -

1. In my mockup I used a tab control. I understand that LV R&D has some aversion to the concept of tabs inside clusters, so I would like to make it clear that I'm NOT asking for a tab inside a cluster. This is purely a cosmetic and organizational feature.
2. I already posted this as a comment on this idea, but I figured it was worth posting as a separate one.

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

It would help a lot if we have an option called pause on first Error. So that the VI at the node/primitive that generates the error and highlights that node so that user decides to continue or abort.

Back in the NI-CAN days, there was a handy development tool which was the usage of two virtual CAN ports, ports CAN256, and CAN257.  If you wrote a frame on one, it would be read on the other, and vise versa.  Other CAN hardware like Vector, and Kvasar support virtual CAN hardware which does something similar, where initial development can be tested before having access to the hardware.

This idea is to add virtual hardware support for XNET which supports this same feature.  it has been talked about in a thread here several years ago, but nothing ever came of it.  Adding support for virutal hardware for CAN, LIN, Flex-Ray and any other XNET hardware would be a great development tool, and enable the testing of the expected handshaking of software, with simulated communications.