How to avoid self-enqueuing

[python007]

Hi to all

I'm new to DQMH and I'm a litle bit confused how to structure my DQMH Module.

I have the Fallowing tasks to do in my Module:

Task 1: Chip Erase

Task 2: Download

Task 3: Verify

I want that this tasks are executet when i Push the Button "Program".

What I have done I made 3 Cases in the MHL for this Tasks and Enqued them in the EHL:

This works so far but what is when an Error occurs in the "Chip Erase" and I don't want to execute the other tasks so I was thinking about to self enque the further Tasks only if Chip Erase is OK in the MHL.

What is here the best practise?

Best regards

[Dhakkan · Accepted solution]

You could make one 'Program Chip' MHL case which runs the three tasks as subVIs, one subVI per task. Each subVI will have an error case structure, which executes the corresponding task only if there's no incoming error.

[python007]

---

@Dhakkan wrote:

You could make one 'Program Chip' MHL case which runs the three tasks as subVIs, one subVI per task. Each subVI will have an error case structure, which executes the corresponding task only if there's no incoming error.

---

Thanks for your fast reply.

Thats a good idea but how to deal with it when its nesccesery that only task 1 should be executed?

[avogadro5]

---

@python007 wrote:

---

@Dhakkan wrote:

You could make one 'Program Chip' MHL case which runs the three tasks as subVIs, one subVI per task. Each subVI will have an error case structure, which executes the corresponding task only if there's no incoming error.

---

Thanks for your fast reply.

Thats a good idea but how to deal with it when its nesccesery that only task 1 should be executed?

---

Only call the 1 task subVI.

Maybe use a case structure:

Maybe have a separate MHL case that only includes task 1:

[Dhakkan]

---

@python007 wrote:

...but how to deal with it when its nesccesery that only task 1 should be executed?

---

You could even go back to your approach in the opening post. Since an error detected at the end of an MHL case immediately makes the MHL go to the Error case in the next loop iteration, you can decide what to do in the event of a specific error. Of course, each of your tasks needs to generate a unique error within that MHL, so that your Error case can be programmed for appropriate exception handling, including discarding remaining enqueued messages.

Note that this approach has its own caveats.

[joerg.hampel · Accepted solution]

---

@Dhakkan wrote:

You could make one 'Program Chip' MHL case which runs the three tasks as subVIs, one subVI per task. Each subVI will have an error case structure, which executes the corresponding task only if there's no incoming error.

---

I second this suggestion.

@Dhakkan wrote:
You could even go back to your approach in the opening post. Since an error detected at the end of an MHL case immediately makes the MHL go to the Error case in the next loop iteration, you can decide what to do in the event of a specific error. Of course, each of your tasks needs to generate a unique error within that MHL, so that your Error case can be programmed for appropriate exception handling, including discarding remaining enqueued messages.
Note that this approach has its own caveats.

---

I would advise against this - having to tinker with the queue is one of the main reasons for not self-enqueueing. 

---

@python007 wrote:
Thats a good idea but how to deal with it when its nesccesery that only task 1 should be executed?

---

Create separate MHL cases that use those subVIs - one case pre scenario which then uses just the subset needed. This makes the code more readable (and if we're talking about requests, the API will be clearer too). Reusing those subVIs is the reason for creating them in the first place, after all.

Spoiler

If you want or need more control, I'd suggest looking into using a State Machine.

[python007]

Thank you all for your helpful tips now I have a lot of new ideas how to solve my "tasks".

Thanks 🤠