I’m using the mcb_pmsm_foc_qep_dyno_f28069m example with a TI F28069M LaunchPad and two DRV8305 booster packs in the motor-dyno configuration.
When I run the model with a constant RPM command from the host, both motors behave normally and the reference speed is stable.
However, when I switch to a ramp input from the host model (over the SCI TX/RX link), the target’s Speed_Ref_PU signal occasionally spikes to extreme values, causing the control loop to overflow and the motor to jerk or stall.
I’ve verified that:
The host model sends a continuous ramp through SCI without discontinuities.
The issue persists whether I send only “speed” or include the full SCI data vector (motor select, debug flags, enable bits).
The model works fine with single-step commands or static RPM inputs.
This makes me suspect that the serial communication framing or data synchronization in the receive path is being corrupted when streaming continuous values, possibly because the dyno model’s receive subsystem expects discrete “change-only” packets instead of continuous float updates.

Questions:
Is the dyno example’s SCI receive block designed for discrete or continuous data streaming?
What is the recommended way to send a smooth ramp command from the host without causing overflow?
Would it be more stable to generate the speed profile directly on the target model instead of streaming it over SCI?
Are there any updates or simplified single-motor examples for the F28069M that demonstrate host-controlled ramp inputs safely?
Any advice or updated example links would be greatly appreciated.I’m using the mcb_pmsm_foc_qep_dyno_f28069m example with a TI F28069M LaunchPad and two DRV8305 booster packs in the motor-dyno configuration.
When I run the model with a constant RPM command from the host, both motors behave normally and the reference speed is stable.
However, when I switch to a ramp input from the host model (over the SCI TX/RX link), the target’s Speed_Ref_PU signal occasionally spikes to extreme values, causing the control loop to overflow and the motor to jerk or stall.
I’ve verified that:
The host model sends a continuous ramp through SCI without discontinuities.
The issue persists whether I send only “speed” or include the full SCI data vector (motor select, debug flags, enable bits).
The model works fine with single-step commands or static RPM inputs.
This makes me suspect that the serial communication framing or data synchronization in the receive path is being corrupted when streaming continuous values, possibly because the dyno model’s receive subsystem expects discrete “change-only” packets instead of continuous float updates.

Questions:
Is the dyno example’s SCI receive block designed for discrete or continuous data streaming?
What is the recommended way to send a smooth ramp command from the host without causing overflow?
Would it be more stable to generate the speed profile directly on the target model instead of streaming it over SCI?
Are there any updates or simplified single-motor examples for the F28069M that demonstrate host-controlled ramp inputs safely?
Any advice or updated example links would be greatly appreciated. I’m using the mcb_pmsm_foc_qep_dyno_f28069m example with a TI F28069M LaunchPad and two DRV8305 booster packs in the motor-dyno configuration.
When I run the model with a constant RPM command from the host, both motors behave normally and the reference speed is stable.
However, when I switch to a ramp input from the host model (over the SCI TX/RX link), the target’s Speed_Ref_PU signal occasionally spikes to extreme values, causing the control loop to overflow and the motor to jerk or stall.
I’ve verified that:
The host model sends a continuous ramp through SCI without discontinuities.
The issue persists whether I send only “speed” or include the full SCI data vector (motor select, debug flags, enable bits).
The model works fine with single-step commands or static RPM inputs.
This makes me suspect that the serial communication framing or data synchronization in the receive path is being corrupted when streaming continuous values, possibly because the dyno model’s receive subsystem expects discrete “change-only” packets instead of continuous float updates.

Questions:
Is the dyno example’s SCI receive block designed for discrete or continuous data streaming?
What is the recommended way to send a smooth ramp command from the host without causing overflow?
Would it be more stable to generate the speed profile directly on the target model instead of streaming it over SCI?
Are there any updates or simplified single-motor examples for the F28069M that demonstrate host-controlled ramp inputs safely?
Any advice or updated example links would be greatly appreciated. c2000, sci, overflow, pmsm MATLAB Answers — New Questions

​