Command parser in DQMH

[Peter_B]

Hey fellow wire workers.

As a roookie to DQMH, I seek your advice on the best way to structure an instrument command parser which must act on a large number of commands (20+).

My Command Parser module receives a Request containing the command string to parse.  It parses that for syntax errors.

If a syntax error then Reply "Error:invalid command"

If no syntax error then I need to do some H/W I/O e.g. "Do I/O" before Replying to the Request.  That I/O can be done before the timeout. The I/O does not need to be reusable but it does need to be (unit) testable and possibly modular if I am to obey good practice..

Then a reply needs to be sent to the Request  - either an "OK" or some other string (e.g. a value).

Now my question.

     Should I :

        i)  code all the (20+) "Do I/O" events into other unique events (e.g. one event per command)  or

        ii) stuff all the "Do I/O" code cases (one case for each command) into a large case structure inside the one original Request MHL case ? or

        iii) try something more elegant  ?

If i), can/should I fire these other user events from within the original Request MHL case ?  and if I do that it seems I can not set the original Request to be Wait for Reply lest the MHL hang (hence I lose my Reply ability).  (also unsure why I would fire user events instead of just enqueueing the other 20+ cases of the MHL) 

If ii) then I fear I am breaking some important principles for designing software (not modular enough ?)

[ChrisFarmerWIS · Accepted solution]

I would probably create a sub-vi to be called within the one MHL case.  This sub-VI would be a single-shot state machine that steps through all of the I/O.  Once completed you send the reply back.

If the time taken is going to be longer than 5 seconds, you'll want to change the request timeout.  Another option is to use a Roundtrip, and you just send the broadcast when the operation is completed.

You may want to track the stop module event case (off a separate register for events) whilst this is happening just in case the modules has been asked to stop half way through and you need to handle that ASAP.

I wouldn't enqueue up 20+ cases into the MHL.  This can work, but it's risky, and you can't be sure that something else will interrupt that sequence of events.  The queued message handler shouldn't be used as a state machine.

[Peter_B]

From a fellow Aussie,  - many thanks Christopher for your suggestion !  

Option 1. You wrote: "create a sub-vi to be called within the one MHL case".

1. Is that a new MHL case or the same MHL case that parses the command ?
2. Can that sub vi be a module in its own right (so I can then take advantage of using the scripted generation of test vis that DQMH does so well)

Option 2 You wrote "Another option is to use a Roundtrip, and you just send the broadcast when the operation is completed.". 

1. Could the listener to that Broadcast be in the same Command Parser module or would/should it be in a new module ?
2. Does the broadcast option have any benefits or downsides compared to Option 1 ? 

[ChrisFarmerWIS]

---

Option 1. You wrote: "create a sub-vi to be called within the one MHL case".

1. Is that a new MHL case or the same MHL case that parses the command ?

On surface value, the same MHL case

---

1. Can that sub vi be a module in its own right (so I can then take advantage of using the scripted generation of test vis that DQMH does so well)

I guess if the I/O device is a different device this could make sense.  If it's the same device, I'd keep it all together.  Consider whether this really needs to be another module, when a class/library might suffice.

---

Option 2 You wrote "Another option is to use a Roundtrip, and you just send the broadcast when the operation is completed.". 

1. Could the listener to that Broadcast be in the same Command Parser module or would/should it be in a new module ?

The listener would be the application or the higher level code that requested the command parser to do something in the first place.

---

?

1. Does the broadcast option have any benefits or downsides compared to Option 1 ? 

---

Really depends on how your process is working.  Hard to say based on the info I know.

[Peter_B]

Thanks again Christopher !  I appreciate your timely advice.

[joerg.hampel]

I'm still unclear about your intent (and I'm having a hard time putting my question into words):

1. Do you want your module to do a single thing, i.e. send a single request with a command string as the parameter, and that single request requires 20+ commands sent to some device in a single sequence (like back to back) before that single request of your module is finished?
2. Or are these 20+ commands corresponding to 20 different things your module offers, and you're asking if you should
   • either have a single request "Do Command", where the parameter (the command string) defines what the device will actually do
   • or have 20+ requests like "Do this", "Do that", "Do some more" etc and each request encapsulates the corresponding command string?

Example for #1 would be a robot module with a single request "walk to goal", and the command string would contain information about the directions (like "left, right, straight, right, left...")

Example for #2 would be a robot module with requests to "go left", "go right", "go up", "go down" ... and your calling code would request these one by one.

I hope my question makes sense...