DQMH Consortium Toolkits Discussions
DQMH - Front Panel Freezing when loading previous save file - LabVIEW-Windows interaction problem or bad design?
Hey Fancy Folk,
First, I already posted this in the general LV forums, but thought posting it here as well could be beneficial since I think it’s a DQMH-Windows interaction that’s causing my code to freeze. https://forums.ni.com/t5/LabVIEW/DQMH-Front-Panel-Freezing-when-loading-previous-save-file/td-p/4263...
I’m having an issue with a DQMH module initializing a secondary module which causes my FP to freeze until the load is complete. Once the secondary module is launched and sends its "did init" broadcast, the main module performs a check for previous save in the main module's MHL. During this process, the FP freezes halting all user events being handled by the main module’s EHL. Once the load is complete, the main module's EHL then reads all of the events sent to the main DQMH module and updates the FP very quickly.
I am by no means an expert in DQMH and may have laid out my modules poorly with regards to who is responsible for what. However, I’m at the point now where I think it’s an issue with how LabVIEW interacts with Windows but I’ve been known to be wrong before.
Background:
The basic idea for my code is that I have a durability module that launches an ai module and 3 station modules which each launch their own sub-modules. These station modules and their submodules are copies of the cloneable module while the durability and ai modules are singletons.
The durability module is registered for the ai module’s broadcast and will rebroadcast the data to a station module in the EHL if the station is enabled.
When a station is enabled, the durability module launches the station then waits on the init of the station to self-enqueue a durability message to launch a load previous save routine in the durability module. Note, the loading of the previous save is done in the durability module's MHL and not the EHL. I originally had the loading in the EHL and I was freezing the FP since I blocked execution of the EHL from reading and rebroadcasting the ai data. With the MHL doing the legwork of loading a previous save, the EHL should be free to continue to send data to the FP and my station submodules However, that is not the case. Below are some images of the block diagram regarding how a station is started and what happens when the "station did init" event is fired off.
Below are the MHL Vi’s in the “Launch station Post Initialization” case that aren’t requests to other DQMH modules along with the FP for the popup message.
What I’ve tried:
As I previously stated, I originally had the code in the MHL in the EHL’s “station module did init” EHL case. I changed that up to free up the EHL so it could continue to receive the ai module’s broadcasts. From there, I’ve tried basic probing of the MHL on the error line to see when the error path was ran to get a basic “this is where the holdup is” via the probe’s timestamp. It appears that the holdup is when I run the “check if previous save file exists” vi. I’m starting to think that when LabVIEW interacts with Windows to get the file names then queries the return against the key (*SerialNumber*.tdms), that it takes priority over the EHL of the DQMH. Has anyone else noticed this issue?
Potential work arounds:
- I could redo how the broadcast of the ai data works. I could have the stations register to the ai module’s broadcast and have the durability controller tell the ai module which stations are enabled so the ai module knows which data to broadcast to which station module. However, I feel like that is creating a bunch of dependencies which is what I was trying to avoid.
- When the durability initializes, I could check the given path for any tdms data then when a station is loaded, query the TDMS files only against the motor’s serial number. The downside is that whenever I change the path, I’d need to recheck the folder for TDMS files.
- I could redo my logging scheme to create a folder with the serial number then query the folders in the module’s logging path for the serial number with my log file residing in said folder. This feels like what I’m currently doing with extra steps, but fewer clock cycles. If it walks like a duck and talks like a duck, it’ll probably freeze up my FP like my current method but for shorter time periods.
- I could do the checking for a previous save in the station module’s EHL/MHL which would offload any responsibility from the durability module. Rubber duck debugging says this would be a good first step to go down to make sure its not a module thing but a LabVIEW-Windows thing.
I am assuming people will ask for the code and I don't know how I can share it without heavily redacting a bunch of stuff. I'll do what I can regarding sharing what code people ask for.
Any advice is more than welcome,
Matt
