In the previous section, we discussed Basic Rotational Components and showed how to build a system model from basic components. In this section we will demonstrate how to incorporate event handling, which we will use when modeling a backlash. Furthermore, we’ll also show how to use parameter values to effect the interface of a component.
Let’s start our exploration of more advanced component models by looking at a rotational backlash element. The equation for a backlash model is very simple:
In Modelica (where is
phi_rel), this component can be described as follows:
within ModelicaByExample.Components.Rotational.Components; model Backlash "A rotational backlash model" parameter Modelica.SIunits.RotationalSpringConstant c "Torsional stiffness"; parameter Modelica.SIunits.Angle b(final min=0) "Total lash"; extends ModelicaByExample.Components.Rotational.Interfaces.Compliant; equation if phi_rel>b/2 then tau = c*(phi_rel-b/2); elseif phi_rel<-b/2 then tau = c*(phi_rel+b/2); else tau = 0 "In the lash region"; end if; end Backlash;
We can add an instance of this backlash model into our previous model by placing it in parallel with the spring and the damper, i.e.,
If we use the inheritance mechanism in Modelica, the resulting Modelica model is quite simple:
within ModelicaByExample.Components.Rotational.Examples; model SMD_WithBacklash "The spring-mass-damper system with backlash" extends SMD(inertia2(phi(fixed=true, start=0)), inertia1(phi(fixed=true, start=0), w(start=5))); Components.Backlash backlash(c=1000, b(displayUnit="rad") = 0.5) annotation ... equation connect(inertia1.flange_b, backlash.flange_a) annotation ... connect(backlash.flange_b, inertia2.flange_a) annotation ... end SMD_WithBacklash;
In this case, if the relative angle between
inertia2 is more than 0.5 radians (i.e., the value of
our backlash instance), then the torque from the backlash element will
If we simulate this model, we can see the impact that the backlash’s presence has on the response of the system:
Another thing worth looking at (which we will delve into much more in the next topic) is the force felt by the mechanical ground element. Looking at our schematic, it is clear that the role of the mechanical ground element is to fix the angular position on one side of our system. An equation to constrain the motion (or lack of motion, in this case) of a point in the system is called a kinematic constraint.
When a kinematic constraint is imposed on a system, the component imposing the constraint must generate some kind of force or torque in order to affect the motion of the system. This is called a reaction force or reaction torque.
The following plot shows the reaction torque that the mechanical ground element must impose on the system in order to fix the angular position:
As we saw in the previous example, the behavior of the mechanical ground element is such that it must exert a reaction torque on the system to constrain the motion of the system. In this section, we will examine this effect a bit closer.
To demonstrate some of the complexities of kinematic constraints, we need to create a mechanical gear model. In this model, we will ignore the inertia of the gear elements, efficiency losses in the gear and any backlash that might exist between the teeth in the gear. Recall our discussion about Digging Deeper earlier in this chapter where we mentioned that component models should focus on individual physical effects. That same principle applies here. Inertia, friction and backlash can all be modeled as individual effects (as we’ve already seen in this chapter). There is no need to lump them into our gear model. Instead, we will focus only on the relationship between gear input speed and output speed.
In a typical system dynamics class, the equations that describe the behavior of a gear are derived as follows. First, we start with the understanding that a gear introduces a relationship between the input speed and the output speed, i.e.,
where is the gear ratio. Recall that we assume the gear to be perfectly efficient. This means that the power going into the gear must equal the power going out which we can express mathematically as:
Note we are using the Modelica sign conventions here where a positive
value for the flow of a conserved quantity means a flow into the
component. In this case, is the flow of
mechanical power into the gear from
flange_a and is the flow of mechanical power into the gear from
flange_b. Therefore, their sum must be zero, since our gear model
does not include the inertia of the gear elements and, therefore, no
way to store energy or momentum within the gear model.
Given these two facts, we can substitute the relationship between the speeds into the relationship between the powers and get:
This allows us to cancel out from the equation and rearranging terms gives us:
Such a derivation will probably look very familiar to most engineers. But it is important to recognize that there is something missing here. More specifically, there is something implicitly assumed that is not necessarily a reasonable assumption.
To understand the issue, let’s first consider Euler’s second law:
In other words, the sum of the torques on a body should be equal to the amount of angular momentum being accumulated by the body. Recall that our gear model doesn’t include the inertia of the gear elements. As such, it has no capacity to store energy or angular momentum. If that is the case the previous equation simplifies to:
Our gear has only two external torques, and . Using the relationships we derived earlier, we know that their sum is:
This equation implies that for any gear ratio, , not equal to
1.0, the torque at
flange_a (and consequently, the torque at
flange_b as well) must be zero. But this cannot be correct if our
gear is to function as a gear.
What this mathematical relationship is showing us about the physical behavior of the system is more clearly demonstrated in this relationship:
The first term, is the torque entering the gear from
flange_a. The second term, is the torque
entering the gear from
flange_b. This equation tells us that
these two torques will never sum to zero (for ). It
appears that we have proven, mathematically, that .
But in fact, what we are really demonstrating is that there is an
imbalance in the equation. This imbalance is the result of having
forgotten something in our formulation. What is missing is the
If you aren’t already familiar with this issue, you might be puzzled about where this reaction torque comes from. After all, we have only two mechanical connections to this gear and we have expressions for the torque at both of these points. But along the way, there was an implicit assumption that the housing of the gear is grounded. In reality, a gear has three mechanical connections. The third connection is the one between the housing of the gear and whatever the gear is mounted to. If the housing is connected to a mechanical ground, then our equations so far are correct as we can capture the behavior of such a (grounded) gear as follows:
within ModelicaByExample.Components.Rotational.Components; model GroundedGear "An ideal non-reversing gear with grounded housing" parameter Real ratio "Ratio of phi_a/phi_b"; extends Interfaces.TwoFlange; equation ratio*flange_a.tau + flange_b.tau = 0 "No storage"; flange_a.phi = ratio*flange_b.phi "Kinematic constraint"; annotation ... end GroundedGear;
Note that instead of using the relationship
GroundedGear model, we instead used the relationship
. This is actually more accurate since,
once assembled, the teeth of the gear really do constrain the angular
positions of the two shafts. Furthermore, there may be some
applications (e.g. stepper motors) where preserving this
relationship between positions, and not just velocities, could be very
GroundedGear model, we can then build a system model
using this gear as follows:
Note this system has two parallel mechanisms. The first one uses the
gear model we just developed. The second one replaces the assembly of
the gear and inertias with a single inertia. This single inertia was
specifically chosen to have the “effective inertia” of the
assembly. As a result, when we simulate this system, we see that
inertia3 have the same response:
As previously mentioned, the issue with the
GroundedGear model is
that it is implicitly assumed to be grounded. This assumption may not
always be a reasonable one (e.g., in an automotive transmission
where gears are generally connected to compliant mounts). To
understand how much different the response of a system can be between
grounded and ungrounded gears we will first create a more complete
gear model that is not implicitly grounded and then compare its
performance, side by side, with gears that are grounded.
Without the implicit assumption that the housing of the gear is grounded, the kinematic relationship between the two shafts and the housing is more completely expressed as:
Although it is beyond the scope of this discussion, we can derive the following two equations using conservation of energy and conservation of momentum:
Combining these relationships and adding an additional mechanical connector to represent the housing, we get the following Modelica model for an ideal gear:
within ModelicaByExample.Components.Rotational.Components; model UngroundedGear "An ideal non-reversing gear with a free housing" parameter Real ratio "Ratio of phi_a/phi_b"; extends Interfaces.TwoFlange; Modelica.Mechanics.Rotational.Interfaces.Flange_b housing "Connection for housing" annotation ... equation (1-ratio)*housing.phi = flange_a.phi - ratio*flange_b.phi; flange_b.tau = -ratio*flange_a.tau; housing.tau = -(1-ratio)*flange_a.tau; end UngroundedGear;
Now, let us build a system model with three different mechanisms. In each mechanism the parameters for the gear, inertia, spring and damper are all identical. The only difference is whether we use an implicit grounded gear, an explicitly grounded gear or a gear that is not directly connected to ground, but is instead connected through a very stiff mounting system. The schematic for our system looks like this when rendered:
The first thing we would expect is that the response of the mechanism with the implicitly grounded gear should be identical to the response of the mechanism with the explicitly grounded gear. This is verified by the following plot:
But the question still remains, how much difference would it make if we assumed that a gear was implicitly grounded when, in fact, it wasn’t? This is clearly demonstrated in the following plot:
So far in our discussion of rotational systems, we’ve created two
different gear models,
GroundedGear, which is implicitly grounded,
UngroundedGear, which includes a mechanical connector for the
housing. Ultimately, the equations used by these two components are
quite similar and there is a considerable amount of common code
between them. As we’ve talked about before, redundancy like this
should be avoided.
One way that we can avoid redundancy in this case is to combine these two models. It might seem like this is impractical since they have very different underlying assumptions and, more importantly, different interfaces (i.e., different connectors). Nevertheless, it is possible to combine these models by making use of something called a conditional declaration.
Consider the following
within ModelicaByExample.Components.Rotational.Components; model ConfigurableGear "An ideal non-reversing gear which can be free or grounded" parameter Real ratio "Ratio of phi_a/phi_b"; parameter Boolean grounded(start=false) "Set if housing should be grounded"; extends Interfaces.TwoFlange; Modelica.Mechanics.Rotational.Interfaces.Flange_b housing(phi=housing_phi, tau = -flange_a.tau-flange_b.tau) if not grounded "Connection for housing" annotation ... protected Modelica.SIunits.Angle housing_phi; equation if grounded then housing_phi = 0; end if; (1-ratio)*housing_phi = flange_a.phi - ratio*flange_b.phi; flange_b.tau = -ratio*flange_a.tau; end ConfigurableGear;
In particular, notice that the declaration of
housing ends with
if not grounded. When
if appears at the end of a declaration,
it indicates that the variables only exists if the condition following
if is true. So when the
grounded parameter is true, there
housing connector in this model. Furthermore, the equations
included, as modifications, in the declaration of
disappear with the declaration.
Meanwhile, in the
equation section, we see that the
statement there provides an additional equation,
the case when the model is grounded. This is necessary because the
housing_phi is always present (i.e., there is no
at the end of its declaration) so there must be an equation for it.
To understand more completely what is going on here, recall that the number of equations required by a component model is equal to the number of flow variables across all the component’s connectors + the number of (non-parameter) variables declared in the model.
The following table summarizes how these things add up for the case
grounded is true and the case where it isn’t:
|Number of variables||1 (
|Equations in declarations||0||2 (from
When using conditional declarations, it is very important to make sure that the number of equations provided balances with the number of equations required for all possible conditions. In this case, we have only two conditions to concern ourselves with and we can clearly see from this table that we have met this requirement in both cases.
The following model demonstrates how we can now use the
ConfigurableGear models as both an implicitly and explicitly
And, as we would expect, the response for
inertia4 are identical: