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

[drjdpowell]

---

@FabiolaDelaCueva wrote:

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

---

Why?  The remaining action in this case is done in at most 500 ms, and I suspect it was completed in much less than that, quite possibly in less than 1 ms.  What are you gaining?

What you're losing is intuitiveness and testability.  "Do X and then stop" is very clear and always happens the same way. "Do X, no wait, stop immediately!" is harder to understand and has a race condition determining if X happens or not. The race can be different in testing and real-world conditions.

[FabiolaDelaCueva]

---

@drjdpowell wrote:

---

@FabiolaDelaCueva wrote:

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

---

Why?  The remaining action in this case is done in at most 500 ms, and I suspect it was completed in much less than that, quite possibly in less than 1 ms.  What are you gaining?

What you're losing is intuitiveness and testability.  "Do X and then stop" is very clear and always happens the same way. "Do X, no wait, stop immediately!" is harder to understand and has a race condition determining if X happens or not. The race can be different in testing and real-world conditions.

---

We cannot please everyone. If we had the stop event not be a priority request, we would get the developers used to NI QMH and other architectures complaining as to why it is not a priority event.

Developers are free to change this behavior in their own custom template, they are not forced to use the DQMH templates in order to use DQMH. You are welcome to create your own DrJDPowell_DQMH template and use that when you are using DQMH. In your template, you could make the Stop Module not be a priority event.

Regards,

Fab

[MaxScz]

Are you sure, that you are using a Request and wait for reply Event? If it was a Request and wait for reply Event, the Stop Module call should be executed after the reply of the Module to the Public API VI.

[CQ_Li]

After I debugged, it was because the hardware (LDD) was not closed correctly, and when I ran the code again, it generated the error in the subVI I used. 

Now it is working well, and no more magic delay needed too.