LabVIEW
LabVIEW block diagram (constrained/simplified) as deployed application UI or embedded scripting interface for "interpreter" at runtime
I have had this idea/thought for years (may have even posted about it before, don't remember). My field has a certain paradigm/use-case where an end-user/deployed app interface similar to the LV IDE's block diagram would be utterly amazing. The way I envision this is that a user would have this block diagram with a palette set that is limited/determined by the developer at edit time, yet also expandable via a plugin-like architecture. It would have the same sort of wire/dataflow paradigm. Likely other constraints would need to be designated by the developer. The idea is that the end user would use it almost as a visual scripting engine, and the LV "interpreter" (which could simply be the same engine LV uses to compile code in the background and allows us to run a VI in the IDE) would be embedded in the deployed application and be able to execute these user created diagram "scripts".
It actually seems relatively easy for this to come to reality, all of the foundational blocks have already been created by NI, including the BD editing interface which is probably the most difficult or impossible aspect to recreate for an LV developer. I realize one might say, why not just deploy the full dev IDE. The point is that it needs to be constrained/limited, the intended end-user being more of a highly experienced "power-user" but not a full-blown programmer.
Has NI ever given this any consideration? It's literally the same as many applications which have an embedded VBA/Jscript/python/C#/C interpreter engine that is utilized to run user scripts.
I've used a few products in my field that attempt this using things like flow diagrams from various commercial UI libraries (for other languages). None of them are as powerful or nice as the LV block diagram UI. In my ideal world the solution would be a little cleaner than the LV BD UI, it would be more like the NXG BD UI.
Curious whether this is a viable idea. Any thoughts? Any existing things out there that are similar? Something like NodeRed comes to mind but I don't have any experience with it and have a feeling it's not quite as powerful or flexible as the LV IDE.
The only working solution which I have seen is GCalculator from VBAI:
This is a very simplified "LabVIEW" with just few basic functions embedded into VBAI UI as child window. LabVIEW development environment is not requred to be installed as far as I know. Internal result of this step is VI with defined Inputs/Outputs, which later called dynamically.
Update. Today by morning coffee break got this, because was very curious how this was done. And the answer is simple — this is "special" LabVIEW Run-Time version deployed together with VBAI called lvffrt.dll.
For example, if I will try to open Block Diagram of the VI programmatically like this:
then in Run-Time when compiled to executable obviously we will get error 1026:
because this method is not officially available in Run-Time:
Well, now if I will install latest VBAI, then "Full" Run-Time called lvffrt.dll will be installed into "C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\2023" Folder, which is in the fact LabVIEW 2023 dev environment in DLL form:
The next steps are the following:
- copy full contents of the "C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\2023" into the same folder where builded application is located (so, the lvffrt.dll and application will be located in same directory).
- rename lvffrt.dll to lvrt.dll (because our app linked against lvrt and not lvffrt)
- copy Menus folder from "C:\Program Files\National Instruments\Vision Builder AI 2023" to the same directory.
Now the "BD Window Open" method will be successfully called also from executable and editable Block Diagram can be opened in builded application and basic functions are available:
The rest integration is just technical things, like getting and setting controls and indicators programmatically, embed BD Window into app as child Window using WinAPI etc. It is an interesting internal experiment, but on the other hand from legal point of view you should not distribute DLLs in such way and use it in production.
Side notes. The same version and bittness of LabVIEW shall be used as was used by VBAI (LV 2013 in this case), otherwise you will get the following error in attempt to run this app:
Also I think it could be theoretically possible to turn LabVIEW.exe into lvrt.dll by modifying the PE File Header and patching the entry point, so it may be possible to achieve this without VBAI installation also for the latest LabVIEW version (but again - tampering of the NI's binaries is prohibited by license agreement, so it is a good and interesting exercise, but no go to production).
Another possible way is to build own "scripting" BD Editor is using Picture Control (like was done in the past in Lego Mindstorm powered by LabVIEW, or old State Chart diagram editor), but this is huge amount of work, of course, and it will be not so good "responsible" from GUI point of view as original LabVIEW Editor due to low drawing performance of the Picture control.
