In Simulink, why do two unrelated modules affect each other?

Question

ZF 2024-7-19，9:43

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2138741-in-simulink-why-do-two-unrelated-modules-affect-each-other

评论： ZF about 8 hours 前

In Simulink, I created two computation modules A and B, as shown in Figure 1. Modules A and B are independent of each other and do not share any data. When A and B are not connected, the time history chart calculated by Module A is shown in Figure 1. However, when A is connected to B, Module A calculates a different time history chart, as shown in Figure 2. Note that Module B does not form a closed-loop with Module A. Why does this situation occur? I would appreciate it if anyone could tell me the reason, thank you very much.

Additionally, I found that as long as module A is connected with the transfer function module (without forming a closed-loop circuit), the time course graph on the oscilloscope will change.

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Paul 2024-7-19，16:31

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2138741-in-simulink-why-do-two-unrelated-modules-affect-each-other#answer_1488161

Even if A and B are not connected, changes in B can causes changes in output of A because those changes in B can affect the step size in the solver. Whether or not that is the case depends on your solver settings and whether or not you have the optimization turned on to not execute blocks that don't need to be executed, which appears to be the case in the first instance as (it appears) there are no signals being logged from B.

In the second case, connecting B to A could affect the step size of the solver as compared to the unconnected case, again depending on your solver settings.

The default solver settings use a variable step solver, so if you haven't changed from the default that's probably what's happening. A quick check would be to run both configurations and compare the tout (default name) output variable from the simulation so you can compare the simulation step times from both cases.

5 个评论
显示 3更早的评论隐藏 3更早的评论

Paul 2024-7-21，0:22

Ok. Let's try next steps.

Are your sure that all three Cases use the same block parameters, like El and the gains in the gain blocks?

Is there anything happening in the NNII function that could cause different results from run to run, like a call to rand or some other similar function? If you run each Case two times in a row, is the scope output the same?

I'm not familiar at all with the DataStore usage, and so not clear on when the DataStoreWrites and DataStoreReads execute relative to the execution of NNII. Actually, I'm surprised that building the model doesn't result in some sort of warning (at least) with that architecture. Anyway, maybe the order of those writes/reads changes for the different configurations for some reason. The DataStoreMemory block has three different parameters for diagnostics that might be helpful to see if this ordering is an issue, and they are defaulted to 'warning'. Are you seeing any warnings in the Diagnostics pane and, if so, are they the same for three different Cases? You can also go to Debug -> Information Overlays -> Execution Order and see if any blocks in the A subsystem are executed in a different order for each Case.

Paul about 4 hours 前

You're very welcome.

Would you mind providing a bit more detail on what the warning was and how it was addressed to solve the problem? Might be useful for others that might run into the same situation.

ZF about 3 hours 前

Of course. An 'algebraic loop(s)' was generated in the original architecture, as shown by the diagnosis in Figure 1. I added 'memory blocks', which seems to have eliminated the 'algebraic loop(s)'. I'm not exactly sure why. But it appears that the problem has been resolved.