Function-call and Sorted Order
1 回表示 (過去 30 日間)
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!
Mark McBroom 2018 年 3 月 10 日
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