6. Cams and Gears

Overview

This chapter covers the modeling of contacting cam surfaces and gear trains with MechanicalSystems. Cam constraints allow the definition of arbitrary curves or surfaces that operate in tangent contact with other curves, surfaces, or points in a Mech model. Cams are supported in 2D or 3D models, and 3D cams may be spatial curves or surfaces.
Gear constraints are used to model several types of nominal gear relationships, such as a pair of spur gears, a rack and pinion, or a lead screw. These constraints are referred to as nominal gear constraints because only the nominal rotary motion is modeled, not the tooth-to-tooth interactions of an involute gear set.

6.1 Cam Constraints

A cam relationship is considered to be any relationship in which an arbitrarily defined space curve or surface is constrained to be in intimate contact with another point, curve, or surface. MechanicalSystems provides several special constraint functions that allow such arbitrary geometric elements to be used in the mechanism model. The definitive characteristic of cam constraints is that they force two surfaces to be simultaneously in contact with each other and, in most cases, tangent with each other at the point of contact.

6.1.1 2D Cam Constraints

The 2D cam constraints provided by Modeler2D cover four elementary cases of a cam and follower mechanism. In each case, the cam surface is defined by the locus of a single 2D point that is a function of one symbolic parameter. For example, the following 2D points are defined parametrically as functions of the symbol s. Each of these locuspointi would be valid as a Modeler2D cam profile.

Here is a valid Modeler2D cam profile.

In[1]:=

Out[2]=

Here is another Modeler2D cam profile.

In[3]:=

Out[4]=

Note that although the Modeler2D cam constraints constrain one degree of freedom in the mechanism model, they actually add two (or three, as in CamToCam1) equations to the model. This is because each cam constraint also adds one (or two) symbols to the model's dependent variable list for a net loss of one degree of freedom. This anomaly is of no consequence to the user except when a cam constraint is used within TimeSwitch or StageSwitch. In these cases, the added symbol in the cam constraint must be dealt with in the other stages of the switch function, usually by using the Modeler2D Constraint function to set the added symbol equal to a constant.

2D cam constraints.

The locus point that is passed to a Modeler2D cam constraint must be a valid Modeler2D point object containing the parametrically defined point. Also, the point must evaluate to a two-element list of differentiable expressions that are functionally dependent on the parameter alpha at the time the constraints are processed with SetConstraints. This is because the locus point is differentiated with respect to the parameter alpha by SetConstraints. Thus, if the locus point is not a function of alpha when passed to SetConstraints its derivative will be zero.
A special graphics function CamPlot is provided to parametrically plot the cam profiles in global coordinates. Note that CamPlot returns a Mathematica graphics object with the head Graphics, not a graphics primitive like most other Modeler2D graphics functions.

A cam-specific graphics function.

CamPlot produces the same output as would the built-in Mathematica ParametricPlot, except that CamPlot transforms the local cam profile into the global coordinate system. CamPlot does not evaluate directly to a Graphics object unless numeric values for the coordinate transformation are available. Instead, CamPlot evaluates to a SysPlot object that evaluates to a Graphics object when numbers are available for the transformation.

This loads the Modeler2D package.

In[5]:=

CamPlot returns a SysPlot object.

In[6]:=

Out[6]=

When numbers are available for X2, Y2, and 2, the SysPlot object evaluates to a Graphics object.

Here is the repositioned cam.

In[7]:=

Out[7]=

6.1.2 Example 2D Cam Mechanism

To demonstrate the use of Modeler2D cam functions a 2D model of a rotating cam with a flat follower is developed. The model consists of two moving bodies, the cam and the follower.

Here is the 2D cam-follower mechanism.

Cam Profile

The cam profile used for this mechanism is defined in terms of trigonometric functions of the symbol alpha. The cam profile expression may contain user-defined parameters that are defined at runtime, but all of the functional dependence on the controlling parameter alpha must be present when the cam constraint is processed with SetConstraints. Thus, it is not possible to leave the cam profile defined as simply a two-element list of symbols, such as {xcam, ycam}, and then define xcam and ycam as functions of alpha at runtime.

Here are two parametric expressions defining the locus of the cam profile.

In[8]:=

Here is a plot of the cam profile.

In[12]:=

Out[12]=

Bodies

Three bodies are used for the cam-follower model.

Names are defined for each of the body numbers in the model.

In[13]:=

Here are all of the bodies in the cam-follower model.

This is to set a nonzero initial guess for the rocker.

In[16]:=

Constraints

Three regular constraints and one CamToLine1 constraint are required to model the cam-follower mechanism.

Note that while CamToLine1 constrains one degree of freedom in the model, it actually adds two equations (one that forces the locus point to lie on the line and one that forces the line to be tangent to the cam at the point of contact) and one unknown alpha to the model.

Here are the constraints for the cam-follower mechanism.

In[17]:=

Runtime

The cam-follower mechanism model can now be run in the usual manner. Note the presence of the cam parameter alpha in the solution rule. At this value of alpha the cam locus point is placed at the point of contact between the cam and the follower.

Now we run the model at T = 0.15.

In[18]:=

Out[18]=

Here is the cam-follower mechanism at T = 0.15.

Now run the model at T = 0.30.

In[19]:=

Out[19]=

Here is the cam-follower mechanism at T = 0.30.

6.1.3 3D Cam Constraints

The 3D cam constraints provided by Modeler3D cover eight elementary cases of a cam and follower relationship. The 3D cam profiles used by Modeler3D fall into two basic categories: spatial surfaces and spatial curves. Spatial surfaces are defined by the locus of a single 3D point, the coordinates of which are a function of two independent parameters. Space curves are defined by a point that is a function of a single parameter.
In practice many 3D cam profiles are 2D in nature, in which case they are modeled using the techniques that were developed in Section 6.1.2 on 2D cams. Any 2D cam profile can be converted to a 3D space curve by inserting or appending a third constant coordinate to the 2D locus point.
Even when a true 3D surface profile is required, it can often be built up from the sum of two 2D curves that are functions of two different parameters. The following example uses one of the 2D cam profiles that was developed in Section 6.1.1 to generate a 3D cam surface. The only change to the 2D cam is the addition of the parameter t that directly specifies the local y coordinate of the cam. This example would serve as a valid cam profile for any Modeler3D cam constraint function.

Here is a valid Modeler3D cam profile.

In[20]:=

Here is a plot of the cam profile.

In[21]:=

Out[21]=

Note that although the Modeler3D cam constraints constrain one degree of freedom in the model (or two in the case of CurveToPoint2), they actually add between two and five equations to the model. This is because each cam constraint also adds one to four symbols to the model's dependent variable list (two parameters for each surface and one for each curve) for a net loss of one or two degrees of freedom. This anomaly is of no consequence to the user except when a cam constraint is used within TimeSwitch or StageSwitch. In these cases the added symbols in the cam constraint must be dealt with in the other stages of the switch function, usually by using the Modeler3D Constraint function to set the added symbols equal to a constant.

Space curve constraints.

Spatial surface constraints.

Note that each symbol in a cam constraint must be accompanied by a numerical initial guess, guess.
The locus point that is passed to a Modeler3D cam constraint must be a valid Modeler3D point object containing the parametrically defined point. Also, the point must evaluate to a three-element list of differentiable expressions that are functionally dependent on the parameter alpha, at the time that the constraints are processed with SetConstraints. This is because the locus point is differentiated with respect to its controlling parameters by the SetConstraints function. Thus, if the locus point is not an explicit function of its parameters when passed to SetConstraints its derivative will be zero.
Note that all cam relationships are restricted to being in point contact. If two cam surfaces are defined such that they instantaneously have line contact instead of point contact, a singularity will result.
Some cam constraints are sensitive to which side of the cam surface the follower is on. The outside of a surface is defined as the side of the positive normal, which is the cross product of the direction of the surface gradient with respect to the first parameter and the direction of the surface gradient with respect to the second parameter.
CamPlot is a special graphics function provided to parametrically plot the cam profiles in global coordinates. Note that CamPlot returns a Mathematica graphics object, with the head Graphics, not a graphics primitive like most of the other Modeler3D graphics functions.

A cam-specific graphics function.

CamPlot produces the same output as would ParametricPlot, except that CamPlot transforms the cam profile into the global coordinate system. CamPlot does not evaluate directly to a Graphics object because numeric values for the coordinate transformation are not available. Instead, CamPlot returns a SysPlot object that evaluates to a Graphics object when numbers are available for the transformation.

This loads the Modeler3D package.

In[22]:=

CamPlot returns a SysPlot object.

In[23]:=

Out[23]=

When numbers are available for X2, Y2, and so on, the SysPlot object evaluates to a Graphics object.

Here we show the repositioned cam surface.

In[24]:=

Out[24]=

6.1.4 Example 3D Cam Mechanism

To demonstrate the use of Modeler3D cam functions, a 3D model of a rotating cam with a spherical follower is developed. The model consists of two moving bodies, the cam and the follower.

Here is the 3D cam-follower model.

Cam Profile

The cam profile used for this mechanism is defined in terms of trigonometric functions of the symbols alpha and beta. The cam profile expression may contain user-defined parameters that are defined at runtime, but all of the functional dependence on the controlling parameters, alpha and beta, must be present when the cam profile is processed with SetConstraints. Thus, it is not possible to leave the cam profile defined as simply a three element list of symbols, such as {xcam, ycam, zcam}, and then define xcam, ycam, and zcam as functions of alpha and beta at runtime.
The cam surface is the same as the one developed and plotted in Section 6.1.3.

Here are the parametric expressions defining the locus of the cam surface.

In[25]:=

Bodies

Three bodies are used for the cam-follower model.

Names are defined for each of the body numbers in the model.

In[26]:=

Here are all of the bodies in the cam model.

SetBodies is used here only to set a nonzero initial guess for the follower.

In[29]:=

Constraints

Three regular constraints and one cam constraint are required to model the cam-follower mechanism.

Note that while CamToSphere1 constrains one degree of freedom in the model, it actually adds three equations (one that forces the spherical follower to lie a specified distance away from the cam surface, and two more that force the cam surface to be tangent at the point of contact) and two unknowns, alpha and beta, to the model.

Here are the constraints for the cam-follower mechanism.

In[30]:=

Runtime

The cam-follower mechanism model can now be run in the usual manner. Note the presence of the cam parameters, alpha and beta, in the solution rule. At these values of alpha and beta the cam locus point is placed at the point of contact between the cam and the follower.

Now the model is run at T = 0.10.

In[31]:=

Out[31]=

Here is the cam-follower mechanism at T = 0.1.

The model is run again at T = 0.20.

In[32]:=

Out[32]=

Here is the cam-follower at T = 0.20.

6.1.5 Splined Cams

In designing an arbitrary cam mechanism it is necessary to be able to describe an arbitrary cam surface, one that is not constrained to be a series of piecewise continuous functions each coded in by the user, such as the examples in Sections 6.1.2 and 6.1.4. One way to define such an arbitrary curve or surface is with Mathematica's InterpolatingFunction objects built with the Interpolation function. Thus, the required sequence of piecewise continuous functions is assembled by Mathematica, while the user merely inputs discrete data.
While a cam surface so defined may work in a Mech model, it may also create some numerical problems. One basic requirement for a valid Mech cam profile is that it have zeroth- and first-order continuity. The Interpolation function uses cubic interpolation to fit the polynomials to the supplied data. This results in a curve that has zeroth-order, not first-order, continuity. Since the first-order discontinuities in an InterpolatingFunction cam are typically small, such a cam usually works fine until it happens to seek a solution point that has its point of contact on the cam directly on a cusp in the interpolating function.
To get around this difficulty Mech provides a function for creating cubic spline objects that have zeroth-, first-, and second-order continuity at each knot point. Mech's SplineFit function is similar to the SplineFit function that is included with the standard Mathematica packages, but it has been enhanced to allow 3D space curves, and the SplineFunction objects it returns are differentiable.

The function for creating splines.

Options for SplineFit.

Note that it is necessary to provide a list of data points with identical first and last points if a Closed spline is desired. The EndConditions -> Closed setting only ensures that the slope and curvature are continuous at the ends. The supplied data must provide zeroth-order continuity.
A closed cam profile in 2D space could be defined with a SplineFunction object.

This loads the Modeler2D package.

In[33]:=

Here is some data to be splined.

In[34]:=

Now we generate a SplineFunction object.

In[35]:=

Out[35]=

Here is a plot of the spline.

In[36]:=

Out[36]=

If it were desired to use this cam profile in a Modeler2D model with a circular cam follower, the following constraint syntax could be used. This constraint implies that the cam is on body 2, the circular follower is on the origin of body 3 and has a radius of 0.2, the constraint is constraint 4, and the initial guess for the cam parameter s is 2.0.

Here is a cam constraint that uses a splined cam.

In[37]:=

Out[37]=

6.1.6 Rolling Contact

In order to have rolling contact between two cams, the arc length along the cam profile must be known as a function of the cam's controlling parameter. For cams that are built up from a sequence of piecewise continuous analytic functions, such as those shown in Section 6.1.1, it is often possible to build up a similar function that exactly represents the arc length of the cam. If a SplineFunction cam was used, the arc length cannot be explicitly stated, but Mech provides a function for approximating the arc length with another cubic spline.

A spline utility.

Example Mechanism

The following example models a snail-shaped cam profile rolling on a stationary line. The cam is defined with a SplineFunction, and it is the single moving body in the mechanism. Note how the EndConditions option for SplineFit is used to specify the direction vector at the ends of the spline.

Here are data points for a snail profile.

In[38]:=

SplineFit is applied to the data.

In[39]:=

Out[39]=

Here is a plot of the spline.

In[40]:=

Out[40]=

To constrain the snail-wheel to be in rolling contact, the arc length function of both contacting surfaces must be known. Since one of the two surfaces in this model is flat and has a trivial arc length function, only the arc length function of the snail-wheel must be determined. The Mech ArcLength function may work quite slowly, because it involves numerically integrating each segment of the SplineFunction object.

Here is the arc length function of the snail spline.

In[41]:=

Out[41]=

Constraints

The snail-wheel is modeled with just three constraints.

Names are defined for each body.

In[42]:=

Here are the snail-wheel constraints.

In[44]:=

Reasonable initial guesses are set for the snail-wheel.

In[45]:=

Now we run the model at three positions.

In[46]:=

Out[46]=

Snail-wheel graphic at each solution point.

Analytic Snail-Wheel

In fact, this particular mechanism could have been modeled without the use of SplineFunction at all. The snail-wheel cam profile can be built from analytic functions and its arc length can be found using Mathematica's symbolic integration capability.

Here is the definition of an analytic snail-wheel.

In[47]:=

Out[47]=

Here is the exact arc length function of the snail-wheel.

In[48]:=

Out[48]=

Here is a plot of the exact arc length function and the approximate arc length function, normalized to the same parameter scale and offset.

In[49]:=

Out[49]=

6.1.7 Fourier Cams

Another method of modeling arbitrary cam profiles is by approximating the cam profile with a Fourier series of sine and cosine functions. This method guarantees a continuously differentiable cam profile and also may evaluate more quickly than a SplineFunction object, provided only a relatively small number of terms are retained. One disadvantage of a Fourier series based cam profile is that it does not pass exactly through the data points used to generate it.
The following example uses a series of points in Cartesian coordinates that are to lie on the surface of a closed cam profile. The profile has a protruding lobe for 1/4 of a turn and is approximately circular with a radius of 3.0 for the next 3/4 of a turn. The built-in Mathematica Fourier function is used to generate the Fourier series.

Here is the data to be transformed.

In[50]:=

Fourier is used to transform the data. Note that the zero-frequency term in each series must be divided by two to map correctly back into the time domain with Sin and Cos functions.

In[52]:=

Here are the first 10 terms of the approximate periodic function.

In[55]:=

Here is a plot of the Fourier profile along with the data points.

In[57]:=

Out[57]=

6.1.8 Cam Constraints within a Multistage Constraint

When a cam constraint is used within a TimeSwitch or StageSwitch function, the extra degrees of freedom that are introduced by the cam constraint must be dealt with when the cam constraint is not active. The following example shows how a TimeSwitch constraint might be used with a Modeler2D CamToPlane1 constraint.

Here is an example of a TimeSwitch with a cam constraint.

In[58]:=

When the value of time exceeds 2.5 the one mechanical degree of freedom that was constrained by CamToPlane1 is constrained by RelativeAngle1, while the values of the two cam surface parameters alpha and beta are constrained to be equal to two constants.
If this technique were not used, the values of alpha and beta would be unconstrained after T = 2.5 and the model would not run.

6.1.9 Involute Gears

A single pair of involute gear teeth can be modeled with Modeler2D as a pair of cam surfaces. Modeler2D provides a function for generating the involute profiles based on the standard gear tooth specifications.

The involute gear tooth function.

An option for Involute.

The following example uses two gear tooth loci (functions of the symbols g1 and g2) located on a pair of mating gears. Note that the coordinates of the center point and the rotation angle of the involute are given in local coordinates. The tooth loci are not placed onto their respective bodies until they are put into Modeler2D point objects.

Here is a pair of tooth loci.

In[59]:=

Out[60]=

Four constraints are used to model the two gear teeth.

Here are the involute gear model constraints.

In[61]:=

The model is run at T = 0.01.

In[65]:=

Out[65]=

Here are the two gear teeth.

Note that the angular velocity ratio of the two gears is equal to the ratio of the radii of the base circles.

In[66]:=

Out[66]=

Undocumented Graphics Generation

The following inputs generate the graphics in this section. These Modeler2D commands are defined in Chapter 3.

Cam-Follower Mechanism

Snail-Wheel

Gear Teeth

3D Cam-Follower Mechanism

6.2 Gear Constraints

Mech provides several special constraint functions for modeling gear-type relationships. These constraints do not, in fact, model the interactions of the individual gear teeth. They simply enforce the nominal rotational relationship that is expected of a pair of gears. An example of involute gear tooth modeling can be found in Section 6.1.

6.2.1 2D Gear Constraints

The 2D gear constraints provided by Modeler2D cover three elementary cases of a gear-drive relationship. In each case, a simple rotational relationship is enforced between two bodies.

Two gear constraints.

Special gear constraints.

Each gear constraint requires an initial position constant to set the initial relative rotational positions of the two gears. Physically, the constant C specifies which gear teeth are mating when the gears are first assembled, on a continuum.
The following TwoGears2 constraint would be used to model a pair of gears with pitch radii of 4.0 and 6.0, respectively, and local origins at {0, 0}. This method of setting the initial position constant causes the two gears to have angular coordinates of zero simultaneously, regardless of the relative positions of the centers of the gears.
Note that using Angle[gear1, 0, gear2, 0] in the orientation constant would produce invalid results if the centers of the gears were to move relative to each other, because the orientation constant is not constant.

Here is an example of a gear constraint.

In[1]:=

Out[4]=

When an Euler solution method is used in a 2D model (Method -> Euler option for SetSymbols), an extra symbol must be added to the model to keep track of the gross rotations of each gear. This is because the degenerate Euler parameters can only uniquely represent rotations from 0 to 2 pi. The extra symbol can be generated automatically by SetConstraints, or it can be specified with an optional argument to each gear constraint.
These extra symbols, and their initial guesses, are analogous to the extra symbols introduced by all cam constraints and the Modeler2D gear constraints.

Optional arguments for gear constraints with the Euler method.

See the appendix for the optional arguments to other gear constraints.

6.2.2 Example 2D Gear Mechanism

To demonstrate the use of Modeler2D gear constraints a 2D model is developed that uses a pair of gears, a pair of pulleys and a belt, and a rack and pinion. The input to the model is the specified rotation of the drive gear. This, in turn, rotates the driven gear, which is the same body as the drive pulley. The drive pulley rotates the driven pulley, which is the same body as the pinion. The rotation of the pinion causes the rack to translate.

Here is a 2D gear-drive mechanism graphic.

Bodies

Five bodies are used in the gear-drive model. No body objects are defined because no explicit point coordinates are used in the model.

Names are defined for each of the body numbers in the model.

In[5]:=

Constraints

Eight constraints are required to model the gear-drive mechanism.

Here are the constraints for the gear model.

In[10]:=

Runtime

Initial guesses for the drive pulley, rack, and pinion must be set or the model will not converge. Almost any guesses greater than zero will do.

This sets the initial guesses for the next solution attempt only.

In[11]:=

Out[11]=

Because of the presence of time T in the driving constraint, the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angular coordinate of the drive gear.

Now run the model at T = 0.05.

In[12]:=

Out[12]=

Now run the model at T = 0.25.

In[13]:=

Out[13]=

Here is the gear-drive mechanism at T = 0.25.

6.2.3 3D Gear Constraints

The 3D gear constraints provided by Modeler3D cover six elementary cases of a gear-drive relationship. In each case the gear constraints simply enforce a nominal rotational relationship between two bodies. The interactions of individual teeth on the gears are not modeled.
Each of the gear constraints must be passed an additional symbol alpha that is used by Modeler3D to keep track of the relative rotations of the gears. These symbols can be arbitrarily chosen, as long as all symbols in all gear constraints in a single model are unique. The values of these symbols are calculated by Modeler3D at runtime and included in the solution rules. Essentially, each new symbol is another dependent variable to be solved for, just like the coordinates of each body.
The numerical values of the added symbols correspond to the rotation of the first of the two gears in each pair, relative to the mutual orientation of the pair of gears in space.

Two gear constraints.

Each gear constraint requires an initial orientation constant to set the initial relative rotations of the two gears. In most simple gear trains the gears are initially aligned so the orientation constant can be zero.
The only significant differences between ParallelGears5 and TwoPulleys5 are that the separation distance of the two gears can be set independently from the gear radii with TwoPulleys5 and that the direction of relative rotation of the two gears is reversed. The direction of rotation constrained by TwoPulleys5 can be reversed by negating one of the two pulley radii.

A special gear constraint.

Another special gear constraint.

As with TwoPulleys5, the direction of relative rotation specified by OrthogonalGears5 can be reversed by negating teeth1 or teeth2.

A screw constraint.

A constant velocity joint.

Note that the ConstantVelocity4 constraint is not stable when the two axes are parallel. The included angle between the two axes must be kept sufficiently far from 0 or to remain stable. If the two axes in a model need to be parallel or nearly so it may be useful to use the OrthoRevolute4 constraint instead.

The following ParallelGears5 constraint models a pair of gears with pitch radii of 4.0 and 6.0 respectively, and axis origins at local {0, 0, 0} on each body. The rotational axis of each gear is in its local z direction, and the local x direction on each gear is used as its reference direction. Setting the initial position constant to zero causes the reference directions of the two gears, the local x axes, and the vector from the center of gear1 to the center of gear2 to be simultaneously parallel.

This loads the Modeler3D package.

In[14]:=

Here is a gear constraint example.

In[15]:=

Out[17]=

6.2.4 Example 3D Gear Mechanism

To demonstrate the use of Modeler3D gear constraints a 3D model is developed that uses a pair of orthogonal bevel gears, a pair of parallel spur gears, and a rack and pinion gear set. The input to the model is the specified rotation of the first bevel gear, the drive bevel. This, in turn, rotates the driven bevel gear, which is the same body as the drive spur gear. The drive spur rotates the driven spur, which is the same body as the pinion. The rotation of the pinion causes the rack to translate.

Here is the 3D gear-drive mechanism.

Bodies

Five bodies are used in the gear-drive model. No body objects are defined because no explicit point coordinates are used in the model.

Names are defined for each of the body numbers in the model.

In[18]:=

Constraints

Eight constraints are required to model the gear-drive mechanism.

Here is the complete constraint set for the gear-drive model.

In[24]:=

Runtime

Initial guesses for the rack and pinion must be set or the model will not converge.

This sets the necessary initial guesses.

In[25]:=

Because of the presence of T in the driving constraint, the model can be run through its intended range of motion by varying T directly with the SolveMech command. The numerical value of T specifies the angular coordinate of the drive bevel.

Now run the model at T = 0.05.

In[26]:=

Out[26]=

Now run the model at T = 0.25.

In[27]:=

Out[27]=

Here is the gear-drive mechanism at T = 0.25.

From the sizes of the gears in this model and the fact that the drive bevel is turning at one revolution per second, we can calculate what the velocity of the rack should be. This can also be found directly from the velocity of the rack in the Modeler3D model.

Here is the rack velocity, calculated explicitly and from the model.

In[28]:=

Out[28]=

Out[29]=

6.2.5 General Rotational Relationships

If the spatial gear constraints provided by Modeler3D will not serve to model a more abstract rotational relationship, similar constraints can be built up from the basic kinematic constraints. The following example shows how to duplicate the function of the ParallelGears5 constraint with a set of other Modeler3D constraints.
This model consists of one moving body, the gear, and one stationary body, the pinion. The radius 3.0 gear orbits the stationary radius 1.0 pinion. The ParallelGears5 constraint is effectively replaced by the set of the following six constraints.

This combination constrains seven degrees of freedom, but it adds two degrees of freedom by adding two variables to the model. Thus, a total of five degrees of freedom are constrained.

Here are names for the body numbers.

In[30]:=

Here is the equivalent ParallelGears5 constraint.

In[32]:=

We define a driving constraint to move the gear vertically so as to orbit the pinion.

In[33]:=

SetConstraints must be passed a flat constraint list.

In[34]:=

One initial guess is needed.

In[35]:=

Now run the model at T = 1.0.

In[36]:=

Out[36]=

Here is the two-gear model at T = 1.0.

In general, this method of constraining the relative rotation between two moving bodies can be used to model any type of rotational linkage. The Constraint function that is used to relate the two extra variables can contain an algebraic expression that is arbitrarily complex. This allows abstract or nonlinear relationships to be modeled.

Undocumented Graphics Generation

The following inputs generate the graphics in this section. These Modeler2D and Modeler3D commands are defined in Chapter 3.

2D Gear Drive Mechanism

3D Gear Drive Mechanism

General Gear