Implemented FreeWheel

[AHaumer]

As mentioned in #3977: I see that we have a rather sophisticated Mechanics.Rotational.Components.OneWayClutch, but no simple ideal freewheel (like the Electrical.Analog.Ideal.Diode). We could introduce such a component for usage e.g. in bicycle models.

[tobolar]

Is there any reason to not extend from Modelica.Mechanics.Rotational.Interfaces.PartialCompliantWithRelativeStates as e.g. Rotational.Components.Clutch does?

With 7e6f6674cba0ccd070a74ff59cea7f917a52fbec, the freewheel extends now from Mechanics.Rotational.Interfaces.PartialCompliant (without the state selection since it could be problematic). Thus, the sign convention of phi_rel (and w_rel) established for all rotational components is assured now. Consequently, the sign of w_rel and tau changes - compared to the original implementation. The example models work fine.

[christiankral]

1. Some time ago we were trying to get rid of all the "Diagram" drawings that explain the model. Instead, the "Diagram" diagram shall be added to the documentation. ~~I will add it.~~
2. The diagram tau vs w_rel has to be adapted, because:

With https://github.com/modelica/ModelicaStandardLibrary/commit/7e6f6674cba0ccd070a74ff59cea7f917a52fbec, the freewheel extends now from Mechanics.Rotational.Interfaces.PartialCompliant (without the state selection since it could be problematic). Thus, the sign convention of phi_rel (and w_rel) established for all rotational components is assured now. Consequently, the sign of w_rel and tau changes - compared to the original implementation. The example models work fine.

3. The currently implemented diagram is a bit misleading, as it is not clear what the parameters tauRes and wRes really mean. The current "Diagram" view shows:

[christiankral]

Before implementing a change I would like to discuss the meaning of the parameters tauRes and wRes:

The current implementation is:

• if free = false the characteristic is indicated by tau = tauRes @ w_rel = 1 (1/s)
• if free = true the characteristic is indicated by w_rel = -wRes @ tau = -1 (Nm)

Hmmm.... the actual implementatioin is somehow avoiding the units that specify the slope of the two branches in the diagram. The diode models uses Ron (unit V/A) anf Goff (unit A/V): this makes a lot more sense to me.

a. Creating the new units "Nm.s" and "1/(s.Nm)" may be one way to resolve this point.

b. We could improve the description to better explain the meaning of tauRes and wRes: this, however, seems not to be a sound way of dealing with this problem, as we avoid the slopes -- which indicate the physical nature of the model.

@AHaumer @tobolar any ideas on how to resolve this "unit" issue?

[christiankral]

OK, possibly the unit SI.RotationalDampingConstant could resolve this issue...

[tobolar]

The current implementation is:

• if free = false the characteristic is indicated by tau = tauRes @ w_rel = 1 (1/s)
• if free = true the characteristic is indicated by w_rel = -wRes @ tau = -1 (Nm)

To my understanding, the implementation is:

• if free = false then tau = (-)flange_a.tau -> s -> w_rel = s*tauRes
• if free = true then w_rel -> s -> tau = s*wRes

Hmm, the documentation says:

• free = false: torque is transferred with a residual difference wRes of relative angular velocity of the flanges.
• free = true: the flanges move independently except a residual friction torque tauRes.

It seems this fits not well.

[AHaumer]

@tobolar and @christiankral thanks for taking care! I need some free hours to consider the changed sign convention ... then I'll propose the following:

• Keep the "Diagram" drawing, but check whether it has to be adapted to the changed signs.
• Check the documentation whether it has to be adapted to the changed signs.
• Replace the parameter tauRes by RotationalDampingCoefficientFree.
• Replace the parameter wRes by 1/RotationalDampingCoefficientLocked.

[AHaumer]

@tobolar and @christiankral I think a have a sound solution (looks like a translation of the electrical diode):

  parameter SI.RotationalDampingConstant residualFriction=1e-5 "Residual friction coefficient (free = true)";
  parameter SI.RotationalDampingConstant torqueTransmission=1e5 "Torque transmission coefficient (free = false)";

• free = false: flange_a is driving flange_b; residual slip is defined by w_rel = tau/torqueTransmission.
• free = true: flange_b rotates (nearly) independent of flange_a; residual friction is defined by tau = w_rel*residualFriction.

[tobolar]

@AHaumer , @christiankral Thinking again about the two "residual" parameters. One can understand tauRes at free=true being a residual torque due to some friction occurency between the two flanges. Thus, for me both tauRes (N.m) and also residualFriction (no SI unit!) could be acceptable. Regarding wRes (rad/s), this is a sort of slip velocity ("Schlupf") which occurs at free=false and forces w_b being smaller then w_a. So to me, the current documentation of the model is fine and provides an explanation everybody can follow. (I know, you both clarified this already. ;-) )

I'm still stumbling about the two parameters. Using tauRes and wRes has an advantage that user can use its own terms to get they values, e.g. the friction. In contrast, torqueTransmission is somehow fancy.

Regarding units - both tauand w_rel depend, in fact, on the unitless variable s which only "transfers" value, not unit. So I would tend to b) in https://github.com/modelica/ModelicaStandardLibrary/pull/4004?notification_referrer_id=NT_kwDOAJJQ8rIzODg0MzUyMzcxOjk1ODg5Nzg#issuecomment-1204413469. Of course, this makes plotting of the two branches in the diagram difficult.

[christiankral]

@tobolar Would the following wording make it better on your opinion:

parameter Real(final unit="rad/N/m/s") residualAngularVelocity =1e-5 "Residual angular velocity coefficient (free = false)";
...
  w_rel = s*unitTorque         *(if free then 1 else residualAngularVelocity);

[tobolar]

Would the following wording make it better on your opinion:..

Sounds good. The following could be a reasonable implementation now:

parameter Real residualFriction=1e-5 "Residual friction coefficient (if free = true)";
parameter Real residualAngularVelocity=1e-5 "Residual angular velocity coefficient (if free = false)";
...
w_rel = s*unitAngularVelocity * (if free then 1 else residualAngularVelocity);
tau   = s*unitTorque          * (if free then residualFriction else 1);

The documentation shall be modified then:

free = false: flange_a is driving ... ... tau = w_rel / residualAngularVelocity;

Regarding the two equations for tauin the documentation (where neither unitAngularVelocity nor unitTorque is used), the correct units of the two parameters shall be:

• residualFriction (unit="N.s")
• residualAngularVelocity (unit="1/N/s")

but it seems to be strange since one could, in general, expect both friction and a coefficient being unitless.

[christiankral]

w_rel = s*unitAngularVelocity * (if free then 1 else residualAngularVelocity);
tau   = s*unitTorque          * (if free then residualFriction else 1);

On my understanding the units of the proposed equations are not correct. They shall rather be:

parameter residualFriction (unit="N.m.s")=1e-5 "Residual friction coefficient (if free = true)";
parameter residualAngularVelocity (unit="1/N/m/s")=1e-5 "Residual angular velocity coefficient (if free = false)";
w_rel = s*unitTorque          * (if free then 1 else residualAngularVelocity);
tau   = s*unitAngularVelocity * (if free then residualFriction else 1);

Note, that I swaped unitTorque and unitAngularVelocity in the two equations.

[christiankral]

• residualFriction (unit="N.s")
• residualAngularVelocity (unit="1/N/s")

@tobolar As we deal with torques (not forces) the units shall rather be N.m.s and 1/N/m/s, isn't is?

[christiankral]

Alternatively we could consider the unit rad, but I am not sure if this makes sense.

parameter residualFriction (unit="N.m.s/rad")=1e-5 "Residual friction coefficient (if free = true)";
parameter residualAngularVelocity (unit="rad/N/m/s")=1e-5 "Residual angular velocity coefficient (if free = false)";

[tobolar]

@christiankral IMO, one would expect regarding a mechanical component:

1. "friction coefficient" (mu overall in MSL) is generally a unitless quantity,
2. and so is probably also with "angular velocity coefficient".

This is why I tend to have no units. Optionally, we schould think again of changing "residualFriction" name and description. Not sure if this also holds for residualAngularVelocity.

[HansOlsson]

Note that unitless can mean two different things:

• A variable without a specified unit.
• A variable with unit="1", also known as dimensionless.

To me the friction coefficient should be of the second kind for translational friction, but I notice that often in MSL it is of the first kind. (And it is generally not possible to deduce its unit because it appears as mu*cgeo where the geometric coefficient also is without unit.)

For rotational friction it is not clear to me if mu or cgeo should handle the conversion between force and torque.

[tobolar]

@HansOlsson Need to open a new issue? (See Sec. 2.3.3 Dimensions of quantities of the BIPM: The International System of Units – 9th edition (2019) - probably you know it already. )

[HansOlsson]

@HansOlsson Need to open a new issue?

Possibly. You decide.