06-21-2018 10:58 AM - edited 06-21-2018 11:07 AM
Hi Fab,
I am working my way through the NIWeek 2018: Tips and Tricks for a Successful DQMH Based Project and firstly a big thank you again for this. I always find this type of thing very useful and interesting.
Near the beginning off the video you talk about the "smell" of the project and in the note you say.
Quote
"We created an unnecessary dependency between the Acquisition module and the Logging module by requiring the Acquisition module to be running before the Logging module runs. What if I want to take the logging module to a different application where the data to be logged is not provided via a broadcast event?"
I have been puzzling over this for half an hour or so, to see what the "unnecessary" dependency" was and as I have nobody else to talk to about it, thus this post 🙂
After all you could start the logger without waiting for the the DAQ module to run, but it would not do anything until the DAQ module ran. So that is not the dependency.
Then I suddenly realized a distinction between the a Broadcast and a Request that I had not possibly recognized before. A Broadcast comes from a specific module whereas a Request can come from anywhere. Using the DAQ Broadcast the Logger module would ONLY work with that DAQ message and thus by using the the Request instead any other DQMH module could pass data in to log. I think this is what you were saying?
This mean any use of Broadcasts tied the receiving module into the Broadcasting module, obvious now I think of it in this way.
The downside of this retaliation is I am now rethinking through all the broadcast events I have done in my two DQMH projects.
On further thought; with your change you still have a dependency but the other way round, now the DAQ module needs the Logger started first. The judgment of which way round the dependency goes depends on the circumstances of your project I assume.
mulling it all over now
Danny
PS I posted this here and not on your site as I could not see a comment section on https://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/ page
Solved! Go to Solution.
06-21-2018 01:08 PM
Hi Danny,
Thanks for the heads up about the comments not working, I have no idea what happened. I added a test comment and now there is a comment section. Thanks for bringing this to my attention, I wonder if this is why nobody comments on our posts 😉
@danny_t@Danny wrote:
Then I suddenly realized a distinction between the a Broadcast and a Request that I had not possibly recognized before. A Broadcast comes from a specific module whereas a Request can come from anywhere. Using the DAQ Broadcast the Logger module would ONLY work with that DAQ message and thus by using the the Request instead any other DQMH module could pass data in to log. I think this is what you were saying?
Yes, if we use "Log Data" request event, any other module could send data to be logged.
When we have the Logger registering for the "Data Updated" broadcast event, it requires the DAQ module to be running before the Logger can register for the DAQ module broadcasts and can only log data from the DAQ module and not from any other module.
This makes the Logger only useful for the DAQM module. Now, as I say on the presentation and the blog post, this might be OK for your application if you are OK on having those two modules always being together AND if you make sure the Logger starts the DAQ module or ensure the DAQ module gets launched before the Logger module.
Another way to identify if you could be using a Request or a Broadcast is to follow the guideline of using "imperative" for the Request event names and "past tense" for the broadcast event names.
Data Updated indicates the action already happened, the DAQ module already acquired the data and it is letting the world know that the "data updated".
Log Data indicates that the action still needs to happen. The outside world is requesting the Logger to go ahead and log the data.
Does this help?
Regards,
Fab
06-22-2018 03:29 AM - edited 06-22-2018 03:57 AM
Fab thanks for that. I hope I get the chance to say Hi at GDev Con in September
regards
Danny
06-22-2018 12:35 PM
@danny_t wrote:
Fab thanks for that. I hope I get the chance to say Hi at GDev Con in September
regards
Danny
Sure thing! I will be there presenting.
I am planning on extending on the first part of the Tips and Tricks presentation I gave at NI Week. I will spend more time going over the modeling decisions, the naming convention and other tools some of our customers are using to identify conflicts in their design at the early stages of development.
If there are any particular points you would like for me to cover, please let me know.
See you at GDevCon!
Fab
07-04-2018 08:47 AM - edited 07-04-2018 08:54 AM
Hi Fab,
May a little bit more regarding sharing DQMH modules across projects might be interesting a GDev Con.
Also I tried to find anything on the PPL presentation you mention at the end of the Video, I know its a little off topic, but is there a link to that presentation please.
many thanks
Danny
07-04-2018 08:56 AM
I'm presenting on another topic at GDevCon, but if Fab chooses to ask the audience during her presentation, I'll be happy to share our experiences with that, Danny.
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® (Developer Experience that makes you smile )
07-04-2018 01:42 PM
@danny_t wrote:
Hi Fab,
May a little bit more regarding sharing DQMH modules across projects might be interesting a GDev Con.
Also I tried to find anything on the PPL presentation you mention at the end of the Video, I know its a little off topic, but is there a link to that presentation please.
many thanks
Danny
Danny,
Here is the link to the presentation about PPLs:
A lot of the SEPAD NI Week track presentations are already up at https://learn.ni.com/center-of-excellence
I will add to my list of things to cover to discuss how to share DQMH modules across projects. From the top of my head I have these three:
* DQMH Module Templates
* VIPM Package
* PPLs
07-04-2018 01:47 PM
@FabiolaDelaCueva wrote:
From the top of my head I have these three:* DQMH Module Templates
* VIPM Package
* PPLs
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® (Developer Experience that makes you smile )
07-04-2018 03:00 PM
@joerg.hampel wrote:
@FabiolaDelaCueva wrote:
From the top of my head I have these three:* DQMH Module Templates
* VIPM Package
* PPLs
- source distribution
- git submodules