Helper loops for active / repetitive tasks

[danny_t]

Thanks Joerg that makes sense.

Sorry to go a little of topic here but.....

I have used and do use User Events, I understand and am comfortable with creating a user event then, registering for that event you have created and then wiring that into your event structure.

But I am not sure I really understand the use of the constant RefNum for an event not yet created as in this case it feels sort of wrong to me, thought obviously works and is something I can use. 

Is there any material you know covering this a little more 

many thanks

[joerg.hampel]

Perhaps it's easier to grasp if you think about the requirements of the LabVIEW IDE and not so much about the user event's lifetime. What I'm trying to say is think about the constant's data type, not the user event it's derived from.

1. If you want to handle a user event in your event structure, you need to wire an Event Registration Refnum to the Dynamic Event Terminal of the event structure. Only then can you you select the Event Source (the "event handled by this case"). 

2. You cannot wire a generic or an arbitrary Event Registration Refnum, it has to be of the exact data type you want to handle, or otherwise the Event Data Node - the node inside the event structure providing the data you want your user event to send - cannot identify the data LabVIEW returns when an event occurs (and we wouldn't be able to change it during runtime).

3. If you only wired the actual User Event Refnum (from the Obtain Blabla.vi) and the resulting Event Registration Refnum to the Dynamic Event Terminal from the inside, you'd still be unable to choose the event source for your event case.

So, it really all comes down to the following: If the user event that you want to handle is not created yet at the time you start executing your event structure, you have to wire a placeholder of the exact same datatype to the outer Dynamic Event Terminal.

Hope that makes sense(?).

[Gregory]

Hi Joerg, I just had a couple of practical questions about using an event structure in the helper loop.

1. When you want a new event for the helper loop, do you use the "Create new DQMH event..." tool? If yes, do you move that event out of the API virtual folder and into a privately scoped folder?

2. Do you handle errors in the helper loop? If yes, does it send the error to the message handling loop or broadcast it?

I tend to use a queue to send messages from the message handling loop to the helper loop, but this event structure approach interests me!

[Darren]

1. Yes, I do exactly that. Use the scripting tools to create the event, then move it to the private 'Requests' folder. If I remember, I'll also document the event as private in its description when I create it. Note that after the scripting is done I usually delete the scripted code in the tester, the Main EHL, and the Main MHL, then I add an event frame in the helper loop for the private event.

2. Most of the time I don't add error handling in the helper loop. But on occasion, I'll just drop a copy of the error handling VI from the EHL into the helper loop and use that.

P.S. - No, I'm not Joerg, but I am a fan of helper loops, so I thought I'd throw in my two cents. 🙂

[ryan_sheppard]

Same as Darren here...

1. Create a new virtual folder "Private Requests" that's privately scoped.
2. For error handling, took a quick look at my helper loops. They do not include much error handling, which now I am going to wait how others handle errors from the helper loop and see if I need to add some error handling to them.

[Taggart]

I just use the normal error handling VI like Darren.

[joerg.hampel]

All very similar to Darren.

1.) We will create a virtual folder named "Private API", move the request VI there, update its icon, delete both EHL and MHL cases, add an event case to the helper loop.

2.) Either use the MHL(*) Error Handling VI to send errors to the MHL, or do something else (like close/reset a communication channel if the communication fails). So that really depends on the module. Now that I think of it, I gotta say that we very rarely use the Error and Status broadcasts (cause we use our hse-logger instead)...

You can find the same information in our KB -> Best Practices -> Style Guide:

https://dokuwiki.hampel-soft.com/kb/bestpractices/codingconventions/dqmh#helper_loops 

(*) Even though there are two different Error Handling VIs for EHL and MHL,  as far as I can tell there's no difference?

[Marius_T]

Hello everyone,

I just discovered the DQMH and I find it a really  powerful tool ( kudos to Delacor!). Since is a maintained, well documented  and powerful framework we decided to use it together with an OOP HAL  to build our testing application (motor efficiency testing which will have 8-10 modules). Since i'm just starting with the DQMH (shame on me) I would be more than happy to get your input regarding the below questions:  

Using a module for data acquisition, similar to the one shipped with DQMH CML template, how would you send the acquired data from a helper loop to a logger module using a queue instead of events ?

Would this approach be against DQMH best practices?

Or a queue  is not even needed, is safe to use the events and all the acquire data will be logged?

Many thanks.

Regards,

Marius

[FabiolaDelaCueva]

---

@Marius_T wrote:

Using a module for data acquisition, similar to the one shipped with DQMH CML template, how would you send the acquired data from a helper loop to a logger module using a queue instead of events ?

Would this approach be against DQMH best practices?

Or a queue  is not even needed, is safe to use the events and all the acquire data will be logged?

---

Hi Marius,

Thanks for your vote of confidence on DQMH and for the compliments. A queue is not even needed. The event handling code works as a queue. The logger can even implement a buffering mechanism so it is not writing to file every single time it gets a piece of data. If the data you are sending to the logger is too big, then consider wrapping it in a DVR and send the DVR reference instead via the event. 

The only time we have moved to a queue approach was on an application that we were acquiring huge data sets and we were acquiring them at 2 gigasamples per second!! We had other problems there and we eventually moved to an FPGA approach instead of using third party hardware but that is another story.

Like anything else, please benchmark your own implementation and see if this solution fits for you. A quick test would be to acquire for a couple of minutes and make sure that your logger keeps up. One more thing, we tend to make the Stop Module request for a DQMH Logger to not be high priority, to ensure it has a chance to log any remaining data in the "event queue".

Thanks again for your trust in DQMH and in Delacor. 

Happy wiring,

Fab

[Marius_T]

Hi Fab,

Thank you for the provided info, your reply  answers to my questions and helps me to move on  in this  "go/no go" situation.

Again, I can't emphasize how much this framework will help me in my future projects. Thank you and keep up the amazing work!

Kind regards,

Marius