Gears in mechanism mode

[dcanelhas]

Hey there fellow IronCAD users. Does anyone know which set of constraints to use to allow mechanism mode to solve for a pair of meshed gears? (bevel and spur)

 

I searched the documentation, tutorials, the internet, these forums and I'm finding nothing of use. Please shine a light of guidance my way.

 

The gears i'm using are the standard catalog gears under tools

[Cary OConnor]

Unfortunately this is not possible if you want the gears to have collision and rotate based on that collision (physical simulation). Currently we do not have this capability. If it is just for an animation, then you would just apply the proper rotation speed.

 

Cary

 

[dcanelhas]

I see. Is there some way to set the angle of one gear constrained to the angle of the other multiplied by the ratio, multiplied by -1 (to invert the rotation)?

[Guest EricFoy]

I'd like to take this opportunity to enter an ER:

 

Gear constraint. This would apply to any two elements rotating about their respective centers of rotation, constrained to a rotational ratio entered by the User. Negative ratio for gears, positive ratio for belts. It wouldn't actually use the gear tooth collisions to compute the motion, but it might be able to detect collisions between "mis-constrained" gears.

[Cary OConnor]

Question - Is this for accuracy or for animations? Would the graphical facet resolution accuracy be acceptable?

 

Cary

[dcanelhas]

If i just set the rotational speeds in an animation i can't evaluate the backlash that occurs when a mechanism is started, or when its direction is inverted. This would only be possible using a physical simulation, since a gear constraint would most likely assume perfectly meshed gears with no gaps.

 

//How accurate is the existing collision detection?

If a gear could be made to test a very small movement "step" in each direction from its collided condition (disregarding those directions in which it is constrained) and adopt the position in which it was released from the colliding surface it would be satisfactory for me.

 

Allowing for gears to be simulated in mechanism mode would remove one source of "false" collisions in the gear to gear interfaces, letting the designer check for other interferences. Not to mention that it would let the user specify a LOT less of those pesky smartmotions if you animate with mechanism mode on.

 

Speaking of which, is there any way to edit a smart motion once it has been created? I only seem to be able to change its duration, but not the angle of rotation, for example.

 

 

Edited April 29, 2010 by dcanelhas

[Guest mhan]

I see most of the following linked sites is likely to be a lot of help.

Also, I think I'll be bound, without IronCAD mechanism for the assembly and operation mode in the motion, while it is possible, for a lot of designers will be able to reduce errors and time.

 

http://www.plm.automation.siemens.com/en_u...aem/index.shtml

 

 

ironcad = innovation = no Assembly constraint

 

- soobin5 -

[Cary OConnor]

Yes the AEM is for the real physical mechanism. However it is an added expense to the software. The other approach is a graphical method which can be achieved with no expense. The main question again is how accurate do you want it.

 

Cary

[Guest EricFoy]

Question - Is this for accuracy or for animations? Would the graphical facet resolution accuracy be acceptable?

 

Cary

28528[/snapback]

My application is general machine/mechanism design. I would consider backlash analysis to be a separate endeavor, just like tolerance stackup. I would use the gear constraint in mechanism mode as a means of keeping things synchronized, like contra-rotating shafts having arms that drive opposing lever actions.

[dhovatter]

I agree with Eric. It would be nice if it simply would rotate in sink.

My applications are round Dies rolling on and anvil roll and it would be great for me to be able to see them roll together.

Dallas

 

[Cary OConnor]

I'm still a little unclear if you need the high accuracy of the solid or not for your cases. The graphical accuracy could achieve physical movement but would not provide highly accurate detection. If we understand the needs, then we can better plan for a path to support it. We could add the graphical first for animation purposes and then look to see if the need for accuracy arises. Or we could go strait to the accuracy one (not sure what all the limiations would be like performacne and such).

 

Let me know,

Cary

[swallis]

I'm still a little unclear if you need the high accuracy of the solid or not for your cases. The graphical accuracy could achieve physical movement but would not provide highly accurate detection. If we understand the needs, then we can better plan for a path to support it. We could add the graphical first for animation purposes and then look to see if the need for accuracy arises. Or we could go strait to the accuracy one (not sure what all the limiations would be like performacne and such).

 

Let me know,

Cary

28566[/snapback]

I would absolutely vote for doing the graphical version as soon as possible. To me it would make the current animation capabilities much more more useful. As it is, I often don't bother with an animation in a situation where I would love to have one, just due to the lack of the rotational constraint. And just to be clear, it would need to work by manual dragging in mechanism mode, not just in a processed animation.

 

Scott