DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Module initialization with input from creator (via Start Module VI)?

If a module needs input for its initialize-case in its Message Handler Loop I kind of expected the creator of the loop to set those parameters when running the Start Module.vi. So when you create a new module you could specify what parameters the module will need to initialize - and the DQMH scripting would take care of making a start module VI that took these as inputs.

Is there a reason why there is no such input capability (or have I just overlooked it?)? And is the current "correct" way of telling a module these things (like for example tell a DUT module which physical device it is to communicate with etc). to create a Request event?

0 Kudos
Message 1 of 14
(7,794 Views)

If I need this functionality then I add the module-specific initialization parameters to the connector pane of Start Module.vi, and send them to the module Main VI via Ctrl Val.Set:

1.png

2.png

Then, those parameters are available wherever you want them in the main VI (usually in the Initialize message) after the main VI launches:

3.png

I've found that I haven't needed this functionality in very many of the DQMH modules I've worked on. Most of the time, I can use requests to send data after the module has started. But this is the approach I take when I absolutely need some information available when the module is initializing.

Message 2 of 14
(6,363 Views)

Sure, this is how I did it too. It seems quite a fundamental feature to me though, it would be neater to have it as part of the Create Module script...

0 Kudos
Message 3 of 14
(6,363 Views)

The scripting tools do provide the ability to define parameters when creating new request and broadcast events, so maybe they could use a similar mechanism to define parameters when creating a new module? I disagree that parameter passing on initialization is a "fundamental feature", given how few times I've needed it. But maybe Delacor will see it your way?

At the very least, it seems like a good idea to templatize the Start Module VI a little bit to make it easier for developers to know how to add this functionality. Something like this, perhaps?

1.png

Message 4 of 14
(6,362 Views)

Mads wrote:

If a module needs input for its initialize-case in its Message Handler Loop I kind of expected the creator of the loop to set those parameters when running the Start Module.vi. So when you create a new module you could specify what parameters the module will need to initialize - and the DQMH scripting would take care of making a start module VI that took these as inputs.

Is there a reason why there is no such input capability (or have I just overlooked it?)? And is the current "correct" way of telling a module these things (like for example tell a DUT module which physical device it is to communicate with etc). to create a Request event?

Hi Mads,

Thanks for your interest on the DQMH and for your feedback.

When we started using DQMH we were tempted to put a lot of things in the Start Module, and we did, only to go back and remove them later and replace them with a request event. For example, a device communication DQMH should be able to restart the connection in case of an error instead of exiting in error. So, instead of passing the device address as part of the initialization, we have a request and wait for reply event called "Connect" and there is a different request event called "Disconnect". Then the only purpose of the initialize state for the DQMH is to initialize the module itself, but not the instrument.

[Edit] Another practice that has ended removing parameters from the Start Module has been to use some sort of configuration file in the initialize case of the DQMH.

I like Darren's suggestion of adding a "code needed" section in the Start Module to indicate to developers where this additional parameters should be added. Because even though we rarely do it anymore, there are still few cases where we did need to pass a parameter during initialization. We will add this request to our internal list of feature requests for DQMH.

By the way, we continue to make improvements to the DQMH as time permits, but if the scripting of additional parameters for the start module is a feature that you would like to have sooner rather than later, please email us at info@delacor.com. In the past we have done custom LabVIEW scripting tools for our customers and we could talk about creating such a tool for you.

Best regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 5 of 14
(6,362 Views)

Darren wrote:

The scripting tools do provide the ability to define parameters when creating new request and broadcast events, so maybe they could use a similar mechanism to define parameters when creating a new module? I disagree that parameter passing on initialization is a "fundamental feature", given how few times I've needed it. But maybe Delacor will see it your way?

Yes, I think having the option to add initialization parameters  should be done *exactly* the same way as for the request events, it would make it a very consistent user experience.

When a module clone is instantiated it will often need to do an initialization step..This has been acknowledged by the fact that there is such a step in place already. But to do that initialization the module will often need some information about its role from its creator, so that information should have an entry-point placed *prior* to the initialization step.

Even though there are ways to achieve that today (hence your lack of wanting any change I guess), providing these parameters to the initialize case through the automated process of making the Start Module function is as far as I see it the most odourless solution. The fact that you can achieve it in other ways today does not mean that it could not be done better (more intuitive and user friendly), it just reduces the motivation for a change slightly.

0 Kudos
Message 6 of 14
(6,362 Views)

FabiolaDelaCueva wrote:

Mads wrote:

If a module needs input for its initialize-case in its Message Handler Loop I kind of expected the creator of the loop to set those parameters when running the Start Module.vi. So when you create a new module you could specify what parameters the module will need to initialize - and the DQMH scripting would take care of making a start module VI that took these as inputs.

Is there a reason why there is no such input capability (or have I just overlooked it?)? And is the current "correct" way of telling a module these things (like for example tell a DUT module which physical device it is to communicate with etc). to create a Request event?

Hi Mads,

Thanks for your interest on the DQMH and for your feedback.

When we started using DQMH we were tempted to put a lot of things in the Start Module, and we did, only to go back and remove them later and replace them with a request event. For example, a device communication DQMH should be able to restart the connection in case of an error instead of exiting in error. So, instead of passing the device address as part of the initialization, we have a request and wait for reply event called "Connect" and there is a different request event called "Disconnect". Then the only purpose of the initialize state for the DQMH is to initialize the module itself, but not the instrument.

[Edit] Another practice that has ended removing parameters from the Start Module has been to use some sort of configuration file in the initialize case of the DQMH.

Hi Fabiola,

When it comes to user interfaces things quickly get philosophical, so please bare with me here:

I think the fundamental bit of being able to supply information from the creator to the initialization of the module is really just 1 piece of information; "who am I". Let's call this the name of the module (as opposed to the module ("social security") number).

If modules have this single fundamental piece of information they can build their initialization case to cover all needs (Load a config file? I know who I am, so I can pick the config file that is for me. Etc.) Without this single piece of information the only things that can be done in the initialization step are things that are identical to all instances. Everything else has to come later as a request. That's fine, but means that when trying to understand the module creation part of the framework people have to connect to the request-mechanism already at this stage in their mental training. That lowers the intuitiveness. Now even though I can reduce the need for input parameters into a "name" like this I still think it would be nice to use the same mechanism for modules as for requests; the window where you add the parameters - which are then scripted into the request.

This is just a friendly request for something that I would love to see in an upcoming version of the DQMH (it is already great). With this change the accompanying controller and DUT examples could show that when a controller or DUT is created the modules can be told which controller or device they are linked to immediately at creation (and hence the modules then know what to do during their initialization step, today this seems missing - until you understand more of the framework)..People can later figure out that they can use requests to re-use the module for a different controller/device by creating a re-initialization (or disconnect/connect pair as you mention).

- And at that stage (of understanding the DQMH) they may choose to not do any of this stuff during module initialization anymore. Or they can choose to apply (/stick to) the simpler mental model that modules are inherently linked to 1 controller/device, and if they need another they create a new module instance (and may kill off the old one if needed).

Darren's suggestion would be a smaller step as it introduces guiding only, instead of the wonderful DQMH magic. I'm happy with whatever I can get though



0 Kudos
Message 7 of 14
(6,362 Views)

Mads,

Like I mentioned in the other thread, we have created a feature request (for adding scripting for start module arguments) in our internal system and we will evaluate if it makes it into DQMH 3.0 when we are ready to release it.

Thanks again for your interest.

Best regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 8 of 14
(6,362 Views)

Darren wrote:

At the very least, it seems like a good idea to templatize the Start Module VI a little bit to make it easier for developers to know how to add this functionality. Something like this, perhaps?

1.png

Darren,

We have included this in DQMH 2.1 and it should be available by refreshing your VIPM.

Thanks for the suggestion

DQMH Toolkit 2.1 is here!

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 9 of 14
(6,362 Views)

Mads wrote:

Darren's suggestion would be a smaller step as it introduces guiding only, instead of the wonderful DQMH magic. I'm happy with whatever I can get though


Mads,

We are still evaluating if we will do something else for DQMH 3.0. In the meantime, as mentioned above, we have included Darren's suggestion in DQMH 2.1.

DQMH Toolkit 2.1 is here!

Hope you like it.

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 10 of 14
(6,362 Views)