Linkage error when reversing Bevel Gear

[BillM]

Hi Art

I ran into a strange error while building a new simulation....this one is of the E Howard Tower Clock.  The attached zipped gth files show what I found:

BevelGearLinkage.gth  I setup a wheel and attached a bevel gear, started the simulation and things worked OK.

BevelGearReverseLinkageError.gth  I simply reversed the bevel gear in the above example and ran the simulation again.  This time the gear and the bevel rotated in opposite directions...not quite what I expected.

I checked the links and they appear identical.  The only way I could find to correct it was to unlink the bevel from the shaft and then link the bevel to the gear. 

Bill

[ArtF]

Hi Bill:

  Thx, this is a bug. Changes to gearotic over the past year or so seem to have broken the
relationship linkage on bevels, Ive tagged it to find a solution.. those same changes made that a bit complex. :)
Good news is, you did the proper thing, perfect solution, once the normal was reversed, tying it to the gear allowed
it to see it was a 1:1 relationship.

Thx for the notification,
Art

[BillM]

Hi Art

I discovered the hard way that the linkage reversal is only part of the problem.

Similar to the example I already posted earlier.  If I place the bevel gear-1 at a distance from the spur gear, reverse it, and correct the linkage all is OK..  That's now my standard op for the rest of the bevel pairs that I'm adding to the clock simulation.

If you then add a bevel pinion to  bevel gear-1, again all is OK.  That is until I decided to move bevel gear-1 closer to the spur gear.  When I complete the move the bevel gear-1 is again reversed and the bevel pinion flips around also.  I again manually reverse gear-1 and, interestingly enough, the linkage is still correct..but the bevel pinion is out of position.  "Moving on gear" the bevel pinion on gear#1 then corrects the position.

On a simpler model the correction for the odd flipping is doable.  In my case with a more bevel gear pairs following the one I moved, it was easier to delete a bunch of bevel gears and redo them.

I now know to make sure,if I have a bevel that needs reversing, that I make sure the bevel gear position where I want it before correcting the linkage and adding any more gears beyond it.

Still having fun with the program.

Bill

[ArtF]

Bill:

Thx for the info, Ill dig into the code to see if I can reset the variables so it stays in position.. Ill see what I can do about making it work
on the shaft linkage as well..

Art

[BillM]

Hi Art

I discovered another anomaly related to the bevel gear linkage reversal issue as I completed a Tower Clock Simulation.  I expected the minute shaft at the top of the tower to have a rotation rate of 1:00:00.0  but it  had a completely unexpected lower value.

I isolated the problem to a 50T to 60T bevel gear combination that included needing to do a bevel gear reversal.  I came up with a simpler example in the attached zipped gth file.

I created a spur gear & set the master rotation rate to 3600seconds.  Shaft rotation properly showed 1:00:00.0.  I then added a 50T bevel gear in a position where I was forced to reverse it and correct the linkage.  To that bevel I added a 60T bevel gear which created Shaft-1.  I expected Shaft-1 to rotate at 1:12:00.0  but instead it showed 1:00:00.0.

The behavior did not occur when I did not position the 50T bevel to force the reverse/relink.  The Shaft-1 rotation rate was correct.  Out of curiosity, I removed the Shaft -50T bevel link and then linked Spur to 50T Bevel.  This actually caused the Spur and 50T bevel to rotate reversed from each other and the Shaft-1 showed the incorrect value of 1:00:00.0

How this is all related is certainly puzzling.

Bill

[ArtF]

Bill:

>>How this is all related is certainly puzzling

  Lol, your not likely to figure out its logic by such stats.. damn thing got complex over time, I think its just one
section doesnt understand a bevel with a reversed normal rotates in reverse to that normal.. :)

Art

[BillM]

Hi Art

I started thinking more about the "reversal" and linkages.

When I used to work for the government one of my projects  involved developing an emulator to serve as a test driver for a system we were developing.  My team came up with an object-oriented system that by it's nature involved multiple coordinate systems.  One was a global system linked to Lat/Lon.  Each object created would move in this global system but have it's own relative coordinate system especially handy when maneuvering in space.

Interesting errors initially crept in regarding right hand vs left hand coordinate systems.  Rotation of an object was calculated in its relative coordinate system.  Such rotation was "gimbal" order specific (e.g. roll, pitch, yaw vs pitch, roll, yaw).  Mismatch the "handedness" of the coordinate system would result in incorrect rotations.  The same was true if the order of the rotations didn't match the inputs from the "real" systems.

I imagine that Gearotic2's implementation also has similar absolute and relative coordinate systems. When a gear is reversed, there appears to be a conflict in rotation angles.

I've been playing a lot with linkages in my simulated clocks.  My goal is enable the replacement of a gear in the middle of a complicated design without having to rebuild the entire simulation.

Correct me if I'm wrong:
I think I've seen your answer either in one of your videos or blog responses that the normal sequence of things is that the First gear on a shaft drives the shaft & any other gears added to the shaft are driven by that shaft.

Adding a gear to a gear creates:

*  a new shaft for the added gear
*  a link from the added gear to the new shaft
*  a link from the first gear to the added gear.

Implicit when the a gear is added to another gear is is that the second gear (linked to the first) always runs reverse from the first.  All items driven by the same shaft have to rotate in the same direction.

The bevel gear is the only one that is reversible...and when reversed on a given shaft it runs backwards from the driving gear...either the shaft object or the reversed bevel gear object is misinterpreting rotation commands.  My guess is that the bevel gear object is the only one that knows it has been reversed...if the rotation command comes from a shaft then it should reverse the rotate command from the shaft.  I don't know if it's possible for a bevel gear object to know whether the rotation command comes from a shaft or a gear.

Bill

[ArtF]

Bill:

  Yes, thats esentially what Gearotic is, a collection of objects, each has its own coordinate system and placement. However,
to eliminate gimble lock , I use quaternions as the rotation system. This can run into trouble in the case of the bevel as a
quaternion reversal looks much like no change in angle. Its just a logic issue that is unique so the system misses it.
Ill see what I can do though to make a special case test on a bevel for a normal thats reversed to the shaft normal..

Thx
Art

[BillM]

Hi Art

Thanks for the info.  Attached are jpgs of the Tower Clock simulation that I'm working on when I stumbled across the additional anomaly with the reversed bevel gear.

I'll work on a video of the running model in the next few days.  I'm impressed how rapidly the .gth file grows as the bevel gear sets get added to the model.  The .gth file is now >93MByte...not something that will ever get uploaded anywhere.  I may put it up on my google drive.

I am impressed that even with the size/complexity of the model that the simulation runs well on my notebook computer.

Bill

[ArtF]

Thats quite a piece of work that. Yes, they do get large. Each object holds quite a bit of data, all one object type really ,
with variables telling each object what to look like and how to rotate.. Nice to hear it still runs smooth even at that size, I
havent made anything that complex in quite a while...

  The tower head is quite impressive...

Thx for the look,
Art

[BobL]

Nice work Bill, always wondered how they did that 4 side clock face, thanks for sharing.


Cheers
Bob

[BillM]

Hi Bob

The attached photos show the inside of the clock tower.  The 4-way bevel gear split is kind of unusual..the top gear is 60T and the  mating gears are 50T.  This reverses the 50T-60T gearing in the clock room.  Our guess is that the first 50T-60T reduction may have been used to bump up the torque a bit prior to the chain of bevel gears to the tower.  When the clock was last running in early 2010 the wear and buildup of friction had reduced operations to a single dial.  Input /Output of each bevel set is driven via universal joints.

The current installation is different from where the clock came from.  The clock mechanism was probably mounted directly below the 4-way split which would have greatly reduced frictional losses in the drive train.

The second two jpgs show one of the motion works.  The input to the motion works is the minute shaft.  At the time we examined one of the motion works I did not have time to document the gear thicknesses, # of teeth, or gear diameters.  What I modeled in Gearotics was my best estimate of the gear ratios and sizes.

My goal of the simulations is to document the mechanical details of the entire clock.

Bill

[ArtF]

Bill:

As of next version the bevel reversal will no longer need to be relinked to rotate properly.
:)

Thx
Art

[BillM]

Hi Art

It will be interesting to see if the  fix to the bevel gear reversal also corrects the other anomaly in the rotation rate calculations.

I suspect that I may have to undo the links in my tower clock sim.  But at least I've been practicing with linkages.

Bill