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.
Had it WAY cranked down, .01 to keep solve speed up...
What is this factor in MDO doing mathematically in the solution?
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...
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.
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.
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?
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.
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.
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.