Cam motion at start of analysis that is in a dwell region / MDO

[EPeters_PE]

I have a CAM problem I have been working on.. one big issue... my cam has motion at the start of the analysis, when it should just be gliding along my lower dwell? 

Here is what I have been doing: 

I start my dynamic run at the center of my lower dwell / Create a snapshot called Start

Make sure I have my springs in the system pre-loaded as I would like. 

(Using spring to input rates I have found by running FEA on the parts, this is a heavily loaded Cam with a low displacement, .010" is the total cam rise and that is reduced through a lever arm.)

Set an Initial Condition, with my cam rotation at full speed, and my snapshot <Start> used.

Run a "Zero Time" dynamic to check that my loads are for the most part balanced.

Run a dynamic analysis for my cycle time, that is 

Lower Dwell (2nd half) | Rise | Upper Dwell | Fall | Lower Dwell (first half)  all at 500 Hz, or just .002 seconds.

My Cam roller seem to have motion, like it needs to "find it's contact" at the start of the run.  I've tried everything I can think of, what gives?

Why is flying around at the start of the run, the loads should all be just pushing the CAM and Follower together, and then staying in contact and motion less until it start to go up the ramp at .0002 second time shot.

Attached:

Cam Area.JPG, this shows the area of the concern, the cam on the right

Full Cycle.JPG, the motion of the center of the pin radially to the CL of the Cam through a whole cycle, notice at start the short time of bouncing around that is going on.

Short Time at Start.JPG from a run done on just the start of the motion... from 0 to .0002 seconds.

Is there something I'm missing?  

[gfraulini]

Could you share the assembly with us?

[EPeters_PE]

Sorry can't not publicly... 

I may be able to build something similar.

[ChrisKaswer]

I can suggest a few things to look at - not sure if you've done these, but if not, add them to your check list for cam-follower dynamic analyses.

• Have all your bodies been assigned proper, accurate mass properties?
• Are you using a "non lift-off" cam definition? (if not, try this)
• Are your steps (time increments) set small enough?
• Is your cam defined against rotation increments that are equal or smaller than your integration time steps? If not, this may cause issues with the follower's motion. I would regularly define my cams with 0.1 degree increments when looking for results every degree (or even 0.5 degree).
• Try running a kinematic analysis first to make sure your motion is good before trying a dynamic study.

I hope these help.

[EPeters_PE]

All masses are assigned

I am looking for lift off, I can "glue it" and look for tensile forces that would be the same as seeing lift off.

Besides the run set up how can I control time increments.

Analysis Definition:

• Duration .002 seconds
• Frame Count 50
• Frame Rate 24500 (49/.002)
• Minimum interval 4.081632653061225e-05 (as output by MDO for 50 frames over the run, is there a good rule of thumb on number of frames and min interval?)
• Cam design is a modified trapezoidal shape was defined with equation driven curves.
• Kinematic will not work as there is a spring used to transfer motion from the follower to the rocker arm to model rocker arm deflection under load.

This setup takes about 20 minutes to solve w/o graphics on... any tricks to faster run times?

[ChrisKaswer]

Your setup is the only way to control desired time increments, and the solver will bisect when/if necessary. Of course kinematic studies will not give you loading, BUT, they will provide a way to make sure your cam pair is operating properly with the given surfaces/curves you've assigned. You may discover issues with the assigned geometry by inspecting the results of a kinematic analysis. Always run a kinematic study first to make sure everything provides the expected output. You may see undulations in your kinematic follower lift for your cam pair, and if so, this can lead to potential dynamic issues - especially if your spring and/or masses are large. Given your equation to define cam shape, how did you use this to construct the actual geometry? Also try setting an initial velocity of your follower's joint axis to zero along with your defined cam rotation speed.

Edit - just noticed the solve time...very large for this type of system. There may be something funny about masses and/or springs with the given driving input. Seems like there is too much high frequency response "noise" getting into the result.

[EPeters_PE]

Ran Kinematic..

first at a lower frame rate 50 frames, it did a "jump"

upped the frame rate to 500 and no issue, also can drag with/out seeing anything in the motion that is a problem.

YES there are a lot of very stiff springs coupled to masses you are not seeing, this model has ~30 DOF, you are only seeing the input device to a much larger problem.  Looking to induce controlled vibrations into a system. this is running FAST at low displacement against a stiff system.

My biggest issue is still at the start of this... look at the graph attached, notice that my cam position goes down / under the surface.  This imparts kinetic energy early in the run, which is being put on the main force vs time reactions in the springs like a carrier wave over the natural frequency, that I am attempting to stay out of harmonics on.

[ChrisKaswer]

Is the plot you shared the position of the cam follower? What does this same measure look like for the kinematic result? The plot suggests high velocities and accels - how did you generate the cam surface? Did you synthesize the shape from your equation? You may need to dig deeper into the creation of the cam surface and define it more finely than it is now. Without knowing more details, it's tough to comment further. I've created and run very complicated dynamic cam-follower systems with 2-3 dozen DOF that would run pretty quickly (10-20 years ago in Pro/E). The input cam shape needs to have enough detail defined at small increments to feed high DOF systems. You may need to dampen some of your joints as well, where it makes sense.

[EPeters_PE]

Created the equations for the cam profile and broke into each segment of the total rise / or drop, cycle of BETA.

Below is the first piece relationship for the curve for a sinusoidal start of the rise using polar coordinates.

z=0

/* theta as a function of t = 0 to 1, => convert P_0# to degrees and multiply by fraction of travel for each phase
/* (-1) added to design a CCW cam, rise needs to go in the negative / CW direction
theta=(-1)*t*P_01*180/pi*RF_01
/*
r=D_BASE/2+RISE*(.38898448*t*RF_01-.03095444*sin(4*pi*t*RF_01*180/pi))

[EPeters_PE]

Kinematic is smooth, works as expected... 

[SweetPeasHub]

Have you tried decreasing your relative tolerance and/or characteristic length? 1e-6 is what i would try first. This is in the model properties.Mechanism Tolerance

[EPeters_PE]

Had it WAY cranked down, .01 to keep solve speed up... 

What is this factor in MDO doing mathematically in the solution?

[EPeters_PE]

HA... I think you just solved it... 

I was too high on this, just changed to .0001 and now the issue is gone... 

Think I was being over zealous on this setting... 

[EPeters_PE]

Check out the BEFORE AFTER graphs from excel... 

Much better... thanks all.

Still have a big problem as I am bouncing, but, that may be solvable with some major stiffing up of the support structure in this system, to increase the natural frequency of the system whole.

[SweetPeasHub]

I see you solved this but I was in the process of writing some more on this and will still share it....

I am not certain what the math is but the relative tolerance affects how loose any joint can be.  Too tight and the assembly cannot connect, too loose and it allows too much freedom at connections.  Having it loose could allow a seemingly overconstrained system to connect because it moves joints slightly off of their perfect conditions.  For my types and sizes of assemblies I have rarely received good results with 0.01 tolerance.  The way I prove whether any larger tolerance and faster run time is sufficient is to compare results to tighter tolerances. (by a couple orders of magnitude)  Usually when I have friction in the mix I cannot get away with much larger than 1E-5.  If you are having way too large of run times I think it was already mentioned about adding damping.  damping is tricky to set in the right range and verify that it is not affecting results too much, just smoothing high frequency content.  A very stiff system like you are modelling could have some very high frequency content as a result.  Consequently the time step will go down dramatically to capture the high frequencies and thus long run times.  I am thinking that the allowed cam connection depth is affected by this tolerance.  That is the parts can be clear or intersecting within a certain tolerance and still be considered connected.

I am not sure how exactly the Cam interface does its contact math but it is common that small stiff springs are used along with a small amount of interference to generate the response force.  As the analysis progresses, if the interference is detected the springs are automatically adjusted to higher stiffness to cause a higher force.  The troubles come when tight tolerance for the connection and hard conditions as well on the other end for too soft conditions (For example in FEA the keyword SOFT can help this).  So I expect CAM joints would have some interpenetration going on during the simulation and I believe I recall seeing that snapshots will not exactly match the static start conditions.

I have a final suggestion in addition to tightening your relative tolerance, that is to run a static case just prior to running the dynamic.  This would "settle" in the cam contact in a better way than drag.  For the dynamic initial condition then use "current_screen" as the snapshot so it captures the exact position things are at the end of the static study.  I am not totally sure about this for your model but it might be worth a try if you have not thought of that yet.

[ChrisKaswer]

I have also used a "zero" motion dynamic analysis as the starting point for a full run. This will provide an initial dynamic condition that the system should like.  As SweetPeasHub suggests, run the dynamic study with zero cam rotation and let things "settle", then use the resulting position as the starting point (in a "Snapshot") and seed your full dynamic run with this as the initial position. I needed to do this for any valve train system where I modeled the spring as full-dynamic, due to the intense response behavior from modeling the details of the spring. Good call on the "accuracy" - didn't think you may have touched that one...BTW, did you try to let it run with the default value?

[EPeters_PE]

Started a run at the default.... I was going to take a long while.. so I when back and adjusted down a order of magnitude at a time.. seems to be at a decent time/accuracy for this model now.  I had forgotten that I was playing around with that setting earlier during the initial assembly, I had overconstrained once and thought I maybe it was accuracy giving me a problem, found my overconstraint, re-assembled in a different matter, then never went back to set the accuracy back to a reasonable number. GIGO

I am using a "Zero" time dynamic, but not much changes as the springs in the system I have all balanced out by calculating the pre-load distance into them, so during the spring definition my U value is set to my pre-defined balanced pre-load.

[gfraulini]

It would be a nice thing if you build a dummy assembly that replicate the same joints/system you really have. So you could share it with us.

Questions like this apart, have you checked if the redundancies are zero? If the number of DOF remained free are zero? (you can do these things by system measures).

I suggest you to re-edit the part geometry of cam/follower by incrementing the accurancy (model properties > Accuracy > Absolute).

Another suggestion I can give you concerns how to input curve points to Creo Mechanism. If you have a motion law different from a simply straight line or sine, you should build the curve outside (eg: with mathcad), export a tab file and utilize it in the servo definition with the "Use external file" link.

[ChrisKaswer]

One more thing to mention - even though your displacement measure looks to have a "smooth" response curve, take a look at your velocity and acceleration curve too. These can get noisy very easily if the definition and/or transitions are not proper or defined with enough resolution. I've seen more than my share of "clean" cam lift displacement curves that, when analyzed, produce noisy 1st and 2nd derivatives. Given your load curves of "before/after", it appears you've got clean accels making their way into the system...but it is a very good output to review for all cam-driven systems.