Naming edges to create chamfers in macros

[Smoshie]

Hi, I want to create macros that automatically generate shafts with different shapes. My problem is that FeeCAD seems to generate the names of the edges "randomly", especially when one chamfer or rounding is already defined. When a chamfer is made, the new edges don't get higher namenumbers than the existing edges, but all edgenames seem to be generated in a new order. Is there any way to control these names? Or is there a usable algorithm to understand the name assignment?

[wmayer]

Unfortunately we have no control over the ordering of edges (or any other sub-elements). This comes from the cad kernel we use (OpenCascade). So, what we badly need is a topological naming interface so that one can see which edge in the old model is now the edge in the new model.

[jmaustpc]

This is what Jan is working on...isn't it?

[Smoshie]

Ok, i guess i can forget it then. I tried another way by generating the roundings manually with solids of revolution and boolean operations, but I get the error that no valid reference axis is defined. The weird thing is that the model is generated completely right, but the macro just stops at some point and doesn't execute the last commands that are to export the file in a neutral data format. Also there is no reference to which line of the macro doesn't work. All solids have the horizontal axis in the sketcher as reference axis (including the shaft itself, that works perfectly fine without roundings). Is that a bug? I don't see any mistake here.

[wmayer]

Is that a bug? I don't see any mistake here.

Is there a script to test?

[Smoshie]

Yes, here i have the shaft without the roundings that works fine and with them. (It's the same code, i just deleted the optional part). The second macro now doesn't generate any data now but i already programmed some macros that generated the model but failed to finish the macro because of the error as mentioned before. I think the code is right...

Shaft (works):
https://dl.dropboxusercontent.com/u/914 ... ft.FCMacro

Shaft with roundings:
https://dl.dropboxusercontent.com/u/914 ... il.FCMacro

[wmayer]

In both scripts the sketch you use to create "Wellengetriebe" is not closed and thus the revolution fails. When closing it manually then everything is fine.

What I find strange in the second script is that the objects Rundung1, ..., Rundung4 are valid. There you also use a non-closed sketch but the revolution seems to work.

[jmaustpc]

Hi werner
for me Rundung4's sketch005 is closed, they have co-incidence constraint on the 3 corners.

closed_sketch.png (35.09 KiB) Viewed 3402 times

If you hide the other sketches it looks OK for Rundung4 and sketch005. This was with the second macro, "Shaft with roundings".

OS: Ubuntu 12.04.4 LTS
Platform: 64-bit
Version: 0.14.3012 (Git)
Branch: master
Hash: ca3b87a719825ad4065b47ade7b472e1f67dd134
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
SoQt version: 1.5.0
OCC version: 6.5.0

Jim

[wmayer]

for me Rundung4's sketch005 is closed, they have co-incidence constraint on the 3 corners.

Ah, OK you're right. I haven't checked this carefully enough. However, in your screenshot they seem to be fully constrained (because of the green color) but here they aren't. I can even drag around the points so that the sketch intersects itself. So, it might be good to add a tangency constraint too so that this can't happen.

[Smoshie]

Until now I always used the revolution feature with an open sketch and it worked, so i guessed that the program closes the sketch automatically. The sketches for the roundings are closed anyway.

Also i must say that everything works fine with these definitions when i try it manually, but in my macro created with my program there is that strange error...

Now this is the macro with a closed sketch and i still get the error (I deleted the close/open document part):

https://dl.dropboxusercontent.com/u/914 ... l2.FCMacro