How to deal with time consuming MHL cases properly

[Ozfarmboy]

For our modules that communicate with a device/instrument, we have created a "Connected?" boolean in our Internal data cluster. 

When our device is initialised and ready to use, we set Connected? to TRUE.

For all other requests and wait for replies, we check this state first before acting.  If Connected? is FALSE, then we reply with an error stating that the device is not yet initialised.

If we lose connection to our device, we set Connected? back to FALSE.

[D_mitriy]

Unfortunately, I can't check template from Jorge (my LV version is a bit too old), but I'm agree that HW communication should be sitting in the different module.

I.e. you have a "Main" module, which is in charge of launching and communicating all other modules. "Main" launches "HW" module and requests it to start initialization. And while "HW" is busy, "Main" still can handle other tasks.

Advantages:

• No locking of the MHL of the "Main" module.
• You can send back some status messages from "HW" to "Main" to entertain the user or make some logging.
• You can always send a high-priority message to stop the execution of "HW" without stopping other software.
• Easy testing of the "HW" module alone using a DQMH tester.

Disadvantages: just a bit more of the coding.

[Jens_S]

Thanks for your advice!

As you might have noticed it's been a while since I asked this question and since then the project has progressed considerably. Nonetheless it's good to recap the decisions you made from time to time to see where you came from and where you are now. After quite a lot of testing I changed the init phase back to a single MHL case and just wait for it to finish. The test stand will run 24/7 and only needs to be restarted or updated for maintenance so it's not too big of a problem.

If I would start the project today I surely would do a lot of things different (full OOP, "smaller" Modules) which I guess is just the way it is when you learn something from scratch.