20 Comments

  1. Chris, is there any reason why the second two videos are unlisted? The first one is searchable, but I could only get to the other two from this blog post. No biggie, just thought I’d make y’all aware… Incredible content BTW!! Excellent job. Love it. -drew

    • CRoebuck

      Hey Drew,

      Thanks for the feedback, thrilled that you enjoyed the post. Regarding the videos. I did add them to a playlist on our YouTube Channel however I was worried that people would only find these “short” videos rather than the longer DQMH instructional videos that go into more detail, these are listed on the Channel. Thanks for the comment though, maybe this strategy is confusing and all should be listed in future. Chris

  2. Excellent explanation Chris! Thanks for taking the time to put it all together in such clear terms. I now have a much better idea of how the pieces should work together for a HAL we’re thinking about building.
    -Dino

    • CRoebuck

      Allen,

      Firstly thanks for following the blog, it’s great to know we have followers and people find the content useful. I’d be happy to back save the demo for 2014 and provide it. I’ve also reached out to you via email to check you have the DQMH Toolkit installed.

      Happy wiring
      Chris

      • Thank you very much. This demo is excellent. It is really helping me understand several very important topics including hardware abstraction. (D)QMH cross-module communications and module cloning.

        Nice work!

        -Allen

    • CRoebuck

      Michael,

      So one example use case that we’ve had success with is calling the DQMH from Teststand. By wrapping the HAL in a DQMH module the Teststand sequence only needs to care about calling the Public API of the DQMH module. The dispatching of appropriate child classes is all taken care of inside the DQMH module. So, no passing of LabVIEW objects, VISA refnums or any other refnum between LabVIEW and Teststand and no persisting of any of those things in Teststand Globals or Locals.

      This also brings the API Tester into play. Because we’re using User Events as the primary message transport, we can interact with our DQMH module from its’ tester in parallel to calling it from Teststand, it’s a great way to perform fault insertion or “sniff” data coming back out of the module. The only caveat is ensuring that the API Tester is running in the Main Application Instance.

      I like Teststand but it’s nice to be able to debug my module and its API entirely in LabVIEW and then call exactly the same public API from Teststand without worrying about objects and references in my sequence.

      Finally, not everyone is 100% comfortable with LVOOP, they might be happy to create the basic HAL but may be uncertain how to go about calling that from a higher level app or test sequence.

      Chris

      • Bob Preis

        >>By wrapping the HAL in a DQMH module the Teststand sequence only needs to care about calling the Public API of the DQMH module. The dispatching of appropriate child classes is all taken care of inside the DQMH module.

        But couldn’t the public api of the HAL be called directly from Teststand in the same vein? The DQMH seems to be contributing two things to the HAL: 1) state and 2) asynchronicity.

        Are either of those really necessary when your test sequencer is linear and your test configuration is predetermined with sequence files?

        • CRoebuck

          Bob,
          Sorry for the very late response, for some reason this ended up in Spam. Your question is a good one. Yes indeed, your HAL could be called directly from TestStand, absolutely. By wrapping in a DQMH module (or Actor Framework “Actor”) you’re providing statefulness and asynchronicity for sure, although by using the Request and Wait For Reply message type the module is asynchronous but communication is not. It’s more like calling a Sub VI. So not strictly necessary but taking this approach allows several things. The ability to use the in-built API tester as a “sniffer”….to be able to observe and interact with the module from the tester whilst it is being simultaneously used by TestStand, a useful debugging feature.

          Also being able to spawn clones of the module, each with its own state being managed internally is very convenient. Ultimately none of it is absolutely necessary to create a good TestStand solution but I feel the benefits outweigh the cost of creating the DQMH wrapper. Don’t forget, the scripting tools take care of a lot of the overhead of this for you.

          Disclaimer. I am not affiliated with Delacor or the DQMH any longer and whilst I use a combination of AF and DQMH in my customer projects, I typically choose DQMH when I am faced with a hardware + TestStand project.

          I think it’s good to have many weapons in your armoury!

          Regards
          Chris

  3. douglas carmichael

    Thanks i’ve looked at HAL code. Looked at DQMH videos. Trying to get get my head round both. You’ve explained how to do both nicely. Thanks
    Question: can you run the clones simultaneously. Because I would like to say run Visa(s) and daq(s) hardware continuously and log data at the same time?

    • CRoebuck

      Hi there,

      Thanks for taking the time to watch the DQMH videos and for evaluating the HAL example code, we’re glad that you found the material accessible.

      To answer your question, yes you can indeed run clones simultaneously, that is the intention in the design of cloneable form of the DQMH. The example use case I always give is based around the common DC Power Supply as most LabVIEW developers have interfaced to one of these at some point in their career. So typically we would physically connect to such an instrument via GPIB, RS232 or LAN. In terms of software we would typically have a VISA reference to that particular power supply. Returning to our DQMH module, we would hold the VISA refnum in the private data of the module (persisted using the shift register in the message handling loop of the DQMH Main VI) and would populate that private data by providing a public API method (Request event) called “Set VISA Address” (or similar). This method would take a VISA refnum provided by the calling code and would write it to the module private data. If we now launch a second instance of this cloneable module we can call the Set VISA Address for both modules, providing a different VISA refnum to each. We now have multiple DC Power Supply modules running which are communicating with different physical hardware using separate VISA refnums.

      Perhaps you could provide some more details on your intended use case. Do you require varying rates of acquisition and data generation ? Do you have both input and output from the same physical device ?

      Best Regards,
      Chris

      • douglas carmichael

        Hi Chris thanks.
        Been doing a lot of RS232/485, Daq analogue inputs/output into projects. Can have 4 parallel loops plus data logging, tdms. All continuous flow.
        In some of the rs232, data rate will be 2/sec for Scales & temperature meters. Analogue pressure, flow rates etc, what rate is required.
        If you use the cloned modules. Can you have a mixture of rs232/485 & Daq. Or will you have to keep them separate. Going to try HAL method first.

        regards
        Douglas

        • CRoebuck

          Douglas,

          I would tend to break that problem down and think of the various processes in your system. It sounds like you have some logging going on. Now, dependent on performance requirements I would consider implementing a logging DQMH module. It possibly would have public methods such as “Set Log File Destination Directory”, “Write Data Point(s) to Log File” for example. Your top level application would be responsible for launching this module however once running, any other module wishing to write something to the log file could call the “Write Data Point” method. The parameters for this method might be (Data, Acquisition Timestamp, Channel Name)

          Another module could be the Data Acquisition module. This module would make calls to the Logging module whenever it needs to log something. This method then makes the Data Acquisition module agnostic of a particular log file format. Any changes to the way you log data, file formats etc are contained to just the logging module.

          The Data Acquisition module could hold a reference to the I/O resource in the private data cluster of the Message Handler loop (the bottom loop). Just edit the typedef and add an Visa refnum for example. Some typical methods for this module would be “Set I/O reference” (where you would specify the comm port for example) and “Acquire Data point”. If you implement a HAL then you probably have a hardware class in the private data. So another method might be “Specify Hardware Class” where you would select the specific hardware implementation required. If this was a cloned module you could launch several instances of the module and each one could be assigned a specific comm port and it’s own specific hardware class.

          I hope this response answers some questions and maybe gives you a few ideas too.

          Chris

          • douglas carmichael

            Chris
            Thanks for your help. I have a few simple projects, on the horizon. One data with logging. So will sit down and apply what you’ve suggested.

            Many thanks
            Douglas

  4. Sergiy

    Hello Chris,

    Thanks for the great example. I am able to run simple sequential test by managing 3 Power Supplies, 2 Electronic Loads, and DAQmx.
    Could you post version from:

    CLA E 2016 Chris Roebuck Complementary Architectures LV and TS

    It looks more advanced than version from original post.

    Thanks,
    Sergiy

Leave a Reply to Drew Pierce Cancel reply

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