Assembly3 preview

[wsteffe]

You have to drag the body inside.

Ok thanks.

I didn't find any problem with test6

Also, please sync both LinkStage3 and asm3 repo before try again, in case you are caught in a bad commit.

I have just re-synced both but my problem persists. Following report is produced after loading test6 and pressing the "solve constraints":

<asm3.gui> 39.354643 - gui.py(261): command "asm3CmdSolve" exception
Traceback (most recent call last):
File "/home/walter/.local/lib/python2.7/site-packages/freecad/asm3/FCADLogger.py", line 106, in report
return func(*args,**kargs)
File "/home/walter/.local/lib/python2.7/site-packages/freecad/asm3/solver.py", line 404, in solve
return _solve(*args,**kargs)
File "/home/walter/.local/lib/python2.7/site-packages/freecad/asm3/solver.py", line 352, in _solve
objs = FreeCAD.getDependentObjects(assemblies,False,True)
TypeError: function takes at most 2 arguments (3 given)

[realthunder]

I have just re-synced both but my problem persists. Following report is produced after loading test6 and pressing the "solve constraints":

Hmm... something wrong with your local repo, maybe? You can check the code at here. According to git blame, this line is changed in last September.

[saso]

Let me try to give an example to why to some of us details like how something is named (or even icons, less, but still) are important or why it makes things confusing to us. In programming you have things like functions, classes, arrays, if, while,... There are many programming languages and each can have a bit of difference but a function is still a function and a class is still a class. It is the same with parametric cad, in the end a Part is still a Part and a fillet is still a fillet. If we would not be building an parametric cad program but a new programming language and we would just mix all this and name an "object" what works like a class, and an array a "function",... Users that don't know other programming languages would not care, however someone that is trained in other programming languages could for some time try to adjust to this differences, but at some point you would for sure say that it is just crazy. So if something works like a Part then it should be a Part.

Lets get back to the programming analogy and say we are talking about implementing a class, and that the PDN Part is an implementation of the class that is somewhat ok but does not support private members and your implementation of the class now adds this, this is still a class and for the time of testing we can have both but eventually one will have to be removed. And if you don't think that PDN Part should be removed, then we should fix it and not be creating new ones.

How would you be able to program if you would have in the same programming language 5 implementations of what works like a class and all of them would work similar but different, and some would be named class and other would be named function but at the same time there would also be a function that works like a function, and non of this would actually be compatible between each other, so in some cases you would have to use some but in other cases the other but none of them would give you the complete functionality that you are used from in other programming languages?

And this is also why this, where the "linking structure", instead of the "part/assembly containers structure", is used for the imported step also makes absolutely no sense to me.

[wsteffe]

Also, please sync both LinkStage3 and asm3 repo before try again, in case you are caught in a bad commit.

Perhaps my problem is related with an incomplete installation of python modules.

For building/installation of LinkStage3 I am using the standard procedure: configure, make, make install.
But I have seen that assembly3 python module is not installed by make install.
In an old post you suggested me to copy asm3 folder into /home/walter/.local/lib/python2.7/site-packages/freecad/.
Then I have prepared the following script which I have used all the times to re-sync and re-install the asm3 module.

I am writing here inline because for some strange reason it can not be uploaded as an attachment.

---- here it is assumed that you are in src/Ext/freecad:
cd asm3
git submodule update --init slvs
git submodule update --init py_slvs
cd slvs/build
make _slvs
cd ../../../
cp asm3/slvs/build/src/swig/python/slvs.py asm3/slvs/build/src/swig/python/_slvs.so asm3/py_slvs/
rm -Rf /home/walter/.local/lib/python2.7/site-packages/freecad/asm3
cp -a asm3 /home/walter/.local/lib/python2.7/site-packages/freecad/
---

Perhaps I am missing something which should be added into my folder /home/walter/.local/lib/python2.7/site-packages/

[realthunder]

Perhaps I am missing something which should be added into my folder /home/walter/.local/lib/python2.7/site-packages/

Assuming asm3 is a git repo you cloned from mine, to sync Python only changes, just run

Code: Select all

cd /home/walter/.local/lib/python2.7/site-packages/freecad/asm3
git pull

If there is change in solvespace, which is very rare, then you can

Code: Select all

cd asm3
git pull

And then follow you script and compile _slvs again. I have only updated slvs source once or twice. It mostly just python code changes in asm3.

[realthunder]

Lets get back to the programming analogy and say we are talking about implementing a class, and that the PDN Part is an implementation of the class that is somewhat ok but does not support private members and your implementation of the class now adds this, this is still a class and for the time of testing we can have both but eventually one will have to be removed. And if you don't think that PDN Part should be removed, then we should fix it and not be creating new ones.

Ah, this. I wrote asm3 workbench to prove that my Link implementation is ideal for use with assembly/part, and that App::Part is lacking critical function. The upstream hasn't response to my opinion yet. I can't just remove App::Part right now.

And this is also why this, where the "linking structure", instead of the "part/assembly containers", is used for the imported step also makes absolutely no sense to me.

Similar reason as above, asm3 is currently an external python only workbench. It is not in FC source tree, while the STEP importer is inside source tree, so it cannot use asm3 container. The container used there is called LinkGroup, which is also used to implement the asm3 container.

The whole situation all comes down to the fact that I am still waiting for upstream to review my branch.

[wsteffe]

cd /home/walter/.local/lib/python2.7/site-packages/freecad/asm3
git pull

Thanks, I have done it and now test6 works.

[Zolko]

And if you don't think that PDN Part should be removed, then we should fix it and not be creating new ones.

Ah, this. I wrote asm3 workbench to prove that my Link implementation is ideal for use with assembly/part, and that App::Part is lacking critical function. The upstream hasn't response to my opinion yet. I can't just remove App::Part right now.

For what it's worth, I agree with both of you. But once a problem is identified we can work on a solution. What would you think of the following approach:

• we agree that the App::Part container is the correct one to build an assembly framework [YES/NO]
• we clone that container and give it a new name:
  • either something like App::Part_New or App::Part+ or App::Part_Next
  • or a completely new name that could be usable even later, like App::Model
• enhance this clone of App::Part with the functionality needed for a good assembly workbench based on the App::Link framework
• once functional and stable and universally agreed-on, propose to the maintainers of App::Part to extend their container with the extra functionality
• if the maintainers accept those modifications to App::Part, then merge the 2 branches
• if not, add that new container as an additional container, and if it's so much better than App::Part this latter will eventually fade into irrelevance

Any thoughts ?

[realthunder]

For what it's worth, I agree with both of you. But once a problem is identified we can work on a solution. What would you think of the following approach:

These are effectively what I am doing now, except for the name (and icon). If there are more people complain about the name, sure I can change it, no problem. My own thoughts is that, since App::Part is going to stay for some time, having a similar name (or icon) to it is going to be more confusing.

[wsteffe]

These are effectively what I am doing now

Are you meaning that assembly container from asm3 is inteded to replace the part container from App::Part ?
It would be nice to but it doesn't seem to work yet. I have tried to use Part Design module to create a body/pad directly inside the assembly container and it doesn't work.

So I assume that part container is needed to create geometry with Part Design Module.

Why it is not possible the following workflow (which seems more natural) ?
-create an assembly
-make it active
-start Part Design and create a part in the assembly
-create a body in the part ...