Function-call and Sorted Order

2 views (last 30 days)
Jason Muller
Jason Muller on 22 Feb 2018
Answered: Jason Muller on 23 Mar 2018
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!

Accepted Answer

Mark McBroom
Mark McBroom on 10 Mar 2018
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

More Answers (1)

Jason Muller
Jason Muller on 23 Mar 2018
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.

Categories

Find more on Complex Logic in Help Center and File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!