07-09-2023 05:37 AM
Well, I could easily do a vim that uses one or the other, depending on type but it's probably not worth it. 🙂
07-09-2023 05:50 AM
Considering the potential problems you can get with vims, such as hard to debug build problems especially for realtime targets, complications when they are included in ppl’s and similar, I still try to avoid them when there is no VERY compelling case for them.
I’ve had to replace out of the box vims in RT applications to fix build problems and or inability to load an rtexe or ppls on cRIOs on multiple occasions.
07-09-2023 09:58 AM
We're currently underway removing VIMs from our code base so we can do PPLs and plugin architectures...
07-09-2023 02:21 PM - edited 07-09-2023 02:27 PM
I have found that vims not automatically and necessarily preclude usage of PPLs as plugin architecture but it sure increases chances that the build of such plugins will at some point fail. My most recent experience was with a large plugin architected system with classes inside PPLs to be run on Windows and cRIO. Windows had no problems, cRIO worked fine too until I tried to build it on my own machine with, as far as we could determine, identical installation. Suddenly certain PPLs would not load anymore. Building on the original machine still produced runnable code. After two days of conquer and divide with compile disable structures, rebuild and reinstall and run, I got it isolated to the inclusion of the LabVIEW provided variant type parsing library in two different PPLs. In there is a vim. Since we had other code using the OpenG variant parsing library externalized in its own PPL I replaced the relevant codes with equivalent functionality from that OpenG library and everything worked.
Conclusion was that vims inside PPLs can be problematic but it depends on what ghosts live in your system if they cause problems or hide in the dark until some magic hiccup wakes them up!