rotating Assy 3 model to a desired angle and back to 0deg (solved)

[bambuko]

...only constraining cos(angle) - giving two valid solutions...

I guess this is pretty common in vast majority of CAD software?
and perfectly adequate for vast majority of uses.
Mine is a minority/niche interest, which commercial CAD software suppliers have no incentive to solve.
For open source like FreeCAD there is an option of writing a code to solve it?
but this is not something that I am capable of

...but there's more going on than just this.

The actual solver problems when you try to rotate assembly at too fast increments are not neccesarily related to angular ambiguities?

To quote from realthunder's wiki page:

...SolveSpace is a numerical solver, which means it is sensitive to initial conditions...

[edwilliams16]

...but there's more going on than just this.

The actual solver problems when you try to rotate assembly at too fast increments are not neccesarily related to angular ambiguities?

To quote from realthunder's wiki page:

...SolveSpace is a numerical solver, which means it is sensitive to initial conditions...

The sensitivity to initial conditions just means the algorithm can converge to a valid solution- but not the one you had in mind. Here it can converge to a non-solution.

See https://github.com/realthunder/FreeCAD_ ... issues/523

@realthunder suggests using an attachment constraint and adjusting the offset property. It works.

[bambuko]

...@realthunder suggests using an attachment constraint and adjusting the offset property. It works.

Thank you!
I can understand how Lock and Attachment constraint might work better.
This can be done easily for a simple model.
For my (far more complicated) model, PlaneCoincidence and AxialAlignment constraints further down the line are unavoidable for the assembly to work correctly.
Is this going to cause problems?

Plus (I guess) doing it Lock and Attachment constraint way, would preclude possibility of continous 360 deg animation?

I will experiment later today and hopefully report her

[edwilliams16]

Animating by adjusting the attachment angle instead of the constraint angle should work fine. I guess you’ll find out if it works down the line soon enough! If not we already have a workaround for the bug.

[bambuko]

Animating by adjusting the attachment angle instead of the constraint angle should work fine...

Yes, that indeed does work absolutely brilliantly for one/simply rotating assembly.

but...
and this is a big BUT for me
the rest of the model and all it's related assemblies don't feel like cooperating at all ...

LATER EDIT:
I continue investigating... this could be something wrong with my constraints...
more to follow

[bambuko]

OK, so I have Locked all axleboxes, and used Attachment constraint for drive axle assembly and another Attachment constraint for coupled axle assembly.
Both are rotated by setting angle value for element offset (using expression formula and spreadsheet).
This works brilliantly, I can rotate to any angle from any position, no hesitation, no solver problems:

rotate_experiment.jpg (460.45 KiB) Viewed 1845 times

Unfortunately (as I half expected) any other assemblies constrained to the drive axle assembly (there is nothing constrained to coupled axle assembly) are as dodgy as always.
I can rotate them gently (no more than about 10 deg and even 2 deg sometimes confuses the solver )
Maybe it is the way I have constrained it (but I doubt it... tried various options):

rotate_experiment-1.jpg (719.27 KiB) Viewed 1845 times

[edwilliams16]

So the solver needs a hint other than the initial configuration to get the right answer if you rotate the drive assembly by more than a small amount.

I would attempt to identity the driving parameters for the various constraints. Then by incrementing slowly, I'd rotate to say 45 degrees and write down the values. Then I'd run it back to the starting point. Then change all the driving parameters by hand and call the solver. If the model happily converges to the correct 45 position, you have the correct set of hints. Now we make a macro to generate a lookup table (or subsequently fit the table values with a lookup function) that give the constraint values as a function of the drive assembly angle and put it in your spreadsheet. Now when you change the drive assembly angle in the spreadsheet (or wherever you linked it), the driving parameters are set to the nearest entry in the lookup table (or to the value of the fitting function) which is then used as an almost correct initial condition for the solver which should then be able to home in on the correct root.

I would try just adjusting only the axial constraints this way, as that is the only case we know so far that doesn't work properly on its own. So as a first experiment write down the axial constraint angles when the drive assembly angle is 0 and 45 and see if you can jump back and forth by setting the angles by hand and solving.

[bambuko]

Thank you!
Understand your suggestion OK.
I can for example isolate everything else and just analyse coupling rods.
They have simple CoincidentPlane constraint on driving crankpin and SameOrientation on the flat top face to make sure they remain horizontal.
I know from tests today that CoincidentPlane alone is perfectly fine (coupling rod rotates happily with the driving axle),
it is only when I further constrain it with the second constraint that things go wobbly.
I will try it tommorow and report my findings.

[edwilliams16]

Just looking at your model, it looks like the basic geometry is a crank pushing a piston through a connecting rod. You could set the angles and piston position with trig - and use it as an initial "guess" to keep the solver happy.

crank geometry

IMG_0939.jpg (871.49 KiB) Viewed 1848 times

[bambuko]

Yes, I have used this kind of stuff in my earlier attempts, when I did "animation" using sketcher solver.
It was actually working OK, but only for one side,
it got too complicated when I tried to do mirror model with RH side 90 deg ahead of LH side

LATER EDIT:
couldn't resists...
so dragged myself back to the computer
and tried something that might be the simplest answer - toggled OFF "Auto recompute"

So far, it seems to be working (tested just on coupling rods).
more testing tomorrow ....