Is it possible to get all springs in a single component/part but conserving different properties/sensors for each spring?

Diego CARO MARTIN
Diego CARO MARTIN Altair Community Member
edited November 2022 in Community Q&A

Hi everyone,

I have a model in which I have 20+ springs (SPR_BEAM to be precise) working at the same time. Those springs have a sensor each that deactivates/activates them in terms on the nodal distance between their two points. 

My main issue is that the model tree gets really busy and illegible, so I would like to include them all in a single /PART or a common Component. The only difference between them is the nodes I use for the sensors. Is there a way to impose a similar condition without having to set all those sensors?

This is related to another question I posted, as I need those spring to stop working when the nodal distance is larger than a certain value (D>Dmax) but work again in case the element gets back to initial position D<Dmax.

I hope this make sense.

Thank you in advance!

Diego

Answers

  • PaulAltair
    PaulAltair
    Altair Employee
    edited October 2022

    If you are using Sensors for this, then the sensor is at property level, so you need a separate property per spring, so no way to have them in the same part

    You can use isflag=2 to have them activate/deactivate with the sensor

    If your tree is just untidy to look at, you could add all these in a /SUBSET (assembly) and collapse them down

    If the distance and spring stiffness is the same in each case though, you could avoid using sensors entirely? And use a non linear Force Displacement curve to get similar behaviour? In this case the spring would not be 'deactivated' but you could set its stiffness very low once the displacement was exceeded?

    e.g. image

    or even if you want no residual loading:

    image

  • Diego CARO MARTIN
    Diego CARO MARTIN Altair Community Member
    edited October 2022

    If you are using Sensors for this, then the sensor is at property level, so you need a separate property per spring, so no way to have them in the same part

    You can use isflag=2 to have them activate/deactivate with the sensor

    If your tree is just untidy to look at, you could add all these in a /SUBSET (assembly) and collapse them down

    If the distance and spring stiffness is the same in each case though, you could avoid using sensors entirely? And use a non linear Force Displacement curve to get similar behaviour? In this case the spring would not be 'deactivated' but you could set its stiffness very low once the displacement was exceeded?

    e.g. image

    or even if you want no residual loading:

    image

    Hi Paul,

    Thank you for the response.

    I will try to organize using /SUBSET so I have a more legible tree.

    On the other hand, Isflag=2 is, for some reason, not working as I expected. So, assuming I need sensors, how would you set up the options for this particular case?

    I also thought about a non linear force displacement curve to avoid sensors. My problem here is that my "Spring" is a /PROP/SPR_BEAM, in which I have constant stiffnes in the axial direction and extremely high stiffness in the other degrees of freedom so the relative movement is not allowed in those.

    So I can make the stiffness zero in terms of the axial displacement, but I cannot make the other 5 degrees of freedom zero in terms of the nodal distance, but in terms of the displacement in that particular degree of freedom. This is why I think I can only use sensors with nodal distance.

    Thanks in advance

    Diego

  • PaulAltair
    PaulAltair
    Altair Employee
    edited October 2022

    I guess the problem you may have with the Isflag is that the 'initial' spring length is set at activation, so if you have deactivated it and reactivated it, it won't retrieve the force it had for displacement relative to t0, but rather it behaves like a new spring activated at sensor switch with no displacement yet?

    I cannot think of a way to easily achieve what you describe exactly.

    What would the required behaviour be for the other DOF if the nodes had become misaligned while the spring is deactivated? Do you want to generate a large shear force at that point? If not, then you may be able to combine the 2 approaches, using 2 springs in parallel, with a non linear spring (not sensor activated) for axial load only and sensor activation for a second spring for the other DOF (albeit this would make the modelling even more complex) 

     

     

  • Diego CARO MARTIN
    Diego CARO MARTIN Altair Community Member
    edited November 2022

    I guess the problem you may have with the Isflag is that the 'initial' spring length is set at activation, so if you have deactivated it and reactivated it, it won't retrieve the force it had for displacement relative to t0, but rather it behaves like a new spring activated at sensor switch with no displacement yet?

    I cannot think of a way to easily achieve what you describe exactly.

    What would the required behaviour be for the other DOF if the nodes had become misaligned while the spring is deactivated? Do you want to generate a large shear force at that point? If not, then you may be able to combine the 2 approaches, using 2 springs in parallel, with a non linear spring (not sensor activated) for axial load only and sensor activation for a second spring for the other DOF (albeit this would make the modelling even more complex) 

     

     

    Hi Paul,

    That is not exactly my problem. I am not worried about the initial elongation/rotation of the spring when it gets "re-activated", I am just concerned about getting it re-activated in the first place. If, as you described, the spring would behave like a new spring activated at sesor switch, that would be good enough, but the problem is that it does not reactive once deactivated.

     

    For the second paragraph: for the other DOF there should be a large shear force if the two nodes get back to the initial position. However, I see how the approach with parallell springs could be useful, even if it makes my model more coplex. I will try this option, while I try to fix the sensor-reactivation problem.

     

    Thanks a lot for your always useful inputs!