Linking Gears to Shafts or Other Gears and Multiple Constraint Placement

[Micheal Cranford]

One of the shortcomings of Gearotic Motion is the inability of the user to link the motions of gears to shafts or other gears
as well as position gears for a proper mesh under particular circumstances. While that may sound contradictory relative to
what GM is capable of, I will provide a picture below to clearly illustrate all of the problems that I have encountered. Some
explanation about the gearing arrangement is also required.

http://www.use.com/supersize.pl?set=b4a ... ff5b76c2bf

Two small involute gear pinions drive a pair of larger involute wheel gears.  Each pinion/wheel pair is independently controlled
with its own motor. The right hand involute wheel gear is connected to the large bevel gear located to its immediate left.  The
left hand involute wheel gear should be connected to the small red bevel gear to its immediate right, and sharing the same
shaft as the larger bevel gear. Note that only one of these two bevel/involute gear sets could actually be solidly connected to
the shaft, so one of them has to be an idler (the leftmost pair of gears in this case).  The 2 driven bevel gears on the near end
of the long shaft are actually on a pair of concentric shafts, with the larger bevel being on the outer shaft and the smaller bevel
being on the inner shaft.  The far end of the long pair of concentric shafts has a mirror image of the bevel gear pair on the near
end.

1. GM is currently limited to only a single input drive gear.  It would be desirable to be able to select which gear is
the drive gear since, as can be seen in this example, there are 2 drive gears.  In any robotic motion gear train there
are often may different drive gears.  For simplicity, being able to only define 1 at a time as the drive gear would still
be a major benefit. For extra credit, being able to have multiple active drive gears would be great but that?s not an
absolute necessity since each drive gear would needs its own rotational direction and speed controls and this adds
a lot of complexity to the programming.

2. Since GM automatically assumes that any gear is rigidly attached to the shaft that it is located on, idler gears
sharing a common shaft do not currently seem possible. As a result, GM is confused about the small red bevel gear
and the large involute wheel gear to its left, and they end up rotating in opposite directions when they should be
rotating together. Also note that they are not currently touching each other, I do not know how to have GM define
a gear hub that is deeper than the remainder of the gear.

3. The two bevel gears located at the near end of the long shaft pair should rotate independently while GM actually
rotates them together. In fact it seems likely that GM considers my two concentric shafts to be a single shaft since
the smaller bevel bore appears to be the larger shaft diameter even though I specified otherwise.

4. It is currently not possible to automatically place the two smaller bevel gears located near the near end of the long
shafts (the small red bevel gear and the small bevel gear that it drives) in proper mesh. The reason for this is that the
red master bevel gear must be placed on an existing shaft and the slave bevel gear must either be placed on an existing
shaft or else it must be placed meshing with the red bevel gear since GM will not currently handle both of the constraints.
One way to alleviate this would be to allow the user the freedom to move any gear along the shaft that it is located on
after placement so that correct meshing could be achieved. Alternatively, being able to specify that a pair of gear should
mesh during or after placement would also work. Currently GM uses either a shaft OR a meshing gear for the placement
rather than allowing for both at the same time.

So, what I am suggesting above is to add the capability to define which gears are coupled to which shafts, and which gears
that are not in mesh but share a common shaft are also coupled together.  Likewise concentric non-coupled shafts should
be possible as well as being able to define which gear(s) is/are the drive gear(s). And placing gears with multiple constraints
or else being able to specify movement for correct meshing after placement would handle the small bevel gear situation that
I describe above. Doing these would allow GM to actually be useful for many robotic motion gear train designs. An additional
extension would be adding in lead screws to allow for the conversion of rotary to linear motion, but that is really a separate
topic.

[BobL]

Micheal;

Thanks for ytour feedback.. That's why a re-write is in progress for a hopeful fall release. When all fundamental items are in place that we all got use to from Gearotic Motion, the new engine should allow users more control of gear trains as you mentioned and other gizmo's too if all of it works out. Art has done an awesome job so far with what we got, seems like possibilities are endless with the new platform as it expands and develops, however all of it takes time.

Thanks
Bob
;)    

[ArtF]

HI Michael:


  As Bob says, this is one of the many reasonds for the rewrite. Simple mechanisms work well enough, but for things such
as you describe you really need more of a physics engine for all the various linkage posabilities there are. It can get very complex
to do all that, but I do intend to implement as much as I can of that. In future each gear will have a setting for if it is pinned
to a shaft or not. Also a gear is intended to be locked or unlocked in terms of reference. ( Does a mating gear turn a gear, or is it forced to circle that gear ).

  Itll take awhile to get there, but it is headed in that direction.

Art

[Douglas Jones]

Great, can't wait. :) awesome. time flies, fall will be here before you know it.

[ArtF]

Doug:

  So long as my head can handle it .... Its amazing how complex things get when you start to get into the physics
engines of thses things. I can promise lots of logic bugs for you to find. :)

Art

[Douglas Jones]

Love bugs, lol, NOT. Interface, well. I'd like to see it slightly different, somehow..  gears displayed on screen, parameters are adjustable, good. Screen/mode change to add or edit, not so good. Thinking....

[ArtF]

Interfaces are always rough. What one person loves, another hates.Im trying to ensure this new one is as intuiitive as I can make it, with mutiple ways to navigate around as well. I sometimes think the interface is the worst part of any program to write..

Art