4 Comments

  1. Gregory

    Thank you for the comments on the NI forums; I spent some time this weekend playing around with the tools and I really enjoy the flexibility that comes with your “modules”. I do have a comment/question about the documentation: could you include some “best practices?”

    Some best practices are already included (like the steps you should take when using the “Remove Event” tool.)

    I still have a couple of questions, like:

    -When creating a new project, should we rename “My Singleton Module” or simply remove it from the project?

    -If we want Application:Main.vi to simply launch all modules (or be significantly different from the default), is it safe to delete the block diagram and just include the launch code?

    That’s all I can think of for now. Thank you again for these cool tools, I’m really looking forward to trying it on my next project!

    • Hi Gregory,

      Thanks for the feedback, we like to hear that people find the DQMH flexible and useful.

      Regarding your questions:
      “When creating a new project, should we rename “My Singleton Module” or simply remove it from the project?”
      For DQMH 1.0: You can remove it rom your project and add a new DQMH module via Tools>>Delacor>>Add New DQMH Module…
      For DQMH 2.0: (oh oh, am I doing a pre-relase announcement here? maybe 😉 ) We are adding a feature that lets you rename the My Cloneable and My Singleton Modules from the create project wizard. We will also add a new Tools>>Delacor>>Rename DQMH Module… Stay tuned for DQMH 2.0 official release. You can sign up to our DQMH News Letter via http://delacor.com/products/ and we will notify subscribers first.

      “-If we want Application:Main.vi to simply launch all modules (or be significantly different from the default), is it safe to delete the block diagram and just include the launch code?”
      Absolutely! Like I mentioned in the posts and on the videos, we just had a simple state machine for an Application Main just to show that any code can be used to call the public API functions created in your module.

      If you open the shipping example (Help>>Find Examples>>Fundamentals>>Loops and Structures>>DQMH Fundamentals – Thermal chamber.lvproj) you will see three simple stand alone VIs (Thermal Chamber Controller.vi; Thermal Chamber Controller with DUT.vi; Thermal Chamber Controller with Multiple DUTs.vi). All of these VIs call the public API functions for the Thermal Chamber DQMH Module as well as for the Device under test DQMH Module. The beauty of the public API created for your DQMH modules is that they can be used by any level of LabVIEW developers. So you can even call it from code that doesn’t even have an event structure.

      “Thank you again for these cool tools, I’m really looking forward to trying it on my next project!”
      And we are looking forward to hearing your feedback when you do! 🙂

      For reference to others, Gregory is referring to this thread in the NI Forums: http://forums.ni.com/t5/LabVIEW/QMH-Message-Management/td-p/3212813

      We also have a group dedicated to Delacor toolkits in the NI communities: https://decibel.ni.com/content/groups/delacor-toolkits

      Fab

  2. Allen Goldstein

    I enjoy reading your blog posts here and have taken a good in depth look at DQMH now.

    What I would like to see is a blog post comparing DQMH to the actor framework. Since NI decided to bundle it into Labview, I don’t think it qualifies as “yet another framework”.

    Two things I note it that the Actor Framework seems a bit more complicated than DQMH and therefore may have significantly more overhead. On the other hand, it goes a long way to try to prevent race conditions and block many of the problems of full duplex comms between parents and their children.

    What do you think of this idea of writing a comparison piece in “Walking the Wires”?

    -Allen

    • CRoebuck

      Hi Allen,

      DQMH and AF target different audiences, we don’t think a comparison would be appropriate or useful to everyone and worse still, may give an unfair view of one or the other framework. If you have looked at DQMH in depth we would welcome your feedback. We maintain a community page here where you are invited to give feedback and make suggestions for future versions.

      Thank you for taking the time to read our blog and for evaluating DQMH.

      Chris

Leave a Reply to CRoebuck Cancel reply

Your email address will not be published. Required fields are marked *