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

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.

Answer 1

[Paul]

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.

[ZF]

Thank you for your reply. However, the issue remains unresolved. I have re-uploaded the three calculation scenarios: Case 1 to 3. All three scenarios are solved using OED4 with a fixed step size of 0.001. As shown in the diagrams, the three time histories are all different,and their step times are consistent.Modules A and B are both very simple computational modules, yet the presence of the transfer function module affects the calculation results. This puzzles me greatly.

[Paul]

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.

[ZF]

Thank you for the reminder. I hadn't paid attention to the DataStoreMemory block warning before. Since this warning did not have a negative impact in my previous framework construction, I ignored it. Now, following the prompt of the warning,the problem seems to have been solved. Thank you very much.

[Paul]

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]

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.