03-17-2018 10:08 PM
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?
Solved! Go to Solution.
03-18-2018 03:58 AM
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?
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)
03-18-2018 07:26 AM - edited 03-18-2018 07:37 AM
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.
03-18-2018 07:34 AM
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...
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)
03-18-2018 02:43 PM
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):
I hope this helps.
Regards,
Fab
03-18-2018 03:30 PM
+1 for the private request events, I should do that more often, too.
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)
03-19-2018 12:38 PM
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.
03-19-2018 12:41 PM
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...
03-19-2018 12:45 PM
Sounds to me like you can get rid of it, Sam.
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)
03-19-2018 12:48 PM
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.