Following Cadence Design Systems’ acquisition of the Design & Engineering (D&E) business, the D&E Community Forum on the Nexus Community Center has been migrated in the Cadence Physical System Simulation Community. For more details and if you have any questions, please refer to the FAQ.

Stats

  • State Not Answered
  • Replies 6
  • Subscribers 1
  • Views 1
  • Members are here 0
More Content

Dependent components added to a double a-arm setup. Have I defined them correctly and will the TESTRIG play nice with them?

Woz
I am trying to analyse a kinematically cross-linked double a-arm suspension. I have crated a template and made the standard parts following the conventions used in the fsae_2018 template. The 'gel_lower_control_arm' and 'gel_upright' are conventional.
 
The 'gel_upper_control_arm' is now a big bell-crank that is attached to an additional part 'gel_crosslink_BC' which, in turn, is then attached to the frame through a mount: 'mtl_crosslink_BC_to_frame'. The bell-crank part of the gel_upper_control_arm is attached to a crosslink 'ges_crosslink_uca_l', which ties in to the 'ger_crosslink_BC' and vice versa. (I've attached a picture to help visualise).
 
These crosslinks make the system 'dependent' and essentially make a double a-arm setup behave like a beam (with regards to camber). With the above in mind I have a few questions.
 
  1. Does A/Car care if links pass through each other or will it just solve the system 'mathematically'?
  2. My assembly loads, but will not statically solve when attempting to simulate OWT or PWT within the 25 MAXIT. Could this be related to Q1?
  3. By making the system 'dependent' have I created an issue for the solver?
 
As is stands the symmetric parts are lca, uca, crosslink, upright, pushrods, dampers, springs and pushrod bellcrank. The single parts are the crosslinks. The crosslinks are attached using single spherical joints, everything else uses symmetric bushinsg and joints.
 
My mounts are:
lca_to_frame
crosslink_BC_to_frame
BC_to_frame (pushrod suspension)
damper_to_frame
tierod_to_steering
 
Hopefully the above makes some sense.
 
Woz
Attached Files (1)
  • 0
    I've also attached the message that came up during both the assembly load and the attempted 'opposite wheel travel' simulation. Points to not here (from what I can see) are:
     
    During assembly load:
    • Three input communicator errors (this maybe key?)
    During simulation:
    • Fails to statically solve, reaching max iterations of 25.
     
    Also, a question that I forgot to add to the above. Can a testrig be modified to accept the different communicators?
     
    Woz
  • 0
    I think my model may be falling over due to joints? I do not have all of the same joints as the fsae_2018 tenmplate, so can someone sanity check me please?
     
    I have a double a-arm setup and the lower_control_arm has the following joints/bushings:
     
    lower_control_arm (at frame)
    • revolute joint front and rear, alignment with front and rear frame hard point. [l:gel_lca, J:mtl_lca_to_frame]
    • bushing front and rear, alignment with front and rear frame hard point. [l:gel_lca, J:mtl_lca_to_frame]
    • spherical joint outer. [I:gel_lca, J:gel_upright]
    • NOTE: the fsae template only uses bushings?
     
    tierod
    • sperical joint outer. [I:gel_upright, J:gel_tierod]
    • spherical joint inner. [I:gel_tierod, J:mtl_tierod_to_steering]
    • NOTE: the fsae template seems to have extra/different joints and I'm not sure why? Example: the tierod inner has the same I/J, but uses a convel joint???
     
    In the above two components, is there a need for any other attachment? Do I need to specify a front AND rear revolute joint on the lca if the the alignment is along line (front to rear)?
     
    Just trying to eliminate any potential issues in the more basic parts of the system.
  • 0
    Yes, if you are only using joints, you are very likely to overconstrain your system and it might then lockup.
    Then there is the fact that there are nothing like a perfectly rigid joint in real life, so a smart use of bushings might reflect reality better.
    And yes, your system is seriously overconstrained:
     Degree-of-freedom analysis identified redundant constraints in the model:
     -------------------------------------------------------------------------
      - deactivating constraint equation Zi.Yj in model.ccar_frontsusp.jorrev_lca_rear
      - deactivating constraint equation Zi.Xj in model.ccar_frontsusp.jorrev_lca_rear
      - deactivating constraint equation X Delta in model.ccar_frontsusp.jorrev_lca_rear
      - deactivating constraint equation Zi.Yj in model.ccar_frontsusp.jolrev_lca_rear
      - deactivating constraint equation Zi.Xj in model.ccar_frontsusp.jolrev_lca_rear
      - deactivating constraint equation X Delta in model.ccar_frontsusp.jolrev_lca_rear
      - deactivating constraint equation Zi.Yj in model.ccar_frontsusp.jorrev_lca_front
      - deactivating constraint equation Zi.Xj in model.ccar_frontsusp.jorrev_lca_front
      - deactivating constraint equation Zi.Yj in model.ccar_frontsusp.jolrev_lca_front
      - deactivating constraint equation Zi.Xj in model.ccar_frontsusp.jolrev_lca_front
     
     
     
    Regarding the tie-rod using a convel joint: If you are using only spherical joints on both ends, the rotation of the tie-rod along it's length is unconstrained and that can case problems for the solver. Old trick is to always use a hooke or convel at one end (but never at both). If there are extra joints in the middle of the tie-rod, they are likely there for the toe adjustment.
     
    There is no inherent problem for ADAMS/Car to handle a dependent suspension. That is done all the time.
     
     
     
     
  • 0
    Thanks JSlatten, I'll make some changes to the joints and add in some bushings too.
     
    Can I confirm that your first "Yes" was in answer to my third post? Do you know is the model will lock up if links pass through each other? Regardless, I will change them to better replicate what will happen in real life.
     
    Woz
  • 0
    No, geometry does not matter unless you explicitly define contacts between them. Otherwise they pass unhindered through each other.
Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.