DQMH and TestStand

[ngblume]

Hello DQMH'er,

it has been a while, since I asked a couple of questions regarding LabVIEW working together with TestStand (https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Fundamental-Understanding-of-interaction-of-DQ...).

I got all the answers needed and have since then been playing with DQMh and TestStand (unfortunately not enough).

But now I ran into a couple of basic questions again, where I need outside help (I'm not sure I've looked at all the documentation aka RTFM, though).

I also attended the talk "Empowering TestStand with DQMH" at NIDays Europe 2019 in Munich (http://download.ni.com/pub/events/nidays/2019/europe/1220_updated_sw_track_presentations.zip, slides inside), which emphasized some ideas in my head.

I have two main use cases:

1. Developing a DQMH module with proper Tester API, which will be turned into a LVLIBP.
   This DQMH module in the LVLIBP may be called from TestStand using LabVEW RunTime-Engine (no dev system on TestStand machine) or might be running beforehand.
2. Developing LabVIEW Applications consisting of multiple DQMH modules all in LabVIEW

Details for Use Case 1: This is to allow for example the following:
Start a DQMH module that starts controlling a system, that needs time to get ready (I don't want to spend the time waiting in TestStand). Basicly any system, from which TestStand only needs a small piece of data / information, but significant overhead would be required (Thermal Chamber, Shared Instruments, Tuning of Filters, etc.). 

Use Case 2 is working great so far, but I'm struggling with Use Case 1.

I'm able to fire up the module from TestStand and send requests and handle replies, etc.

My problems arise from the tester VI. I understood the importance of application instances, but I'm not getting the "complete" hang of it. 

Goal:

Have TestStand use a DQMH module in two ways:

1. when the DQMH module is a singleton and already running (and should continue running afterwards) - UseCase: Thermal Chamber, where I fire up a DQMH module controlling the chamber, to which I can than "connect" to from TestStand, check temps, etc.
2. when the DQMH module is started from TestStand, while the user uses the Tester VI from LabVIEW to "debug" / "sniff" the execution of the module - UseCase: Debugging into existing and running sequences

I see three ways of achieving parts of these two scenarios:

1. Start the Tester VI from TestStand and the tester has "access" to the module. This would mean the Tester VI is always started in a separate thread and the user has to close it at the end. This also only works with goal #2.
2. Somehow get TestStand to use the same instance as the beforehand separately started DQMH EXE, so that the already running module is used.And furthermore, somehow get the Tester VI started in the same instance as well... No idea, how.. or if possible at all...
   I was under the impression, that using a LVLIBP would help in this case...
3. Some other architecture / structure / approach, that allows for the same goals to be achieved but makes the interactions easier..

Any help is greatly appreciated !!

Cheers

Niels Göran

[FabiolaDelaCueva]

Hi Niels,

Before I launch in one of my long responses 😉 

One question: are you already including the DQMH API Tester inside the project library? The API Tester is normally outside of the library but for distribution purposes, it is OK to bring it into the library. The reason we have it outside is to ensure that during development we don't accidentally call a private VI within the API Tester.

I will come back with more information after that...

Thanks for your trust in DQMH.

Regards,

Fab

[ngblume]

Dear Fabiola,

thanks for your response.

I added the API Tester VI to the lib before building the PPL.

Before you create a lengthy response (which would be greatly appreciated), I'm thinking that it might be easier to got about this a little differently:

I normally don't like questions, that are asking for other people to just tell you the solution to your problem, but in this case it might be easier to get to a working solution and then discuss questions / understanding.

System:

- Test System PC with TestStand (most of the time Dev-version, rarely Run-Time-version, but perferably should be working with Run-Time as well) and only LabVIEW RTE and device drivers, etc. as well as hardware and devices

- Dev PC with LabVIEW Dev System and TestStand 

Goal(s) / Requirements:

- On the Test System LabVIEW software is always packed in PPLs (mostly for ease of deployment)

- Advancing drivers to DQMH modules to improve reuse and have them become more intelligent

      - Use Case: Keep handling messages (maybe from a bus), while TestStand does something else and later provide information on request (Last value for a parameter for example)

- Use DQMH modules as follows:

      - Use modules started beforehand (and should run afterwards)

      - Start DQMH modules from TestStand and later close it from TestStand as well

      - When something happens during run or I just set a break point in a TestStand sequence, I would like to fire up the API Tester at that time and "connect" to the module and do debugging or open block diagramm for example

What would a feasible approach for such a system look like?

I was under the impression, that PPLs were essential for something like that to work...

Thanks !

Cheers

Niels