QMH Test Sequencer module

[Tamir87]

Hi,
I'm looking for assistance with building a test sequencer module base on QMH pattern, I'm really struggling with it. 

My application is based on QMH modules, each qmh module has is purpose, to log data, operate a device (power supplies, cameras, stages, powermeter and etc..) or to run a test (sequence of steps, I-V sweep for example )

My issue is that now i would like to build a module that run the tests modules in a sequence (i.e call for a module (I-V sweep module for example) wait its done and then run the next test module(test))

these are my modules - some of them are used to operate devices and some of them are tests:

inside the test sequencer module - each message is a case where i call a test module, I need to add a method that will wait till the test ends and only after that to move to the next one (next case). 

 -- >

Kindly ask for ideas how to create this test sequencer module, i tried to search on the forum for a solution or idea but didn't find. 
I can give more info or clarify things if needed. 

Thank you in advance. 

[Tamir87]

"We use an method that first generates a temporary one-shot queue name.  To make this more useful, it's the name of the calling VI with a globally incrementing number attached to the end, letting us know both the order that temporary queues were made in as well as the origin VI of those queues."

This is interesting, but I'm not sure how do it, could you please give more details about this method, or maybe an example. 

My issue is that i have a test sequencer (QMH module), that running tests (other QMH Modules that performing sequence of steps such as I-V sweep for example), I'm calling a module, running the test and then need to know when the test is done so I'll be able to run the next module.
I'm struggling how to build it. 
this is my modules:

inside the test sequencer module - each message is a case where i call a test module

 -- >

kindly ask for ideas how to deal with the issue, maybe by creating a new queue or other methods

[Intaris]

---

@Yamaeda wrote:

You can e.g. send it back with a Notifier, they work (very) similar to a 1 element queue. Queue up the request and wait for a Notifier, the consumer loop reads the value and send the notifier with the value. That way it won't have to wait.

---

This is how I would approach it (notifier return channel), but with a single addition.

If you notice that your Data has a different scope than your instruments (Loops), you might need to consider having a "repository" for measurement values. This can be whatever form you want it to have, either active or passive. But it might need to be brought into existence as a seperate entity, decoupling the nitty gritty of actual instrument communications from the current state of measurements.

If, however, your request is "Loop A wants Loop B to perform a new measurement NOW and return the current value to me" as opposed to "Loop A wants to know the most current measurement from Loop B", then you actually have a synchronous relationship and no amount of code wrangling is going to change that. How you handle this is going to depend largely on how your system is supposed to perform. Is blocking the message handler for 20 s OK, required, undesired? This is more of a system design question than an actual QMH question. How do you want your system to actually behave?

[Tamir87]

I'm not sure I understand you and how should deal with it.
I I need loop A to call loop B, then loop B perform some tasks (sequence of cases). when loop B finish the tasks it notify it to loop A. then loop A can continue to the next step (case).

[Intaris]

Yes that would essentially be the order of execution,. but using a "private" notifier to return the data as others have proposed.

What is it that Loop A is requesting of Loop B? Must it be a new measurement or is it the last measurement value?

Making software do what you want is dependent on being able to properly define what it is you want. How to properly approach this particular problem is very dependent on the intricate details of how the actions of Loop A and the measurement of Loop B are related functionally, temporally and logically.