官方“构建 CAN 通信 Simulink 模型”文档can接收部分，每次运行的结果不一样

参考官方的“构建 CAN 通信 Simulink 模型”文档搭建的简单can发送和接收，我在调试的过程中发现，在transmit前面对can报文unpack，消息如下是可以正常显示的。但是在receive之后在function-call subsystem之后添加scope，有时候只有一条线，如图所示，而我调试的过程中，在subsystem外面加上一个unpack和scope有时候显示这样，有时候显示这个，有时候运行就可以正常显示出多条线，有时候就只有一条线，subsystem内外的unpack后的scope都经常出现结果不一样的情况

Answer 1

[Ritam]

Assuming the CAN Transmit/Receive blocks behave like standard triggered function‑call subsystems, I suspect that the inconsistent scope behavior likely stems from event timing and sample‑time propagation. I would suggest the following:

1. Validate trigger semantics: Confirm the Function‑Call Subsystem’s Trigger Port is configured correctly and that the CAN Receive block generates the function‑call only when a new message arrives.
2. Verify and align sample times: Check compiled sample times across the path; if rates differ, consider using Rate Transition, and consider marking the subsystem "Treat as atomic unit". Use Sample Time Display/Legend (Format > Sample Time) and Compiled Sample Time via get_param(subsystem,'CompiledSampleTime') to spot mismatches.
3. Place CAN Unpack inside the function‑call path: Decode inside the triggered subsystem so each event unpacks the desired number of messages; unpacking outside can execute at a different rate.
4. Review solver configuration: Ensure that the solver settings is as per the requirement.

Also, I would recommend the use of some of the debugging tools in Simulink which may help you diagnose the issue:

• Information overlays can provide visual cues about sample times by enabling Sample Time Colors and the Sample Time Legend, and block annotations can display rate labels for quick verification.
• Diagnostic Viewer offers detailed messages and warnings related to rate mismatches or missed function calls, helping identify timing issues during simulation.
• Simulation Data Inspector (SDI) allows logging and comparison of signals before and after the subsystem, making it easier to analyze event timestamps and value changes.
• Signal logging and scopes can capture event-driven outputs inside the subsystem and time-driven outputs outside (after a Rate Transition), enabling a clear view of how signals propagate across different execution contexts.
• Simulink Profiler provides insights into execution order and hit counts for function-call subsystems, which can help confirm whether triggers and sample times behave as expected.