Identical blocks in Simulink with identical inputs from different sources results in different solutions

While debugging a model-based controller on a system, I came across the following situation:

I have two identical blocks, each defining a nonlinear, 2nd order continuous system model (it's a pendulum) xdot = f(x,u). The blocks output xdot, which is hooked to an integrator that is looped back around so that the next simulation step can get the updated state x in f(x,u). However, one block gets u = u1 from the controller output, and one gets it from a "Repeating Sequence Stair" block that contains the same command to the plant, u = u2, that the controller outputs (saved from a previous simulation). I've output the inputs to each block and shown definitively that u1 = u2, so as far as I can tell, the systems should be identical; they just get their inputs from different sources.

However, that's not true; instead, the solutions are completely different. I'm using a fixed time-step with a Runge-Kutta (ode4) solver. I've tried other solvers and it doesn't seem to affect the result. I'd really like to know how this is possible.

See this picture http://tinypic.com/r/33n9c0o/6 in lieu of the actual model. The plant input sources are in red, the blocks containing continuous model definitions are in blue, and the states/integrators corresponding to continuous model are in green (so the conflicting outputs are Position and Position1). There's a lot of other stuff but it's also all identical between the blocks and related to the discrete models anyway (i.e. not this issue).

Answer 1

[Guy Rouleau]

Are the colors in your image sample time colors? If yes, do you have the same response using ode1 solver?

If ode1 solver gives same response, then use this central submission to understand the effect of minor steps:

http://www.mathworks.com/matlabcentral/fileexchange/22695-minor-time-step-logging

Another you might want to try is reduce the step size of the fixed-step solver to ensure the dynamics of your system is slower than the solver step size.

Answer 2

[Hannes]

Hi Guy, thanks for your comments. I tried to look into your suggestions. The colors are present purely to draw attention to the parts that matter. Further, I had set the solver to use a fixed step size of dt = 0.01 s in the configuration parameters, so that everything in that previous model would use the same step size.

I tried modifying the system slightly to try out some of what you said. The new system -- http://tinypic.com/r/vyl0dy/6 -- includes sample time annotations in addition to the color formatting and tries to use a smaller step size for the continuous states while still allowing the discrete ones to sample at a lower speed (for realism). This system is solved at 10000 Hz (time step = 0.0001) while all the discrete elements and the controller sample at 1000 Hz, i.e dt = 0.001.

That gave me a Position and Position1 that were closer, but still different (using both ode1 and ode4). I chose not to reduce the time step any further; it was taking a long time to solve, and it seemed unnecessary based on open-loop (uncontrolled) tests of the plant model.

It wasn't clear to me how minor time step logging fit into this; I guess what I don't understand is how two blocks with identical parameters produce different continuous time solutions, when the only apparent difference is that u1 is continuous and u2 is discrete, though their outputs to the workspace (usave and usave1, respectively) are identical (as expected, since I defined u2 based on a saved previous identical run of u1). So what is it about the solver process that leads to different behavior, and which one is more representative of discrete controller outputs interacting with a real continuous physical system?

Thanks

[Guy Rouleau]

My main concern was that you model was mixing continuous sample with "fastest disctere(D1)" at the same rate. This can lead to oscillations in the minor steps. But if the phenomenon you observe still appear with ode1, then we rule that out because ode1 does not have minor steps.

With the information provided, I am running out of idea...