I inherited an ADAMS model that involves co-simulation with Matlab/Simulink.
In the Simulink model, before the computed data gets exported back to ADAMS, by an outport block, a unit delay block was included ( 1/z ). The reason for using the 1/z block as I understand it, is to have stability between the ADAMS and Simulink codes.
Without the time delay block, Simulink passes NaNs to ADAMS, causing the simulation to crash. Even though, the time delay block allows for the co-simulation to complete, it inherently modifies the data being passed to ADAMS: the lag + stair-step shape.
What other alternatives are there to using the unit delay that prevents the passing of NaNs to ADAMS without impacting the data being passed?
trying to fix any kind of issue in a time-continuous system model with a (time-discrete) unit delay block is never a good idea. It introduces 'non-physical' time lag, spurious state variables (falsifying linearisation and system size), is degrading both physical and numerical stability, is interfering with Simulink's step-size control, and is degrading solution accuracy.
If I were you, I'ld try to find out and fix what block/subsystem in the Simulink model creates the NaN's at t=0. If you cannot find it, try to simply switch output signals to value zero (or whatever is more or less meaningful) for t<=0. This will affect the very first part of your simulation, but won't have any negative impact later.
let us know if it worked. Anyway, as said: perfect solution was to find and fix the reason of the NaNs. . division by time t=0 in one of the blocks or something like this? Simulink provides many easy ways for debugging such issues.