Function-call and Sorted Order

Hello, I was wondering if anyone can help me understand what I am seeing in a control model I have developed. This issue relates to the execution order of blocks.

The model in question is intended to run as a serial comms server on target hardware. In the model is a stateflow state machine which sits & waits to receive incoming serial queries. Whenever such a query is received, its data payload is parsed by the state machine, which then initiates an appropriate response transmission (a 10-byte string whose contents vary based on the query).

To initiate the transmission I have the stateflow machine activate a function-call subsystem via a fired event (ie. "send(TrigEvent)"). The now-activated function-call subsystem contains the actual serial TX block which interfaces to the hardware port.

Everything works as expected -- almost. However the "turnaround" from my code is 1 loop time longer than I expect. I have confirmed this with a serial sniffer on the physical line. I cannot account for this one-loop delay.

One thing I have noticed is that, when I turn on the "Display > Blocks > Sorted Execution Order" option, my "Serial TX" block (inside the function-call subsystem) shows a lower execution number than the calling state machine does, meaning it is executed first. Since my model runs on a discrete fixed time step, could this mean that the function-call subsystem won't execute until the next subsequent time step after the state machine fires the event? Instead of the same time step as I am intending? This would explain the delay I am seeing.

I have tried setting the "Priority" in the Properties section for both the state machine & for the TX block (inside the function-call subsystem), to try to force the state machine sooner in the execution order, to no avail. No matter what I do the function-call system has a lower number.

One other note. I realize that any time target hardware interface blocks are involved, those are an easy thing to blame for funny behavior. But I have run this model on two different hardware targets using the official vendor-supplied blocksets, and observed the same behavior on both. One target is a well-known automotive development platform costing tens of thousands of dollars and the other an industrial control system that is also quite pricey; these commercial systems are quite well-tested. I cannot rule out the same bug being in both systems but I do consider it unlikely.

If it matters I am currently developing in Matlab 2014b. Thanks to anyone who can shed some light on this!

Answer 1

[Mark McBroom]

Do you have states in your state machine? Is the processing of incoming messages performed in a different state from the state which send(TrigEvent)? If so, could cause the delay. A couple of ways to address. One is to adjust state machine so that send(TrigEvent) is a action that occurs when you transition out of parsing state. You can also address this by enabling Stateflow's superstep capability as described here: superstep

Answer 2

[Jason Muller]

Thanks Mark, you got it -- I had parallel (AND) states and the event broadcasts were originating from a parsing state. I thought that the event should cause the chart to re-evaluate within the same time step but there must have been some mistake in my semantics. I have taken your suggestion and have thus been able to shave off the loop time. Perhaps I will give supersteps a try at some later date, but since the rest of the machine was not constructed with superstep behavior in mind I am hesitant for fear of encountering unintended behavior.