Strange behaviour in a clonable module

[Keplovic]

First of all, I apologize if this topic doesn't go here.

I'm experimenting a strange behaviour in one clonable module of one project. In the project (developed in 2022 Q3 32-bit version) I have several DQMH modules, and some of them are similar to this one and they behave properly.

For some reason, at any moment, the MHL stops receiveing messages from the EVL without generating any error and from that moment this clone become a "zombie" clone. I can't do anything, I have tried stopping the clone or sending any request but the MHL seems to ignore all messages. If I stop the tester and run it again, then I can see that this "zombie" clones are still alive.

I have attached a probe image where it's possible to check that the EVL of some clones is still working but not the MHL (4140003, 4140005, 4140006 clones are not working in the pictures) . I have 7 clones of this module as it shown in the next pictures.

Has anybody bumped into this problem?

 

 

 

 

 

 

 

 

[Enrique.Noe]

Hi @Keplovic, one recommendation would be using the Module Id that comes from the Module Admin Object instead of the one that comes from the unbundle by name

I don't think this is the cause of your issue but it helps with the troubleshooting, the problem comes when you launch several modules and send a request to "All", the module ID that comes from the unbundle by name is the "all" and it will be used by your code, and you'll want to use the Actual Module ID from the clone Instance.

Please read the following to better understand what I´m talking about.

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/Newbie-question-regarding-Module-ID-in-EHL-passed-...

I would suspect from the OPC Read function, maybe it is timing out?

Additionally, Verify if all the VIs you're using are Shared clone reentrant or Preallocated Clone reentrant.

You can run the DQMH Validation tool, but this checks only for the Module VIs.

Hope that helps.

Enrique.

[Keplovic]

Hi Enrique.Noe:

Thanks for the recommendation, but I'm afraid this is not the case.

Anyway, I have found that this behaviour only happens when I'm developing. Once the executable is built, the program works great.

Thanks.

[FabiolaDelaCueva]

This may be a good opportunity to give a try to Lumos.

https://dqmh.org/product/lumos/

The tool would allow you to monitor the events both in development mode as well as in executable to see where the difference may be.

Regards,

Fab

[Keplovic]

Thanks Fabiola!

I think I'm gonna try to acquire one license, but I have one question: is the individual license a perpetual license?

Thanks

[mbaudot]

Yes it is. You can find more details here: https://documentation.dqmh.org/lumos/1.0/faq.html#licensing

[Keplovic]

Thanks, my bad.

I dindn't find this info in Lumos - DQMH® 😅

[shuttlefan]

I've found issues where I wasn't closing my modules properly and it becomes a zombie module.  

are you closing out of the clones properly?

Might be something else to try.  

[FabiolaDelaCueva]

Thanks for pointing this out, we added the licensing link to the additional information tab for https://dqmh.org/product/lumos/ 

Happy wiring,

Fab

[Keplovic]

Thank you shuttlefan, it's nothing about this.

I think I have found the source of the problem but not sure why is this thing causing problems.