statechart data flow through

[peabody124]

I'm tryign to put a statechart in a loop where an object is updated outside the statechart and then passed in (where it can be updated).  This is the experiment control into and out of the state chart.

This code ends up extremely awkward because in ever transition (sometimes I modify the object in them) I have to:

1. in exit item cache input to state data

2. in transition load from state data, modify, write to state data

3. in entry transition take from state data to output

4. in all static reactions make sure to pass from input to output

However I still find some changes from my outer loop are getting dropped (i.e. not propagated from statechart input to output).

So I have a two part question: is there a a better way to do this and if not is this the right way to make sure the object is always preserved?  If I read from the inputs or write to the output during the transition itself then it seems that the entry and exit action work will be dropped.

[Greg_S-Video]

Hello peabody124

I don't have your VI myself, but if you single step through yout code, are you able to isolate the exact moment when you start losing changes?  If you upload your VI, other users may also jump into addressing this concern.

Thank you for choosing National Instruments!

[peabody124]

I can write up a test app I suppose.  I was just disappointed that there wasn't documentation detailing the timing of when data is cached to and from inputs/state data/outputs during a transition.  The really weird thing is I have other state transitions when the input information isn't lost even though I'm handling the caching identically in every state and transition (a tedious amount of code to write).  Since stepping isn't really feasible because it's talking to other systems and they will fail if it's not keeping up.

I suppose I'll implement a loop counter and also increment a counter in the object each cycle so I can detect how bad the losses are.  I found a workaround for now (updating the state information before emiting the trigger) but I worry this will lead to more insidious bugs in the future.

Unfortunately this VI is embedded in a fairly complex application so isn't trivial to upload.