DQMH modules causes LabVIEW/TestStand to freeze for ~3 seconds

[CyGa]

Seems that I was wrong about the number '4' (dunno why I've got that number in mind).

Here are important info about reentrancy : https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/reentrancy/

The table in that page summarizes well the caveats of shread reentrancy : 

• Determinism for multiple, simultaneous calling VIs : Possible waiting—Call sites may need to wait for LabVIEW to create a new clone if the pool of clones is empty. When the pool is not empty, pulling a clone and returning the clone to the pool can introduce non-deterministic delays.
• Call overhead when no simultaneous calling VIs exist : Highest—LabVIEW must atomically pull clones from and return clones to the pool of clones. Calls may need to wait for LabVIEW to add a clone to the pool.

Really curious to know if you see any improvements when changing your test VI from Shared to Preallocate.

[Nightshade42]

Tried to reproduce the issue and test out the re-entrancy settings. Of course, it wouldn't reproduce and the sub-sequence calls would all execute a VI call without locking up the software, so I couldn't test things out. I had already made fairly significant changes beforehand though, so I'm guessing something I changed has influenced the behaviour. As my workaround solution is in place and working, I have had to move on to meet project deadlines. If I get a chance, I will come back and re-visit this.

[Nightshade42]

As I'm now confident this is not a DQMH issue, I've moved this issue over to the TestStand forum