DQMH Consortium Toolkits Discussions
Questions on best practices and getting started with DQMH on RT/FPGA
I recently discovered the DQMH pattern and thought I would give it a go on a pretty simple project to just log some data for benchmark/validation on a larger project. I was curious and wanted to try it (learn it), and I also have another project coming down the pipeline that I wanted to start writing some reusable code for. Since there is the DQMH CML shipping example, I am basically basing my project off a modified version of that. For hardware I am using a cRIO-9047 and will be using an NI9203 to acquire the data. I have successfully created the NI9203 DQMH module based off the supplied CML Acquisition Module, and modified the Settings Editor Module included in the DQMH CML template to suit my needs. I created the RT API testers for both and was able to find a few minor bugs that otherwise would have been a pain to identify. So, that was pretty cool that I could individually run the modules and find the errors and fix them without having to run all of the code at once (like there's a lot of it or something, ha), very useful. I have found a few things though that I haven't really been able to find answers to while searching, and maybe this is just my lack of experience and no one else needs these answers because its basic knowledge, but if someone could answer these questions for me it would be helpful.
This project will be headless, I do not need any user interface for this. I plan on plugging in the cRIO, hooking up the 4-20mA sensors to the 9203 module and when the User Pushbutton on the cRIO is pressed acquisition and logging will start. During my testing and using the RT API testers I found that there didn't seem to be a way to stop the front panels from opening when they were running on the RT target. When I ran the modules on my Windows dev machine (I put some simulated data generation in the NI9203 module and used some conditional disables for the DAQmx stuff), I was able to set the modules with the existing code and VI Properties so they wouldn't open a Front Panel when called. I know in this case it doesn't really matter on the RT side, if there's no monitor connected the modules would still operate as expected without having to click on anything because of the way my code is setup and the modules are called. But, like I mentioned, I want to reuse some of this code and the project I will be re-using it in will have a HMI UI so I would like to know what the best method of suppressing or not opening a module FP is until I want to see it when it is running on RT.
The workaround I am using now is to use a conditional diagram disable structure in the MHL Init, when the target == RT, the case is empty:
Additionally, when the Hide Panel.vi is called, it also scripted an FP.Open Invoke Method and wouldn't change the VI to hidden, so I changed it to a FP.Close Invoke Method. In this program I won't be using the show panel or hide panel, so calling FP.Close shouldn't cause any unsuspected behavior, but later when I use this code or similar code to show and hide front panels I can see calling FP.Close being a problem if I close the calling VI.
What is the best way to handle calling these modules so that on a RT target they don't open when started? What about showing and then hiding them on an RT target with a UI? am I missing something that should make the FP.Open invoke work on RT as it does on a Windows machine? I should also mention that I have "Enable Embeded UI" checked in NI-Max in the cRIO settings, which I think it needs to be checked for the event structures in the modules to work properly(?).
My next question may be less about DQMH and more about FPGA, and FPGA/RT best practices, but I am curious to know what the best method for monitoring FPGA I/O is while using DQMH on the RT side. As mentioned above, I want to use the User Pushbutton to start the acquisition and logging in this project. In a future project I will be doing a lot more on the FPGA than just monitoring the user button. My plan here is basically just setup a SCTL with the pushbutton rising edge triggering an interrupt. I created a, "FPGA Interface", DQMH module to run on the RT side. I added a helper Loop, "Monitor FPGA Interrupts", that I have setup to immediately wake on module init. In the helper loop timeout, I have a "Wait on IRQ" with the timeout going to a case with an Ack IRQ and another case based on IRQ number that will fire off an event, in this case, my only IRQ (that I want to act on), NI9203 "Start Acquisition" event. This works, but for future projects, is using an interrupt for something like this a bad idea? This is my first time messing with FPGA interrupts. I know I could create an FPGA Boolean indicator and read the bool on the RT side with a read/write control from the FPGA interface pallet, but have read somewhere that having too many controls and indicators on an FPGA can use up resources or slow things down. Where I am just monitoring a button, I am no where remotely close to using up FPGA resources and nothing here is time critical, but I just thought that maybe this is a better way rather than having an FPGA FP indicator?
I need to add some logic to stop the acquisition on a second button press/interrupt and it won't be hard, but I just want to make sure I'm not wasting my time by using an interrupt like this before I go nuts dong something impractical that I will regret later. If I wanted to read and write FPGA controls/indicators in addition would this best be accomplished with a second helper loop?
And one last question, Is there a quick way to add or remove payload data from an event without having to do event/vi surgery, or deleting and rebuilding the event? I can do it without blowing away the event, but it's tedious and was wondering if there is a quicker way that I have missed.
Thanks.
TL;DR: Trying to figure out some DQMH, RT, and FPGA interaction, my questions are in bold.
We created an RT application with Embedded UI turned ON and we did experience the issue of windows popping up on the launch of each module. We actually employ the same workaround you have. Cool! In your case, with Embedded UI turned OFF, it really shouldn't matter other then when running from the development environment.
Changing Event Arguments (payload)
I feel your pain! However, it is not that bad. You modify the typedef and then make sure to visit the EHL (and MHL) frame where the request or broadcast is handled. The Panther Dashboard for DQMH can help you find all those places pretty quickly. Feel free to suggest a feature addition to script argument changes. It will need lots of Kudos, but there is always a chance!
Reading I/O from FPGA
Your choices are polling and interrupts. In both cases a helper loop is... helpful. I like to use interrupts for waveform data and trigger signals. I use polling for keeping low-speed values fresh on the RT side. I'm thinking things like temperature inputs and such.
Hi,
Regarding the FPGA questions, they are very depending on the application and not really related to DQMH itself.
However, Wait for Interrupt does have a timeout. IMO you should build a Helper Loop with a Timout set to 0, and rely entirely on the Wait On IRQ node.
If the Wait for IRQ times out, then re-read, otherwise set Helper Timeout back to -1, and enqueue an order to do something (or private evt).
Also, whatever happens on DI side (button, etc...) and need to sync with RT, I would still use interrupts and have the FPGA detecting the button rising/falling edge. It would allow having a monitoring loop on the RT side running as slow as possible (based on Wait for IRQ timeout) while you don't care if the FPGA just runs as fast as possible to detect egdes.
