Right tool to replace a State Chart project?

[Evan]

I am about to start a new project based off a project written in the State Chart toolkit.  A lot of the tests and the sequence we want to keep but we want to ditch the State Chart editor due to its crashy nature and difficulty to debug and maintain.

So I am looking at the DQMH, and trying to decide if its a good architecture to utlize in this instance.  Any thoughts?

I like the testers and the logging nature.  I also feel it offers a much better "abort" path for when we want the sequences to stop.  The current State Chart project has a single abort state and if any test along the way fails it just aborts the entire sequence.  We want more intellegence and options.

Lastly, this new architecure will need to have some control loops in them as well, so I figure a the DQMH is perfect there to use clonable items.

Generally I am leaning towards DQMH, I just figured I get it out to those using it and see if there are any general thoughts, ideas etc.

Thanks all,

Evan

[FabiolaDelaCueva · Accepted solution]

Hi Evan,

Thanks for your vote of confidence on DQMH.

I am also curious to see what others answer about using DQMH to replace a project using the State Chart toolkit. 

I think it should work out. As with any other project, I suggest that you model it first. It can be on a white board, better if you can do it with your team. Ask yourselves how many modules you have and how many could you have. Define these based on responsibilities. These are good candidates to be your DQMH modules. Then draw arrows describing the messages that need to go in between your modules, what type of messages are they? Requests or broadcasts?

I am assuming that since you already were using the State Chart toolkit that you also have a good state diagram. What is each of your systems steps and what makes you go from one step to another. 

I commend you for not wanting to completely start from scratch. A lot of hidden treasures and hours of troubleshooting and decision making are hidden in each part of existing code. It is better to mine those treasures out instead of trying to reinvent the wheel. 

Good luck and please keep us posted of your progress.

Regards,

Fab

[Evan]

Thanks Fab,

I realize this is one of those post that is obviosly me trying to think through some things with no real specific question, but any little light bulbs or feedback anyone has is great.  I am looking at this is a good mental excerisae so maybe others will enjoy it.

I am starting to really try and define what I think the various modules for the project really are.  I was waching some of the videos, including the HAL video and post and see some good ideas.  Our current structure is an extremely linear state diagram with very little forks and in general it either continues or abort the entire system after each step.  Not great but is is working.

For the new project we need to do all the above, modified and to add intelingent control loops.  That is why I liked the DQMH idea.  I can make the control loops modules and get the benefites of testers etc, and then have a state architecture callign it somehow.  It is the state portion I am still trying to wrap my mind around.

In general do you find the DQMH modules are functional like you said and then there is a "Main" that is not a DQMH module, like the examples.  I am concerned I may be trying to make to many modules with a class style hierachy to them, and over architecting the project.

I can't decide if I make the state machine sequencer its own DQMH or just stick with a "basic" state machine.  We will end up with a few different types of sequences to run, so I may make the sequence a class of sorts so we can dynamically call the "get next step" style function.  With that in mind I can see it being a reply event and a DMHQ...

I am somewhat going in circles on the best way to lay it out, but I keep drawing various ideas and am making progress.

Thanks all

[FabiolaDelaCueva]

---

@Evan wrote:

I can't decide if I make the state machine sequencer its own DQMH or just stick with a "basic" state machine.  We will end up with a few different types of sequences to run, so I may make the sequence a class of sorts so we can dynamically call the "get next step" style function.  With that in mind I can see it being a reply event and a DMHQ...

---

At Delacor, we are evaluating the PTP sequencer, it is a free product. We are at the early stages, but so far we like what we see. Their example (located at <LabVIEW>\examples\PTP\PTP Sequencer\Test Executive) includes a Producer Consumer that we have replaced with a DQMH module.

So far, we have figured out that we would need to use "Requests and wait for reply" events for the sequence steps, otherwise the PTP sequencer goes super fast through the sequence steps and the end user thinks they never executed.

PTP has already figured out the sequence engine and the XControls for listing the sequence steps, and defining the sequences are very cool. They make it very easy to define your sequence, and you can save/load different sequences. 

[Evan]

I really like the PTP sequencer but for this specific use case I need more flexibility in the cycling and less in the dynamic creation of sequences.

So I have a DQMH sequencer that at the moment is basically 2 events.  Add a sequence, evaluate a sequence.  Abort is coming.  The sequences themselves are a class, similairly to the steps.  So the DQMH is just a layer on top of the sequence classes and is responsible for "managing" them.

So far so good, but I am still learning.

[Evan]

Just a note.

I am continueing down the path of using the DQMH for the sequencer and it has gone pretty well.  A tip for anyone, and this may be obvious, but my first attempt I tried to put too much in the DQMH.  I needed to really define the modules my system needed and then make a couple DQMHs rather than try to force it all in one.  So I have an app with a DQMH sequencer, a clonable DUT DQMH, and potentially some controller DQMHs.  Trying to put too much in the first DQMH was really causing a lot of the head ache.

Thanks Fab for the help.