DQMH Consortium Toolkits Feature Requests

I sometimes need to implement a DQMH module in isolation. So the first thing I do is create a new blank project and save it (this will be the dev project for the new module). Then I try to create a new DQMH module in the same folder as that project (by editing the 'Module Save Path' to point to the folder containing the new blank project):

When I try to click OK, I get a dialog that says I can't create the module because the specified folder contains LabVIEW files:

Yeah, I know the folder contains a LabVIEW file... it's the blank project. The Add Module dialog wants me to create a new subfolder for the new module, but I don't want that... I want the module and all its files to live in the same folder as the isolated development .lvproj. I propose that this file check be changed to remove ".lvproj" files from the list of LabVIEW file types that it checks for.

Just a very, very simple proposal for consistency, as per what the title says: when a "Panel close?" event is triggered in "External Launch" mode, the module should probably broadcast a "Panel hidden." Status updated. Like this:

Do you agree or is there any reason I'm missing for which the broadcast was not placed there?

Thanks!

Hi,

When creating a RT Tester, the wizard asks for which modules it should do so. And it lists all modules in the project, even those which already have a RT Tester generated.

Maybe only showing the modules which do not already have a tester would help shorting the list ?

Now, when creating a round trip event, the broadcast event uses the exact same typedef as the reply payload. When using a cloneable module, this causes the broadcast event to miss the module ID and therefore any listener to this broadcast event does not know from which module it comes.

One typical use case we have which illustrates this is a cloneable module to drive a thermal chamber. The "get thermal chamber status" must be a request + wait for reply, but we also added a helper loop in the module's main to execute a periodic status check and the status update must be shared to everyone using a broadcast event so it can be displayed on a top VI's user interface for example. Actually, if we create a "round trip event" the brodcast event created misses the module ID, therefore the top VI cannot know the status of which thermal chamber was updated.

A possible solution I see is the broadcast event to have it's own typedef, composed of the module ID and the typedef of the reply payload.

What do you think about this proposal? Do you have other suggestions?