"It appears that current Kinematics software does not model power available."
Well, I don't really agree. For example, in my powertrain model (which plugs into my standard vehicle model) I'd have an engine torque vs rpm curve. Then my driver model applies a certain throttle %age. The solver looks up the current rpm, and delivers that % of that torque to the crankshaft. This then goes through the rest of the driveline model, via inertias, springs, damping, gaps and gears and whatever, to the contact patch.
That's overkill for most vehicle dynamics work, but it is there.
So the problem seems to be that the kinematics software bundled with Cosmos is less powerful than the standalone products. I don't think that is surprising - using ADAMS less than 2 days a week would be frustrating, and I normally edit the code by hand, in parallel with the GUI.
"The problem with adding mass for limiting the max acceleration is you change the acceleration forces, output forces at different positions, and inertia when stopping."
Sure. All of these models work better if you don't trick them, but model the actual process in the mechanism. So if your pump has an inertia, put it in. If the fluid in the lines has an inertia, put it in. If there is a pressure restrictor, or a one way valve, put it in. Replacing a 5 element block, as suggested above, by one transfer function is /possible/ but is hard to debug.
As another example my power steering model has a simple pressure vs engine rpm vs flowrate delivery map to represent the hydraulic pump side. That's not really good enough for what I want, so the next step is to put the hoses and so on into the model, as I am interested in elasticity and resonant effects. I could cheat and add some arbitrary first order systems in there to represent those resonances, but ultimately it is more robust to model the real system than abstract it down to a very complex equation.
Cheers
Greg Locock
Please see FAQ731-376 for tips on how to make the best use of Eng-Tips.