What's new

Wow - Could have used this

RCH_Projects

Alibre Super User
FAQ - Calculations and validation

https://translate.google.com/transl...w.lista.it/atnet/FAQ3/WM3DFAQ.htm&prev=search

Italian FAQ.jpg

I've spent years working out a lot of what is clearly stated here, but I missed it on the Italian website until now, if it was there; and if I had the translate option. Really good website with translate!

HEY - that's some pretty fundamental need-to-know stuff!

Of course I'm still trying to benchmark/resolve issue with basic operations of Dynamics/Simwise. You can't get this on the US website.

I carefully reengineered the prior benchmark that I posted. I then created side-by-side models of the same components and setting everything I could see to the same relationships (friction, material, constraints (orientation and positions), etc.).

Darned if the friction in one doesn't track with the other.

Frictiony.jpg

I think the deck is stacked :confused:.

I can see myself trying to explain - "I'm sending you these benchmarks from the Simwise software, but, um, The accelerations and speeds don't jive and I've had to fudge around with the frictions to try to compensate, but, um, the results are totally dependable" - (right)!

I'm trying to get an updated version of the Sim to use at least until it all runs out in June. I haven't heard back from Alibre.

If the latest does the same thing, maybe someone can explain???
 
Last edited:
Dear RCH Projects, thank You for linking to my old Italian web pages, endeed it's time to refresh and translate them in English (maybe with Your help!)
Let me also point You out the new page http://www.simwise4d.it/SimWiseAlibreEN.htm (this is in English at least!).
Regarding Your issue, I haven't really understood what You mean (due to my poor English) but first of all I want to point You out that if in one step You can have input data and calculated data, then of course there is at least a calculation step difference between the input and results.
For example, if You need a second wheel to rotate at the same velocity of a first wheel, please consider that by reading the velocity in the first wheel (input data), You can force the velocity of the second wheel to be the same or double or a function of it (output data) only in the subsequent calculation step. If there are integration/derivation operations on those measures You must solve the matehematical discontinuities of course. If integration time step is selected to be variable, then You are loosing control on where exactly in time calculations are made. Finally frame/animation rates could be different from calculation steps. So it's easy to get lost without considering and solving these issues.
To start with, use three wheels:
- the first one not in sight (a ghost wheel) to generate the input data
- the second wheel to copy the input data of the first wheel (so an user believe it's the source)
- and a third wheel to elaborate again the input data of the first ghost wheel (while the user believe it's driven by the second wheel)
So, at least wheels n° 2 and wheel n°3 are at the same calculation step, driven by wheel n° 1.
Ciao! Paolo Lista, Italian distributor, www.simwise4d.it
 
Last edited:

RCH_Projects

Alibre Super User
Thank you for the reply sir!

My poor physics/math/engineering vocabulary does not help understanding either I am sure. My Italian is only as good as "Google" translate or I would love to help. I can look for obvious English errors. Personally I use free online translators from English to another language. Then I translate the result back into English to compare to the original English. I do that until I am comfortable that the sentence maintains meaning both ways - if that helps you.

I understand all that you have said. For just an "eye candy" presentation the three wheel solution is perfectly suitable. The presented model is an effort to understand and reconcile different "friction" results from identical but independent models in one simulation.

I agree that It is "unusual" to have two input data's per step. The simulation is two identical sets of pulleys connected by a belt between each actuator and rotor (two pairs of pulleys with a belt on each pair).

A "torque" Revolute motor is on each actuator using "step(0 lbf ft,0.01 s,-1 lbf in,10 s)".

The two individual actuators turn individual rotors, with friction applied to the rotor constraints (Rotational Coefficient at .9966, Effective Radius at .5 inches.) The only connection from each of the two actuators to the corresponding rotor is a belt.

I would expect the two pair of pulleys to report the same acceleration +- a small percentage at worst. The acceleration of Actuator 2 is greater than Actuator 1, from initial acceleration "step(0 lbf ft,0.01 s,-1 lbf in,10 s)", to steady input torque of "1 lbf in.".

With torque steady at "1 lbf in." I expect acceleration on both sets of pulleys to be identical. But the "Actuator 2" has consistent .3374 rpm/s, against "Actuator 1" with .2511 rpm/s.

The "reaction(?)" torque on the output pulleys do reflect a "Tz .0001 lbf in." difference but can that account for so much differences in acceleration.

For further evaluation I know that I can cross link the belts from each actuator to the other pulley to isolate a cause. This could isolate the issue to the friction component.

I can also create TWO totally independent simulations with the opposite set of pulleys deleted. This could eliminate the "two" input condition in a single simulation.

But to my eyes, the two sets of pulleys are configured totally identical down to the details. Working from scratch, if there were irrelevant variations due to automatic constraint placements or swapped coordinates I would not expect such a difference.

This "exercise" with two sets of pulleys is only the start of appraising the issue with actual work in progress. There I have "belts" that disappear from the simulation (but appear to continue to function) with sudden acceleration then deceleration as alternative components engage and other issues.

For software issues I reengineer or break the relationships into isolated simulations. Not a totally bad thing if it leads to improved design. I had believed that "this" appraisal would have performed without a hitch. All of this is very time consuming and not very conclusive. So I am looking for some consistent outcomes.

The mechanics I explore are not typical or trivial (a copy of any known work or just artsy fartsy) and variations must be tried and compared for performance optimizations (the only outcome with a payout). After "belts" I will start over using "gear" substitutes. Then other different embodiments, then installed applications. I need a higher degree of confidence in the simulation software so I can focus on the solid mechanics.

A whole lot of work waits for me that I might offset with some solid progress that interests principled parties, when I can start presenting accredited evaluations.

Any insights appreciated.

Ciao! Roger
 
Top