DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH 7.0 feedback


@Darren wrote:

Thanks @1984. I've filed Issue #912 to the DQMH Consortium on the 'stub' VIs in Dependencies issue. If you end up being able to share more details about the issue, please post them here.


@1984, I was unable to reproduce this issue when validating a stock DQMH 6.0 cloneable or singleton module. Note that those stub template VIs do appear under Dependencies during the fixer scripting, but then they disappear once the scripting is done, assuming no errors or problems are encountered. I'm guessing something went wrong when the fixer ran on your code. Again, if you are able to share the code along with exact steps to reproduce the issue, please send me a DM and I can update the DQMH Consortium with more details.

0 Kudos
Message 11 of 15
(384 Views)
@1984, I was unable to reproduce this issue when validating a stock DQMH 6.0 cloneable or singleton module. 

Thanks for looking deeper into this. On my setup the problem is clearly reproducible and affects pretty much all my modules. Unfortunately I can't attach an example. 

 

Just add more information:

On my PC after selecting the "Semaphore synchronization not found" in the validation tool labview start searching for some VIs. I think it shows up four times, not sure if its related.

 

1984_0-1705910371506.png

 

Once the validation is done my GIT client shows the following: 

1984_2-1705910724910.png

 

and these two VIs show up in the dependency list:

 

1984_3-1705910761836.png

 

Besides that my module is now calling a stub_VI another problem is that if the project has more than one DQMH modules which you want to validate then all of them will call these stubs instead of the ones in the module.

 

HOW TO FIX MANUALLY?

I guess fixing the stub_obtain Module semaphore its easy, I can simply replace the stub VI with the Obtain Module semaphore VI of the module(s). Replacing the stub_module Name--constant.vi is a bit different. The stub VI has a numeric input and a string output and no other code while the VI in the module has a string constant and a string indicator.

 

Can I just replace the stub VI in the dependency list with the one in the module? Whats the purpose of the numeric input? Is that just for cloneables? Should I add this numeric control to the Module name--constant.Vi?

 

1984_4-1705911090596.png

 

0 Kudos
Message 12 of 15
(375 Views)

There should never be 'missing VI' search dialogs during scripting. I wonder if something went wrong with your DQMH install? In Windows Explorer can you see if these files exist:

 

[LabVIEW 2022]\project\Delacor\DQMH\_DQMH Validate Module\templates\stub_Acquire Module Semaphore.vi

[LabVIEW 2022]\project\Delacor\DQMH\_DQMH Validate Module\templates\stub_Obtain Module Semaphore.vi

 

If one or both of these are missing, then your DQMH 7.0 install is bad, and you should uninstall/reinstall DQMH.

0 Kudos
Message 13 of 15
(360 Views)

Oh, and yes, to fix manually, you can delete that stub VI with the -1 constant and replace with the Module Name--constant.vi from your module.

0 Kudos
Message 14 of 15
(358 Views)

[LabVIEW 2022]\project\Delacor\DQMH\_DQMH Validate Module\templates\stub_Acquire Module Semaphore.vi

[LabVIEW 2022]\project\Delacor\DQMH\_DQMH Validate Module\templates\stub_Obtain Module Semaphore.vi

 

If one or both of these are missing, then your DQMH 7.0 install is bad, and you should uninstall/reinstall DQMH.


Sorry for not coming back earlier on this. The VIs do exist on my PC in the right folder. I reinstalled DQMH when I started to see this problem, but it didnt change anything. I sent you a DM, just check that out and we can go fro there.

0 Kudos
Message 15 of 15
(309 Views)