Another approach to assembly solver (A2plus)

[manuelkrause]

@Kbwbe,

there is 1 constraint solved at stage 2, all other are solved all together in the stage 5 because there are not enough constraint to match stages 1 or 2,
the attached file adds several lockrotation so some constraint are solved alone, and it finally solve it.

I think even master fails on it, or I'm wrong?

cranckshaft_reworked.gif

You're completely right with "not enough constraints". I recently reworked this crankshaft assembly and noticed, that the solver was much happier when applying some additional pointIdentity constraints (what logically did the same as lockRotation would/ should do in these places).

[manuelkrause]

Mmm. That's not enough info for me to find my mistakes. I'd attach the current devel-branch based changed files and a .diff patch as well for reference.

Please retry and then, please, find more descriptive words than your "no success" and "not run correctly".

TIA

Hi Manuel,
Yesterday, i stopped debugging early. Sorry for missing informations.

Thank you for your files. I opened new branch "improve-color-import", based on "devel" branch and inserted your files.

Quicktest-result:
- import of subassemblies works, colors are imported, transparency not. ( I think it is not possible )
- import of single parts does not work anymore, see console output: (you have to check that a property exists before accessing it)

Code: Select all

Running the Python command 'a2p_ImportPart' failed:
Traceback (most recent call last):
  File "/home/klaus/.FreeCAD/Mod/a2plus/a2p_importpart.py", line 316, in Activated
    importedObject = importPartFromFile(doc, filename)
  File "/home/klaus/.FreeCAD/Mod/a2plus/a2p_importpart.py", line 172, in importPartFromFile
    importableObjects.extend(getImpPartsFromDoc(importDoc))            #visible parts only
  File "/home/klaus/.FreeCAD/Mod/a2plus/a2p_importpart.py", line 89, in getImpPartsFromDoc
    impPartList = filterImpParts(obj)
  File "/home/klaus/.FreeCAD/Mod/a2plus/a2p_importpart.py", line 143, in filterImpParts
    elif obj.subassemblyImport == True:          # assem item

'PrimitivePy' object has no attribute 'subassemblyImport'

Find attached the part, which can not be imported

Your replacements of "unicode()" to "str()" breaks unicode handling on Py2 machines. So our french user @JBE could use accents anymore. It has to be replaced dependent on PyVersion...

Code: Select all

PyVersion=sys.version_info[0]
if PyVersion == 2:
...
else:
...

Ah, yes! That was the information needed to work with. Thank you!

Locally I've fixed it and most likely this would also fix your missing subassembly transparency (as importPartFromFile is involved).

Please leave me some time to learn into github, so things can be handled easier and less time consuming.

Thank you for your time and work!

[wandererfan]

Please leave me some time to learn into github, so things can be handled easier and less time consuming.

This thread has a whole bunch of git/github suggestions.,

[manuelkrause]

Please leave me some time to learn into github, so things can be handled easier and less time consuming.

This thread has a whole bunch of git/github suggestions.,

@wandererfan,
many thanks for that link! It provides the summary of information I needed.
Perfect collaboration on here!
I'd set it up tomorrow.

[kbwbe]

@Kbwbe,

there is 1 constraint solved at stage 2, all other are solved all together in the stage 5 because there are not enough constraint to match stages 1 or 2,
the attached file adds several lockrotation so some constraint are solved alone, and it finally solve it.

I think even master fails on it, or I'm wrong?

cranckshaft_reworked.gif

You're completely right with "not enough constraints". I recently reworked this crankshaft assembly and noticed, that the solver was much happier when applying some additional pointIdentity constraints (what logically did the same as lockRotation would/ should do in these places).

.
Hi Manuel, hi Turro !
i pushed a bugfix to devel branch. It now solves the unreworked crankshaft too !

[wandererfan]

This fastener set is 4 separate pieces in the source file. When we import it, it gets sub-assembled into 1 item. But we should support importing a set of pieces, no?

I can see how to program the importer to bring the fasteners in as 4 pieces, but how should the program decide that importFile1 should be merged into a sub-assembly, but importFile2 should be left as separate items? A separate "import as pieces" command seems excessive. Any thoughts?

[Turro75]

This fastener set is 4 separate pieces in the source file. When we import it, it gets sub-assembled into 1 item. But we should support importing a set of pieces, no?

I can see how to program the importer to bring the fasteners in as 4 pieces, but how should the program decide that importFile1 should be merged into a sub-assembly, but importFile2 should be left as separate items? A separate "import as pieces" command seems excessive. Any thoughts?

How about a question dialog to ask what to do whenever found a multi shape obj?

One request, does it can be added a command to transform a shape already in the fcstd to a valid asplus obj which can now be "seen" by constraints?

[kbwbe]

This fastener set is 4 separate pieces in the source file. When we import it, it gets sub-assembled into 1 item. But we should support importing a set of pieces, no?

Hi wandererfan,
Which usecase do you see for a "import as pieces" ?
I think it will complicate future releases of A2Plus regarding reimporting of edited parts. (Especially when we try a kind of topological naming)
I would not do this ATM, if there are no clear applications for that feature.

Our state now, being able to import multi shape parts (afterwards combined to one shape), is already going beyond the capabilities of Hamish's A2 WB.

[kbwbe]

One request, does it can be added a command to transform a shape already in the fcstd to a valid asplus obj which can now be "seen" by constraints?

Hi Turro, wandererfan,
this could be somehow useful, as for working e.g. fasteners from correspoding WB.
@wandererfan: Is it possible to adapt your import-algo to convert a shape within assembly to a valid A2plus importPart ?
Property "sourceFile" has to be handled differently later, as no reimport is possible.

[wandererfan]

One request, does it can be added a command to transform a shape already in the fcstd to a valid asplus obj which can now be "seen" by constraints?

Yes, I believe this would be fairly straight forward.
This would be a shape that didn't pass though importer to be added? Maybe a base shape for the assembly?