New statechart type

[Lars-Göran]

Hi all!

I have tried to come to terms with the statechart implementation in the Statechart Module, but I miss the option of running a statechart without the notion of iterations. I have experimented with sending external triggers along with variant data via a queue to the internal of the statechart. Here it is dequeued in a dedicated state, where the trigger is sent to the internal queue and the variant is converted to data and put into its place in StateData.

Benefits of this model:

- The statechart will run (without being in a loop) until an exit trigger is generated internally or received from the outside of the statechart. This is more like the original statechart concept.

- You can send specific data along each external trigger.

- You avoid this situation: When an asynchronous Run Statechart is waiting for a trigger, it has already read its Inputs making it impossible to send data at the same time as the trigger is generated.

The model above seems to work, but wouldn't it be nice if this third statechart type (aside from syncronous and asyncronous) with its trigger/variant queue was built-in?

If I don't get any serious objection to this idea, I will post it in the Wish List.

Lars-Göran

[Matt W]

QUOTE(Lars-Göran @ Nov 13 2007, 12:29 PM)

Hi all!

I have tried to come to terms with the statechart implementation in the Statechart Module, but I miss the option of running a statechart without the notion of iterations. I have experimented with sending external triggers along with variant data via a queue to the internal of the statechart. Here it is dequeued in a dedicated state, where the trigger is sent to the internal queue and the variant is converted to data and put into its place in StateData.

Benefits of this model:

- The statechart will run (without being in a loop) until an exit trigger is generated internally or received from the outside of the statechart. This is more like the original statechart concept.

- You can send specific data along each external trigger.

- You avoid this situation: When an asynchronous Run Statechart is waiting for a trigger, it has already read its Inputs making it impossible to send data at the same time as the trigger is generated.

Drawback:

- I just realized that the external trigger and the external variant data may not be active in the statechart at the same time.

Wouldn't it be nice if a third statechart type (aside from syncronous and asyncronous) with a trigger/variant queue exposed externally was built-in?

This would also take care of the drawback above, as the variant data would be a dequeued along with the trigger.

If I don't get any serious objection to this idea, I will post it in the Wish List.

Lars-Göran

You lose the use of the inputs and outputs of the statechart (which I've found useful). And there's an easier solution, just use a synchronous statechart with your own queue of data inputs and trigger. I posted a very trivial example on ni's forum.

http://forums.ni.com/ni/board/message?boar...ssage.id=280719

This still requires a while loop, but if you embed it in a subvi you effectively have the same thing. I found the concept of iterations to be helpful once I started using the inputs and outputs of the statechart.

This would be easier if trigger's had built in (and typed) way to pass parameter's with the trigger. Which is a feature that needs to added in my opinion (and can be added onto the current statechart models). Currently I can either use a variant (losing static type checking) or a large cluster (wasting memory).

Matt W

[Lars-Göran]

QUOTE(MATTW @ Nov 13 2007, 07:38 PM)

You lose the use of the inputs and outputs of the statechart (which I've found useful). And there's an easier solution, just use a synchronous statechart with your own queue of data inputs and trigger. I posted a very trivial example on ni's forum.

http://forums.ni.com/ni/board/message?boar...ssage.id=280719

This still requires a while loop, but if you embed it in a subvi you effectively have the same thing. I found the concept of iterations to be helpful once I started using the inputs and outputs of the statechart.

This would be easier if trigger's had built in (and typed) way to pass parameter's with the trigger. Which is a feature that needs to added in my opinion (and can be added onto the current statechart models). Currently I can either use a variant (losing static type checking) or a large cluster (wasting memory).

Matt W

Hi Matt!

I think there's one problem with your solution. If a statechart continously generates internal triggers, your external trigger will never have the chance to get into the statechart.

What I would like, is to have the InternalQueue exposed to the ouside of the statechart, so that external and internal triggers are handled on equal terms.

(The queue then of course isn't internal anymore, so perhaps it should be renamed to "TriggerQueue").

As mentioned before, we will then also have the benefit of rendering the loop around the statechart superfluous.

And as you pointed out, if we could get triggers to carry data along, that would be great. I think I would prefer a variant instead of a cluster, to avoid sending data that is not of relevance for a specific trigger.

Lars-Göran

[Matt W]

QUOTE(Lars-Göran @ Nov 14 2007, 01:06 PM)

Hi Matt!

I think there's one problem with your solution. If a statechart continously generates internal triggers, your external trigger will never have the chance to get into the statechart.

What I would like, is to have the InternalQueue exposed to the ouside of the statechart, so that external and internal triggers are handled on equal terms.

(The queue then of course isn't internal anymore, so perhaps it should be renamed to "TriggerQueue").

As mentioned before, we will then also have the benefit of rendering the loop around the statechart superfluous.

And as you pointed out, if we could get triggers to carry data along, that would be great. I think I would prefer a variant instead of a cluster, to avoid sending data that is not of relevance for a specific trigger.

Lars-Göran

I hadn't thought of continuously generating internal triggers. I'm not sure if this would work but you could ignore the internal queue entirely, and send the internal triggers to the external queue. Personally I like the concept of iterations since it seems to makes timing data acquisition used by the statechart easier.

I meant that each trigger would have it's own cluster (or none), and states that trigger off of that it would have access to that cluster. Much like NewVal in the event structure for a value change event, which only turns into a variant if there's multiple controls with incompatible types.

Matt W

[Lars-Göran]

QUOTE(MATTW @ Nov 14 2007, 05:10 PM)

I hadn't thought of continuously generating internal triggers. I'm not sure if this would work but you could ignore the internal queue entirely, and send the internal triggers to the external queue. Personally I like the concept of iterations since it seems to makes timing data acquisition used by the statechart easier.

I meant that each trigger would have it's own cluster (or none), and states that trigger off of that it would have access to that cluster. Much like NewVal in the event structure for a value change event, which only turns into a variant if there's multiple controls with incompatible types.

Matt W

Interesting idea, ignoring the internal queue altogether and instead use an external queue for both kind of triggers. I will try this out.

I'll also have to check out the NewVal functionality you describe.

Lars-Göran