Helper Loop Data Communication

[ryan_sheppard]

This post is to confirm that my data communication with my helper loop is following best practice and hopefully if someone has a similar question this can help answer it for them. I read through the post that Fab led me to about private events, but was not confident that I understood them fully.

The function of my helper loop is as follows

In the timeout case, an AO value is calculated using data that a user provided in the main application. The AO value is then written to a DAQmx Write.vi in my MHL.

To accomplish this task, the data communication I used is as follows:

Sending Data to Helper Loop

1. When the user updates a value in the main application that will be used in the calculation performed in the helper loop, the normal process to send that data to the MHL occurs. But in my MHL I have a private event that my helper loop is registered to listen to, which receives the updated value.
2. The updated value is then stored in a new data cluster, and in a shift register. I think the new data cluster may be redundant because the scripted data cluster contains all the controls that my new data cluster contains.
3. This same communication is used for all data values communicated to the helper loop. 
4. While writing this, I realized in my helper loop I am registered to a public API event which is used to wake up the helper loop. Should I create another private event which is fired from the MHL to wake up my helper loop?

Sending Calculated Value to MHL

1.  After my formula node calculates the new AO value, I enqueue this value to the MHL.
2. The value is then dequeued in the MHL case and written to the DAQmx Write.vi.
3. This skips the EHL, going directly to MHL.

Note:

Private events are stored in a new virtual folder that has a private scope.

Images of said communication:

MHL Sending Data to Helper

Private Event in Helper

Timeout Case

 Please let me know if I need to provide anymore information regarding my data communication.

[FabiolaDelaCueva]

I will look in more detail later. The first question I have is where you wake up the Helper Loop. 

You only show changing the value of the timeout timer within the timeout case, but your shift register starts with a -1, so the helper loop will never execute the timeout case.

Can you add a post of where you are waking up the helper loop by changing the timeout timer value from -1 to something else?

Second observation, if the data for both your broadcast and you private request are the same and are called at the same time, I think you don't need the private request, you could just register the helper loop for the "Final Travel Updated" broadcast event.

Regards,

Fab 

[ryan_sheppard]

Above is how I wake up my helper loop. I also put it to sleep in this event case, reading the Ramp State enum that has Enable and Disable as items. The disabled case sends a -1 value again.

I thought I read somewhere that using a broadcast to send data to the helper loop was not a good practice, so I didn't took that route. The data for the broadcast and my private event will be the same. The only reason I have the broadcast event there is because I was learning to use the new DQMH unit test, no one else is listening to that broadcast currently.

[FabiolaDelaCueva · Accepted solution]

---

@ryan_sheppard wrote:

I thought I read somewhere that using a broadcast to send data to the helper loop was not a good practice, so I didn't took that route. The data for the broadcast and my private event will be the same. The only reason I have the broadcast event there is because I was learning to use the new DQMH unit test, no one else is listening to that broadcast currently.

---

If you are going to create an event just to communicate with the helper loop, a Request Event seems more appropriate, because the module is asking itself to do something. We do need to make the request private because we don't want other modules waking up the helper loop when it is not their job to do so or the module itself needs to do some preparation before waking up the helper loop. On the other hand, you might just use the same "Start Acquisition" request to wake up a helper loop that is in charge of acquiring data and does not require any additional preparation, in that case, no need to make the request private.

However, this is just a guideline, not a rule. 

If you already have a broadcast event that executes right when you are ready to wake up a loop, there is no need to create a new event just for that. You can use the existing broadcast event.

Does this make sense?

Fab

[ryan_sheppard]

So the correct way to communicate with the helper is, it depends. Since I have a broadcast event in my MHL, I can use that to communicate with the helper loop. If I were to not have a broadcast event in my MHL, I could use a private request event to communicate with the helper loop. Do I understand correctly? It sounds like both ways work, and I will probably be better off if I am consistent throughout my modules.

Really appreciate the help.

Ryan

[AlexElb]

I would prefer to wake up the helper loop with a private request, since it is the modules private helper loop and so you can be shure, that no one from outside can wake it up.

I can understand that if nothing complicated has to happen before and after the helper loop performs (like maintaining a specific state of the module etc) you could also use a public request. Then your public "Update Final Travel" Request could be handled directly by the helper loop and there wouldn't be cases for that in the EHL nor the MHL, wouldn't they?

But using the broadcast event "Final Travel Updated" to update the helper loops doesn't seem very nice to me, since the module is saying it has done something what hasn't yet happened. What happens when something in the helper loops gets wrong but others modules already expect it is running / running with an updated value?

I see that we're talking about guidelines and not about rules. But the definition of requests as "module - do something!" and broadcasts as "I've done something" seems very fundamental to me. Maybe I'm not getting something here. If module 1 makes a broadcast, I would say it is legal to have the helper loop of module 2 registered to that broadcast and directly react to that. But that would be a different case.

[joerg.hampel]

---

@AlexElb wrote:

I would prefer to wake up the helper loop with a private request, since it is the modules private helper loop and so you can be shure, that no one from outside can wake it up.

I'd argue that depends on the module. In this case, it sure seems like a private helper loop. We also have modules where the helper loop implements part or most of the module's public API.

I can understand that if nothing complicated has to happen before and after the helper loop performs (like maintaining a specific state of the module etc) you could also use a public request. Then your public "Update Final Travel" Request could be handled directly by the helper loop and there wouldn't be cases for that in the EHL nor the MHL, wouldn't they?

I'd go for that approach, too, if nothing else happens (see above).

But using the broadcast event "Final Travel Updated" to update the helper loops doesn't seem very nice to me, since the module is saying it has done something what hasn't yet happened. What happens when something in the helper loops gets wrong but others modules already expect it is running / running with an updated value?

Agree.

I see that we're talking about guidelines and not about rules. But the definition of requests as "module - do something!" and broadcasts as "I've done something" seems very fundamental to me. Maybe I'm not getting something here. If module 1 makes a broadcast, I would say it is legal to have the helper loop of module 2 registered to that broadcast and directly react to that. But that would be a different case.

---

Agree.