hexagon logo
Register Sign in
  • State Not Answered
  • Replies 3 replies
  • Subscribers 14 subscribers
  • Views 139 views
  • Users 0 members are here
Options
Related

Limited data points (10 million) in Cosim with Adams View and Simulink

Sebastian Netter

Dear all,

I'm running a co-simulation with mechancial system representation in Adams and a control system in simulink. The interface is established via co-simulation (controls plugin): injection of electrical torque into ADAMS model, feedback of position to Simulink.

Due to representation of the electrical subsystems I need to simulate with a very high sampling rate (100kHz).
Executing the complete foreseen trajectory takes ~240s. This results in a total of 24.000.000 time points for the complete duration.

The simulation runs without any issues for 100s. After 100s ADAMS stops updating my state variables and the output value stays identical to the last value at t = 100s for the rest of the simulation duration.
Consequently, my closed loop controller saturates at the control variable limit. The simulation in Matlab runs until the nominally defined simulation duration of ~240s.
Please find below a plot of the desired (blue) and actual position (orange) of my mechanism illustrating the nominal behaviour until t = 100 and the behaviour after t = 100s.

The issue I'm experiencing always happens at exactly 10 million time steps in ADAMS.
- Meaning at a sample rate of 100 kHz ADAMS stops the communication at exactly 100s
- I also checked with a sample rate of 50 kHz. Consequently, ADAMS stops the communication at exactly 200s.

Has anybody already encountered this issue and/or knows how to fix it?

Thanks a lot,

Sebastian



Addition of explanation of displayed signal.
[edited by: Sebastian Netter at 11:58 AM (GMT -5) on May 19, 2025]
  • 0

    Hi Sebastian,

    Thanks for sharing this query. Unfortunately, we haven't seen this issue before, and it seems that we would need to debug the issue. That being said, would it be possible for you to log a case ticket using our simcompanion portal, and then we can schedule a debugging call for the same.

    In case this is not possible, please share the sample model with which the issue is reproducible so we can investigate the same at our end.

    Hope this helps!

    Regards,

    Saurabh Saste

    Hexagon Technical Support

  • 0

    This is interesting, and I can see a 1e7 sneaking into the code somewhere.

    One way to get around this is to use the FMU export, and import the Adams FMU into Simulink instead of a direct cosimulation, I know this limitation is not there  (at least not on the Adams side) as we are running Adams FMU's in real-time simulators for hours.

    There is of course a possibility that  the limitation is on the Simulink side.... IT will be investigated.

  • 0

    Dears,

    thanks a lot already for your feedback!

      As you suggested I created a case ticket via the simcompanion portal (Case ID: 01184384). I also added a minimum working example with a ball fixed to a spring. I choose the same sampling rate. Therefore, one can see a clean oscillation of the ball on the spring until 10 million communications between ADAMS and Simulink. After that, there is a freeze of the ADAMS state variable, which is sent to Simulink. In this case the ball vertical position.

    Yes, I agree. There seems to be going on something after 1e7 communications. Im not familiar with ADAMS FMU export. Maybe this could be an alternative if the topic within the direct cosimulation should persist.

    Please note: -> Please excuse if I cannot come back directly to your well appreciated feedback, but I will be on vacation in the coming days.

    Thanks a lot,
    Sebastian

© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement