statechart trigger informationI

[peabody124]

I'm pretty impressed with the functionality of the new statechart module.  However, I was wondering if there was any way to get information about the trigger in the action panel of a transition.  For example, I have a transition between two states, that can be caused by an "incorrect response" trigger and "correct response" trigger.   I want the action to be the same in that transition, and the start and stop points the same.  However, I'm sending a message across the network, and it seems very redundant to have to write two copies of the transition with a 0 and 1 in each.

A similar problem I'm having, based on the asynchronous design I'm having, is I would prefer to have a "responded" trigger and have an input that indicates what response it is (eg. a U16 if I had many possible responses).  However, if in my data processing loop it analyses the analog input, and sets a local variable that maps to the input in the same iteration that throws a trigger I have an instant race condition, because the input to the state machine has already latched the previous input in the execute state machine caller loop. 

It seems like both of these would be solved by allowing triggers to carry some custom information in the same way that dynamic events do, allowing a trigger to _synchronously_ carry information into the statechart, even in an asynchronous design (I can't do synchronous because some of the calls take too long, and I get buffer overflows).

Thanks!

[Matt_W1]

I wish you could pass data with triggers as well. But there is a work around. Basically use a synchronous statechart, with your own queue (which also inputs to passed with the triger) to make it work like a asynchronous statechart.

I wrote up a very quick example to show the idea.

[peabody124]

Thank you very much, that makes sense.  I'd tried something similar with a event dispatcher but it looked pretty cludgey.  That seems a bit more sensible.  Hopefully they'll add this feature in the future.

[Matt_W1]

If you need triggers that return data you can also set up a queue to return the statecharts outputs (and have it send the outputs only on certain input triggers). But if you do that you have to be sure your input queue has a length of one, otherwise overlapping multiple requests may get the wrong responses.

Another useful thing I learned about statecharts (and this saved me a ton of headaches when I did), is that you can use the outputs like statedata (they can be on the left and right side of an action, and their value remains between iterations of the statechart). So if your statechart manages data that you always want displayed put it in the outputs instead of the statedata (no need to try to keep the output data and statechart data in sync).