Proposal for a first (simple) motion/animation designer in Assemblies

olaf_huber644

Since some weeks I am evaluating Onshape and currently I explore the borders of the animating an assembly with mechanism(s).
Currently I found these restrictions

1. It is only possible to animate one mate at a time
2. It is only possible to animate a mate "linear" from the minimum value to the maximum value

I guess this is sufficient for a great bunch of usecases.
But when it comes to (more complex) assemblies with (multiple) mechanisms and "diagram driven" motions the workarounds become quite sophisticated (see the famous Rubik's Cube animation...)

In our business the engineer's demands are simple and the same for the last few decades when it comes to animate machines/concecpts:

1. The production machine runs in a cylic manner
2. The whole machine consists of a certain number of "moving mechanism" or "axis" (contraint sub-assemblies)
3. each "axis" assembly often boils down to simple gear, chrank, rack'n'pinion or screw/Belt driven motions. I.e. one input motion relates in one output motion
4. For each axis the engineers has a "motion diagram" at hand how the axis moves during a cycle.
5. All axis motion diagrams run "synchronized" to one mecanical "master cam" ("Königswelle" in German) or its electronical counterpart in the sense of a "servo controller/drive"

On my way home I put these demands together with Onshapes easy to use capablities of

1. Adding relations to mates
2. Tools for handling tables (as used e.g. the parts configuration)

Then I had an epiphany I found worth sharing:

• Introduce a new mate relation type called "Motion Diagram"
• For each "slave" axis there is a table defining the motion
• There is one "master driver" animation axis or "item" that synchronizes all (slave) axis when animating

How should it work in detail?

Generally a motion diagram consists of these elements:

1. a horizontal axis or first coordinate (abszissa) with
   time (max. x seconds for a "non cyclic", "one-time" motion) or
   angle (max. 360° for a cyclic "camshaft" motion)
   as the "master unit"
2. a vertical axis or second coordinate (ordinate) for each (slave) axis with either
   linear units (in mm or inch for linear movement) or
   angular units (in degree for rotational movement)
3. a motion path (for each axis)
   This path is divided in "sections" (I-IX)
4. In these sections are defined either
   Positions (where the axis "rests" e.g. for the blue axis 1 these are section I, III, V, VII, IX) or
   Transitions (where the axis "moves" from on position to the next e.g.for the blue axis 1 these are section II, IV, VI, VIII)
   The width of the sections is measured/defined in "master units"

For the usage I could imagine these User-Stories/Workflows/best practices (I do not know the proper term used in agile SW-development...):

1. Definition/Constraining assemblies:
   For each "slave axis" the user needs to have a separate sub-assembly (which is normally for free, assuming a proper design workflow...)
   Each sub-assembly should be constraint down in such a way that either one revolute or one slider mate drives the whole mechanism when animated
2. Definition of Motion Diagrams:
   Either in each sub-assembly or in the top-assembly the motion for each axis can be defined by a table (one for each axis, similar like the configuration tables)
   There the user can sectionwise enter the desired path
   for each section (column 1) he can select which
   type (position or transition) the section is (column2).
   Depending on this he can either enter (column3) the position value or select the appropriate motion law for the transition (from a dropdown with the options shown on the right)
   Finally the user can define the duration of each section (column4) (in fractions of a "normalized" unit), so it is independent of length or angle of the master unit
   
   
3. Relating motion diagrams to "slave mates"
   Once all motions are defined, the user relates each diagram to the appropriate mate with the suggested new mate relation type (probably best on top-assembly level).
   In this mate relation type the user can also define the master unit (time (x seconds for one-time motion) or angle (360° for cyclic motion),
4. Animate
   Finally the user could make use of the animate mate dialog, instead of selecting a mate he selects the "motion diagram relation"

Hopefully this was not too long and too eloquent written so that you get the idea.
Of course I am already thinking of a graphical UI for entering the motion diagram, etc.
But I guess for a prove of concept the above would be sufficient for starting.
I am looking forward to your feedback.

Best regards
Olaf

MBartlett21

Your diagram of paths looks exactly like @john_mcclary did with his rubik's cube

olaf_huber644

@MBartlett21_CSM:
I guess the simple reason is:
this is the way motion diagrams look since decades
And are thus the basic fundament for planning/designing motion in production machinary ranging from huge automotive presses to tea bag packaging machines...
If you are interested in the background, refer to VDI 2143 "motion rules for cam mechanisms" (if it is available in english).
It deals with all theoretical and terminological stuff related to this topic.
Might be interesting for the developers as well, if the idea gets voted high enough and it comes to implementation...