Preallocate dynamic dispatch

[ThetaMa]

I've developed a LabVIEW program that loads a packed project library multiple times using the re-entrant (0x80 in open vi-reference and in the  execution settings). This way I am able to load the PPL as many times I want.

My problem is that as I keep loading the PPL multiple times the system is not able to keep up with the datarate (AMC queue messages) the PPL send to each other. As a result I see that the items in each queue is building/buffering up. The more instances of the PPL I load the more they all buffer.

I've come down to that this is because each instance loaded from the PPL use the same class method from the PPL and they have to wait for it to become available before they can execute it. I am not able to set the method to "Preallocated clone reentrant execution" as the method has a dynamic dispatch input. It has a dynamic dispatch input to make it easier to change versions and do updates. I am not using the dynamic dispatch input to make it possible to change the method during run-time. I put a class constant on the block-diagram so in that sense LabVIEW should be able to know at compile-time what datatype to use. Is it possible to force LabVIEW to compile the system with "Preallocated" set since it is not changing in any way?

Or is there a possibility to force LabVIEW to load the entire PPL as a standalone system (preallocate each VI in the PPL) when a new instance is loaded?

I have not been able to run the time consuming method as preallocated in any way so I thought I could copy the PPL and rename it before I load another instance. But re-naming the PPL makes it corrupt (as I have seen on this forum).

Any suggestions how to load multiple instances of a PPL and not share the VI's inside? Or how I should fix my code so that i don't get problems with time consuming methods?

[crossrulz · Accepted solution]

Why does it have to be "Preallocate Clone" instead of "Shared Clone".  If a lack of reentrancy is your problem, then going Shared Clone will fix that (more clones are created as needed).

[JÞB]

Forcing a DD to execute in a different context via ACBR should be possible with a wrapper caller.  You will need some method to keep something top level running in the PPL or garbage collection "*may" destroy internal references. 

*may, might not, if the hierarchy is idle the OS will get around to garbage collection according to whatever collective bargaining agreement is in place and how the union workers feel that day.

[DHerron]

What I ended up doing when I need multiple instances of the same plugin is to dynamically launch the associated plugin launcher only once, which itself is setup for dynamic dispatch. The launcher uses parallel For loops to spawn however many instances of the "main" plugin code I need (in the picture this would be the FLIR AX8 subVI). That subVI is setup to be Preallocated and I *think* should accomplish what you're trying to do.

[JÞB]

Coming back to this. And I'd like to see some example inlined so I can review it.

I'm not sure but, you may be able to add an ini key like "AllowMultipleInstances=TRUE" to the ppl build. At least worth exploring. That should give each instance a seperate application context but may require something more than context limited Synchronization functions (Queues, Notifiers, User Events, etc....) You would need something like a TCP/ IP service or the like

[pauldavey]

If you changed the method to static despatch, and then broke the inheritance relationship but made the methods VIMs then you would still be able to have the edit-time behaviour you want, albeit needing to duplicate the entire set of VIs for each new version.

[Intaris]

LabVIEW cannot pre-allocate class methods because it allows loading of child classes at run-time.

Due to this, it never has the case where a class input type is guaranteed at compile time. There can ALWAYS be a child loaded at some time between compilation and execution of the callsite.

I have asked for the option to "finalize" classes in LabVIEW because I feel this would open up this possibility.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-support-for-quot-Uninheritable-quot-methods-and-c...

With this duplicate idea coming years later

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-for-quot-Final-quot-specifier-on-Class-Override...

[ThetaMa]

I tested the suggestion to set the methods to "shared clone" it helps, but it is not perfect. I can still see som message buffering as more PPL's are loaded. I guess this will be my final solution, although not perfect.

A for-loop is a good solution for many applications but unfortunately not for this project.

I tried to check out the  "AllowMultipleInstances=TRUE" but did not find anything about it.

I have tried VIM's in PPL before but I got compilation errors. I don't know it's still an issue.

I would love to have som "finalize" settings for class methods. Or in the PPL build there should be a setting to remove all dynamic dispatch inputs and replace them with what's on the block diagram, compile the code as is. This way 3 static VI's could be made, "init", "driver" and "close".