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

Repeated ADAMS<=>Imported Simulink Control simulations crashes ADAMS

PMotaghe
I have an ADAMS <=>Simulink Controls Import (as an ESL DLL) working, but it only runs the FIRST time. Running a 2nd time causes ADAMS to crash.  Beside the Simulink Contorl Import ESL GSE, my ADAMS model also has a user-defined GFORCE subroutine (DLL) that works fine (even repeatedly, when the Simulink Controls Import ESL GSE is not present)
  • 0
    Hi,
    Can you share the .msg file for the working/failing simulations, please?
    Thanks,
  • 0
    Hi Alexis - I've attached a copy of .msg files from the first run, then the 2nd run (which bombs). I'm increasingly suspecting there's a different level of "resetting" going on with models involving DLL-integrated Simulink models, and that's somehow messing with the initialization of the Python interpreter I have programmed into my user-written GFORCE C routine (Python function is called to compute and provide force feedback). I have observed IFLAG being set to 5 when this Simulink-integrated simulation is stopped, unlike the model WITHOUT the integrated Simulink version.
  • 0
    I have figured out the cause of the problem.
     
    It turns out that when the integrated ADAMS<=>Simulink simulation is stopped, ADAMS runs through my GFORCE user routine one more time with IFLAG=5 (does not happen w/o Simulink integration). Apparently, the next time the simulation is started, all the C routine variables values (even those declared static – ie, persistent across GFORCE Gfosub routine calls) are lost and the routine gets called just as it would be for the very first time, with one exception: the prior-initialized Python engine (ie, from the first run) remains initialized – however, references to loaded/initialized modules are lost and need to be re-loaded/re-initialized. 
     
    My integrated sim was crashing because the GFOSUB C routine was requesting variable values from the Python session using a no-longer-valid Python object reference pointer (lost after IFLAG=5 call). Once I fixed that, the ADAMS simulation can now be called multiple times without a problem.
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement