Another approach to assembly solver (A2plus)

[manuelkrause]

Hi,
I just want to confirm, that changing the function to the shown section of code in a2p_MuxAssembly.py, works fine from the start for my FC 0.17 assemblies. Of course, without any of the lengthy lines I had introduced with my code.

Shapes, colors and transparencies are taken from the underlying sub-assemblies, and saved changes in there are taken over at a simple "Update imported parts".

Thanks!

Manuel

Thanks Manuel,

does this change has an impact on assembly file size?

In my case for the engine assembly it didn't change the file size. But I need to say that I haven't changed much in the sub-assemblies: only tried changing colors and transparencies and didn't re-assemble any of them from scratch.
Primarily I only wanted to see the intended color/transparency take-over over more assembly stages with the much-much simpler code, and it worked out of the box.

Really a very good finding from @wandererfan and a proper implementation from @kbwbe!

[manuelkrause]

@kbwbe:
I inspected the files you posted which I wasn't able to open on here.
They're also stamped with "assembly2".
Can it be that you still have an assembly2 WB running, so that you're able to open them and my A2plus-only fails due to some incompatible data structures in the .fcstd assembly? Just an idea.
And if so, can it be, that the visualizations of these WBs interfere in 3D view, resulting in "overlayed" effects as seen, artifacts and unselectable faces?

Just a shot into the blue...

[Turro75]

does this change has an impact on assembly file size?

Hi Turro, hi manuel,
also in previous versions we stored one color value per face. I assume filesize will stay constant.

@Turro75:
On Github, i see you are very busy. "Multimode Solver" seems very promising. Are you integrating my "simple" solver into your files ?
If so, we should try to merge with devel, to get your stuff into it.

Hi Kbwbe,

Not really promising, I tried to implement the master solver in the stage 5, I still get some assemblies quickly solved and other completely messed, this also happens when playing with rigid weight constant, some are better to a sort of assembly, other don't.

Recovering the concept of distance from fixed we could identify which assembly is and then choice the better strategy. This will the last chance.

My next approach will be:

As the unfixing strategy is very slow especially if the reason of misplacement is not directly constrained to the one misplaced ,I'll try to unfix everything and then analyze how it works

Another way is
Stage 1 : merge all fully constrained objs
Stage 2 : use master way with progressive and unfixing if needed hoping that reducing the number of objs does the job

[kbwbe]

Stage 2 : use master way with progressive and unfixing if needed hoping that reducing the number of objs does the job

One question: Is merging of rigids compatible with recursive unfixing ?

[Turro75]

Stage 2 : use master way with progressive and unfixing if needed hoping that reducing the number of objs does the job

One question: Is merging of rigids compatible with recursive unfixing ?

I think Yes it is,
Merging simply delete one rigid and replace any reference to merged obj to the resulting one.
The rigid objectName, placement and savedplacement are now list where there all merged objs properties are stored.

The rigids methods that do something on objects were mopdified to properly handle a list

[manuelkrause]

@kbwbe, @turro75:
I'm not seeing, that the current (devel) solver does it's job properly.
Again with my now bloody getting crankshaft...
When constraining over a span of parts, e.g. an axialConstraint, and that fails (due to no reason?) it can lead to a recursive cascade of "Constraint mismatch" errors making the whole assembly useless.
I attach one state before maybe having to delete all previous constraints in the path of assembly.

[kbwbe]

@kbwbe, @turro75:
I'm not seeing, that the current (devel) solver does it's job properly.
Again with my now bloody getting crankshaft...
When constraining over a span of parts, e.g. an axialConstraint, and that fails (due to no reason?) it can lead to a recursive cascade of "Constraint mismatch" errors making the whole assembly useless.
I attach one state before maybe having to delete all previous constraints in the path of assembly.

Hi Manuel,
what's the reason for using all these pointOnLines Constraints ? They are completely useless. For the crankshaft you only need circularEdge, planeParallel and angledPlane constraints.
I remove all useless constraints, had to assemble newly starting from "Kurbelscheibe-004".
At last, i added a additional axialConstraint from first "Kurbelscheibe" to last one. It is really a big span. The assembly is stable. Find it attached.

[kbwbe]

@kbwbe, @turro75:
I'm not seeing, that the current (devel) solver does it's job properly.
Again with my now bloody getting crankshaft...
When constraining over a span of parts, e.g. an axialConstraint, and that fails (due to no reason?) it can lead to a recursive cascade of "Constraint mismatch" errors making the whole assembly useless.
I attach one state before maybe having to delete all previous constraints in the path of assembly.

Hi Manuel,
what's the reason for using all these pointOnLines Constraints ? They are completely useless. For the crankshaft you only need circularEdge, planeParallel and angledPlane constraints.
I remove all useless constraints, had to assemble newly starting from "Kurbelscheibe-004".
At last, i added a additional axialConstraint from first "Kurbelscheibe" to last one. It is really a big span. The assembly is stable. Find it attached.

P.S.: Your crankShaft is not so easy for a solver as it looks like. It is a long chain of constraints, making an assembly less precise. If you start with a "Kurbelscheibe" in the middle as fixed part and extend the crankShaft to both ends, it will be more precise.

P.S.II: Just another hint. In my past assemblies i always used a "Kurbelscheibe" as first fixed part. You have been using a piece of the shaft. The advantage of my approach is, that you have a fixed part with a good reference plane for the following planeParallel + angledPlanes constraints.

[manuelkrause]

@kbwbe, @turro75:
I'm not seeing, that the current (devel) solver does it's job properly.
Again with my now bloody getting crankshaft...
When constraining over a span of parts, e.g. an axialConstraint, and that fails (due to no reason?) it can lead to a recursive cascade of "Constraint mismatch" errors making the whole assembly useless.
I attach one state before maybe having to delete all previous constraints in the path of assembly.

Hi Manuel,
what's the reason for using all these pointOnLines Constraints ? They are completely useless. For the crankshaft you only need circularEdge, planeParallel and angledPlane constraints.
I remove all useless constraints, had to assemble newly starting from "Kurbelscheibe-004".
At last, i added a additional axialConstraint from first "Kurbelscheibe" to last one. It is really a big span. The assembly is stable. Find it attached.

P.S.: Your crankShaft is not so easy for a solver as it looks like. It is a long chain of constraints, making an assembly less precise. If you start with a "Kurbelscheibe" in the middle as fixed part and extend the crankShaft to both ends, it will be more precise.

P.S.II: Just another hint. In my past assemblies i always used a "Kurbelscheibe" as first fixed part. You have been using a piece of the shaft. The advantage of my approach is, that you have a fixed part with a good reference plane for the following planeParallel + angledPlanes constraints.

Hi Klaus!
Thanks that you give me one resource posting to answer to:
* using pointOnLine: Just used, to emulate lockRotation. Otherwise the part would have had one rotational DOF left, what is not intended for this assembly, being a sub-assembly
* I normally start an assembly with the first root part. For the crankshaft it's most likely the first cylinder (fixed)

Please note this after thorough testing:
* I don't want to need workarounds for preferring parts in the order of constraining with A2plus, the solver should do them all, and NOT complain about prevoius good ones at once!

Always read me like this: I don't want to complain but improve!

[babaroga]

Guys, thank you for excellent work. I just wanted to share document made with A2plus in production environment.

https://forum.freecadweb.org/viewtopic. ... 41#p255608

I am preparing tutorial for this WB beauty.