DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Validated module not stopping properly.

Hi,

 

I upgraded a module (again) to the latest version of DQMH using the validate module tool. Everything appears to check out ok, but I have a bug now where if I launch more than 1 clone of my module in the tester and then close the panel to shutdown the modules, everything hangs at the stop module request. It seems only to be an issue when stopping all modules at once (i.e. set module ID = -1) AND wait for module to stop = True. 

 

At one point I had 3 clones and showed their diagrams before closing, using execution highlight after the stop call showed that all 3 clones were "stuck" in the close module.vi, one was stuck at "safe to destroy", one was stuck at "Wait on stop sync" and one was stuck at acquire module semaphore.

 

Any thoughts on what might have gone wrong in the validation? This module has come up through a fair few versions of DQMH (rightly or wrongly!). This appears to be the only module with this issue.

 

Thanks!

 

Paul

0 Kudos
Message 1 of 4
(160 Views)

So - I found the culprit, one of the validation tests said it wanted to change the order of the operation within stop module. That appeared to work correctly and the resulting stop module.vi match that of a newly created module... BUT... the close module VI that I had after DQMH6.1 also had some code in a different order compared to a DQMH 7 module... it seems that combined with the change to stop module meant there was a lockup as soon as you tried to stop all modules in one call and wait for the modules to stop.

 

If anyone on the team wants a demo I can do one on teams/zoom or similar, cant really share the code.

 

Cheers

 

Paul

0 Kudos
Message 2 of 4
(136 Views)

I remember there was an issue where one of the cluster constants in the Close Module.vi was erroneously changed as part of the validation process and had a "-1" changed to a "0". Is this the case in your validated code that is functioning incorrectly? The numeric value inside the cluster constant in this screenshot should be "-1", see if it is in your validated code:

 

close module wrong value.png

0 Kudos
Message 3 of 4
(124 Views)

Hi Darren,

 

Nope, that looks correct. What I changed (after comparison to a working module) was more order of execution. So I've attached 3 screen grabs of the close module vi, pre validation, post validation and post fix.

 

Key differences - I moved the "update module execution status.vi" to inside the flat sequence structure and I moved "Release module semaphore.vi" to run before wait on stop sync.

 

I suspect its the latter change that fixed it, but by that point I was being less systematic and just copied all the differences across from a working module before testing again!

 

 

0 Kudos
Message 4 of 4
(109 Views)