Request and waiting for reply Event.... Works with Module Tester, but not with sequential calling.

[CQ_Li]

Hi, All

I am a newbie to DQMH. Right now I am working on a small project with singleton module, which communicate with a laser controller. I created a request and wait for reply event, which send a command to the singleton module and wait for controller sending back some string. 

I tested this event with the Tester generated by the project template, but some how did not work with my sequential calling code, which is very similar to the LabVIEW example 1 in the DQMH example code (Thermal Chamber): Start module, Sync Module, Connect to controller... etc. 

Any suggestion on this issue?

Thanks and regards

[DGrayEOS]

We would love to help you, but you haven't given us enough information. If at all possible, please post the code in question so we can take a look.

[FabiolaDelaCueva]

We do need more details in order to help you, please add pictures of your code or a video.

I also asked the moderators to move this post to the Delacor Toolkits discussion group, there will be more people there who can help you once you include more details.

https://forums.ni.com/t5/Delacor-Toolkits-Discussions/bd-p/7120?profile.language=en

[CQ_Li]

Sequential test code"LDD on-off" in Tester"LDD on-off" in Singleton

Thank you very much for your quick response. This time I attached the sequential  test code I wrote, the  "LDD on-off" code in Tester and the "LDD on-off" in Singleton Module. I did more debug, it is nor the request and wait for reply event ("Get LDD info" in the code), but the request event "LDD on-off" is not correctly working.

1. In the Tester, I can send command through the "LDD on-off" event to turn on/off the controller. After close this controller and stop the singleton module, I can run Tester to restart this singleton module and reconnect to controller and turn on/off it again.

2. In the sequential test code, when I disabled the "LDD on-off" event, I can run this code multiple time without any errors, but when I enabled it, the sequential only can run one time, the second time I will get an Error in "Get LDD info".

3. Third try was done as: I run the sequential test code first time ("LDD on-off" was enabled in this try), then run the Tester code, this time I found out that Tester code can not reconnect to  LDD controller. That means the sequential test code did not close LDD controller correctly.

Now I try to understand what is the calling difference between the "LDD on-off" event in Tester code and the one in my sequential test code.....

Hopefully I explained the issue this time.....

[CQ_Li]

Update:

After I added a 500ms delay between "Close LDD" and "Stop singleton Module", now the sequential test code works.

[FabiolaDelaCueva · Accepted solution]

I am wary of magic delays that fix things.

I would suggest you use the "Status Updated" broadcast to figure out the order the different actions within your DQMH module are taking place.

The "stop module" is a priority request event and it might be getting in front of the queue before your Close LDD gets processed.

Also, it is a good idea to add any closing code to the Exit case in the MHL case structure as well. This way you guarantee that whether the calling code explicitly asks for closing or not, the DQMH module closes resources on its way out.

[joerg.hampel]

---

@FabiolaDelaCueva wrote:

I am wary of magic delays that fix things.

---

https://blog.jki.net/news/announcing-the-new-magic-delay-fairy-tool-for-labview

[CQ_Li]

Thank you guys. 

The "Magic Delay" is very interesting 🙂

As suggested, I add the code in the "Exit" case to close the hardware and double check it was closed correctly. 

Thanks and regards

CQ

[drjdpowell]

Why is "stop module" a priority event?  That would seem to be asking for this kind of trouble.

[FabiolaDelaCueva]

---

@drjdpowell wrote:

Why is "stop module" a priority event?  That would seem to be asking for this kind of trouble.

---

In general, we want modules to stop as soon as we tell them to stop.

The Exit case has a #CodeNeeded bookmark that tells the developer to remember to do any cleanup or closing in that case.

Developers are welcome to change this. I have suggested in the past to change this behavior for logging modules because on those cases we do want to make sure that anything that is left in the queue is processed before exiting.