DQMH - Front Panel Freezing when loading previous save file - LabVIEW-Windows interaction problem or bad design?

[Matt_AM]

Hey Fancy Folk,

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

[drjdpowell]

Have you considered (I'm calling "Durability" "Top Level" as "Durability" doesn't mean anything to me):

• Top-Level module starts AI and gets its data broadcast User Event (but does not register for it)
• When Top Level starts a Station module, it sends it a "AI Data Source" message, cotaining that Broadcast User Event 
• AI registers that User Event, and from then on receives AI data directly

This way the Station and AI modules are not coupled, other than to the common datatype of the broadcast User Event.

An alternate thing to consider, is just let them be statically coupled.  DQMH is set up to make static connections very easy.  This has major problems as code gets scaled up in size (or in reuse), but many applications are limited in size and natural reuse, so adding complexity to reduce coupling is not always warrented.  Note that you always have the option of later refactoring to get rid of the coupling if needed.

[Matt_AM]

drjdpowell,

I don't understand what you mean by getting its broadcast user events but not registering it to them.  I wanted to run through the imagined scenario in terminology I understand and I wanted to make sure it's what you are suggesting.

When I start the AI module from Top Level, I dont have an event in the Top Level's EHL (unlike the image below which is a snippet of the AI feedback broadcast and all messages in my top level EHL) that listens to the AI Broadcast.  I am assuming this is what you mean by starting the module but not registering for it.

Next, when I start a station module from Top Level, I send the AI module's ID to the station module so the station module listens to the broadcast from the AI.  This way the station is the one receiving the AI data directly. 

I can do this, but the issue becomes I want to display the AI data on the top level's FP.  I could do a work around and use sub panels to show the station module's FP on the sub panels, but I haven't messed with sub panels enough to feel comfortable with that.

Matt