Dqmh module registered to its own broadcasts

[Rafal_Kor]

I really like Dqmh implementation. Thank you delacore. I also want to thank Joerg for his helper loop processing repetative tasks in the event time out idea - it works really well for me. Now onto the question; would there be any reason and/or a way for a module to need to act on its own broadcasts?

[joerg.hampel]

Let me start off by saying that I didn't invent the helper loop idea, I just wrote about it 🙂

Regarding your question about broadcast events, let's see what the DQMH Online help says about them:

Broadcast: An event generated by the module to let any external code that is registered to receive the event know that “Something happened”.

Typically a broadcast event is generated after the module acts on a request.

This implies that broadcasts are meant to communicate events and data from a module to the outside. Judging from that definition above, it might not be the intended use to register a module for its own broadcast events, even though it's technically possible.

Let's think about the architecture of a default DQMH module: Events (requests as well as broadcasts) are received in the event handling loop (EHL). In general, the event data will be forwarded to the message handling loop (MHL) via the queue to be processed there. So if you register a module for its own broadcast events, you would basically end up with a way to send data from the MHL to the EHL and back to the MHL.

To sum it up, there might be cases where it makes sense for a module to listen to its own broadcast events (I can't think of one at the moment), but most of the times, you can just have the MHL send a queued message to itself or use a normal request event to send data from the MHL to the EHL.

That being said, is there anything else to this? Fab?

[Rafal_Kor]

I suppose I must clarify here that I asked my question in the context of a module with a helper loop which periodically generated a certain broadcast. Think of a DAQ module acquiring data and broadcasting it to whoever was registered to listen. In that context, is my question then, more a question of style? Meaning that even if there was a case when a module needed to do something with its own broadcast events, rather than have the module's EHL act on the broadcast only to then pass the data to the MHL, stylistically it would be better/nicer to just queue that data direcly from the helper to MHL (for display update for example) like what I already do with the helper's errors, which I simply pass to MHL on its queue to be handled in the MHL's error case.

[joerg.hampel · Accepted solution]

Sorry, I misunderstood your question then.

I would argue that you lose both CPU and execution time if you route the helper loop's data via the EHL to the MHL. So, clearly, I would suggest to not do that but - like you described - send it directly to the MHL via its queue.

That being said, for modules with helper loops, we sometimes have large parts of the module's functionality in the helper loop, and don't even bother sending data to the MHL at all...

[FabiolaDelaCueva]

I agree with everything that Joerg has said. I will only add something regarding Private DQMH Request Events.

There have been occasions where we need the DQMH module to send an event to itself. In the context of helper loops, a case I can think of would be sending from the MHL a Request to wake up the helper loop. In this case, we would create a Request event, with a small caveat. The caveat is that we need this request to be private because we don't want the outside world to ever be able to send this request. 

In the past, we have created a new private virtual folder in the library for Private-Requests. Once we create the Request Event via the DQMH tools, we move the Request VI to the Private-Requests folder. We debated about making this a native DQMH feature, but it is so rare that we need to create private events, that we decided against it. 

In the DQMH Best Practices document, we mention Private Request Events in two cases (so far):

• If a module registers for the broadcasts from other modules, you need to be careful about calling “Obtain Request Events for Registration.vi”, because if the module is not already running, this VI just determines the broadcast datatype. You should consider creating a private request to register for the events if the module launches later.
  
  • You can create a Private DQMH Request Event as a regular DQMH Request Event and then move its API VI call to a virtual folder in your Module (configure the virtual folder with private access scope). This is to make it clear to you and others that this Request is intended to be used only within this module and it is not part of the public API as regular DQMH Request event would.
• When coding a repetitive operation, use a helper loop that is registered to the stop Module event and does the repetitive operation inside the timeout case. Leave the changes to the local data cluster to be handled via the traditional EHL->MHL and then use a Private Request to update the data in the helper loop. This ensures that if the event structure in the helper loop has several events already in the queue, it contains the latest information the next time the timeout is handled.

I hope this helps. 

Regards,

Fab

[joerg.hampel]

+1 for the private request events, I should do that more often, too.

[Taggart]

so I have a similar question...  I inherited some code and there is a request event.  It is only fired from one spot, inside it's own EHL.  Basically it decides what vi to put into a subpanel. There is enum dropdown on the main.vi FP.  When that changes, the EHL detects that and then calls the Request Event, which just sends the same data back to the same EHL... It's not called from anywhere else. Does that make any sense to do it that way?  It seems to me you would just enqueue a command to the MHL with the subpanel you wanted to load...  Is there any good reason to do it the way it was done?   My plan is just to refactor it and get rid of the request entirely, or at the very least, keep the event in case I ever want to fire it from somewhere else, but in that particular event case bypass the request event and just send the command directly to the MHL.

[Taggart]

Actually I should note it is called in one other place in the initialization frame of the MHL, but it would also be super-easy just to enqueue there as well...

[joerg.hampel]

Sounds to me like you can get rid of it, Sam.

[FabiolaDelaCueva]

Sam,

If you look at DQMH 4.0, we made it so Show Panel, Hide Panel and Show Diagram would not be handled by the MHL anymore. The reason behind this is that the MHL might be blocked by a Request and Wait for reply and in those cases, it is safe to act on the real quick request to show/hide the panel.

I wonder if there was some reasoning like this behind acting directly on the EHL to insert into the subpanel.