I'm having some weird issues with a DQMH module when it's in a packed library. I saw a variety of issues when building the library but after repairing my LabVIEW 2020 SP1 install and reinstalling the DQMH toolkit I'm able to build a packed library successfully
The problem I'm seeing is that the main.vi of the module is broken so it won't start up. It's fine in LabVIEW but becomes broken in the library. I tweaked the Source File Settings for main.vi so I could look at the block diagram, and everything appears OK - there's no errors in the Error List and the code looks fine as far as I can see
This is in LabVIEW 2020 SP1 64 bit, Windows 10 64 bit in an Azure VM, DQMH 5.0, OPC UA 64 bit
It seems similar to what's happening in this thread: https://forums.ni.com/t5/DQMH-Consortium-Toolkits/Problems-running-executable-with-DQMH-made-into-PP...
My module is a little complicated as it uses child modules to handle some of the comms with the PLC, as there's a number of identical test fixtures in the system
Things I've tried so far
- Split the project into two and build the two DQMH modules as separate libraries. Now I have two packed libraries that are broken. I wasn't certain having multiple modules in a library was OK
- Removed all of the OPC UA calls from both modules. This 'works' - both the main.vis are now unbroken and start up as expected, but then I have two modules that don't do anything useful
- Built a packed library containing a single simple VI that calls OPC UA in a similar way to the main module. This works fine so the OPC UA library should work OK in a packed library
- Cleaning out the Compiled Object Cache. No effect
- I can rebuild any of the other modules in the project into their libraries and everything works as expected, so I *think* my LabVIEW environment is OK
- I tried turning on 'Exclude dependent shared libraries' which causes ni_opcua.dll to be copied into the build directory but doesn't change the way the packed library behaves
Sorry this is a bit of a brain dump. I had this nearly working a few days ago with a version of the packed library that wouldn't open in LabVIEW, but TestStand would open on the second try, so I was able to get everything kind-of working
Solved! Go to Solution.
Rubber duck debugging to the rescue
So I dug into the code in the packed library and it turns out there was a broken subVI under main.vi, it just wasn't visible at all..
I originally added a call to FP.Open inside of Start Module.vi, using the static reference to main.vi. This was how I was able to see that the main.vi was broken. I set the build spec to not strip out the block diagram, but LabVIEW still showed no error information other than the broken run arrow
I then changed the Access Scope of the main.vi in the module's lvlib to Public. After doing this and rebuilding the PLL, I could open the main.vi in the library and now there's an error - a subVI was not executable .. finally some useful information to go on
So I set the offending VI to include its block diagram in the PPL so I could look inside, and after rebuilding the PPL, the main.vi is now OK - even without doing anything else to the broken subVI
I tried turning block diagram removal back on, and main.vi broke in the PPL - so this looks like the culprit. I set it to off again, and restored main.vi's Access Scope to private. So long as I have the block diagram for this particular subVI included, everything works. Not sure what's special about this subVI in particular though
OK so I'm not quite out of the woods yet
The PPL works fine in LabVIEW, in TestStand not so much
TestStand is also 2020 64 bit
Main.vi is showing up as broken, TestStand seems to have done something to the VI as I can't show the block diagram even though it's included in the PPL
Calls to the module work fine if I change the LabVIEW adapter to use the development system
Calls to the module fail if the adapter uses the LabVIEW runtime engine
I had similar problems in the past. The solution was that the Main.vi had to be Public and all controls on the FrontPanel also Public.
Hope it helps!
TS don't do much to your PPL.
However I'm curious : when you test your PPL in the TS env, do you create a deployment?
Or you just copy paste the PPL within one of your search directories?
If you don't use the deployment, try using it and see if it brings some warning / error. And if not, try running your sequence with LV adapter set to RTE.
Also side question, are using git with source code separated from compiled code LV setting applied ?
I haven't tried setting up a deployment yet. We have a standard directory that all of the packed libraries live in, the path to this directory is in TS' search paths
There are half a dozen other libraries we have that are working fine, this is the first one I have built from scratch in the VM
I have been working with separated compiled code to make using git easier, but I tried turning that back off this afternoon. It didn't seem to help but I haven't experimented much with this yet
I've also just turned on debugging in the PPL but it doesn't seem to allow any additional behaviour in TestStand, like being able to step into the library code
I originally had the LabVIEW adapter set to use the RTE, which is where the PPL stops working. If I have it set to use LabVIEW it works as expected - but I suspect this won't be any good when we go to deploy everything
Ok I see,
Try creating a small workspace+project+sequence that is just calling the PPL.
Then build a deployment and take a look at the errors and warning. They may be cryptic, but sometimes highlights not functioning parts of a system.
TS will only give the VI to the LV RTE, and that's all. So you to step in you need to have the adapter set into LV dev.
Never tried that, but if you modify your main to call the module public request to show your diagram / FP, does it work?
And indeed you really need to make it work with the LV RTE if you don't want to buy a LV licence for your test system PC.
I asked all this before because we ran into an issue lately where the steps could run in dev but not in RTE.
The issue was that the source code was separated from the compiled code. In LVdev mode, LV was able to link the source with the compiled code in the cache. In RTE, it wasn't able to do so.
Using the deployment, it returned weird warning codes. Going back to NI with that, they found out that the deployment was 'seeing' the problem but not correctly reported it. We had to merge back compiled code into source code.
My point here is that there is something in you PPL that the dev environment can resolve (dependency, compiled code, ...) but not the RTE.
Not helping much, sorry, but few things here might give you ideas to resolve your problem.
Thanks Cyril, that's all useful information. It definitely gives me a few ideas of things to try
I moved my front panel controls to Public scope and all my problems went away.
THANK YOU SO MUCH!
OK so I think is is really fixed now
I also spent some time messing about with access scope and was able to get everything working by making a subVI and associated strictly-typedef'd control public...
But it turns out that just turning on 'disconnect type definitions' in the build spec does the trick without having to muck about with individual file settings. I can only assume that the LabVIEW runtime is unable to find the strictly-typedef'd control's path if it's not public, and disconnecting the front panel control from the typedef while building allows it to load the subVI successfully
I've also left all the VIs in the project with 'Separate compiled code' turned off. I might try turning it back on to see if it breaks everything again, but it sounds like it's required for the PPLs to build with everything included for deployment on a runtime-only system