Closed alexpGH closed 1 year ago
Can you try with newest version from github and Blender 2.82a? It seems to work fine for me. If the problem persists, please send an example .blend file and I'll have a look at it.
Hi,
I tried to use the newest version of blendercam (before changing all other components like blender, opencamlib etc.).
However the current head in master gives me (on the console when starting blender):
blendercam/scripts/addons/cam/__init__.py", line 112 experimental: BoolProperty( SyntaxError: invalid syntax
invalid syntax at the : of line 112
I'm no pro in python. Any ideas?
I've just checked with the most recent version and can't replicate the error. Did you get most recent version using git? The command would look like that:
git clone https://github.com/vilemduha/blendercam.git
And install it for Blender 2.82a?
Yes, I git pulled the head in master. I have not yet blender 2.82a as i'm on an older debian stable. Does the current blendercam require python 3?
The line 112 ff in the new version reads:
experimental: BoolProperty( name="Show experimental features", default=False, )
while in the older version
experimental= BoolProperty( name="Show experimental features", default=False, )
-> using : istead of =
There are some more of such adaptions (e.g. line 127, 150,...)
Is this a new feature (allowing to use : istead of =) in python 3?
Debian stable has Blender 2.79 right now and there were lots of changes required to make blendercam work with Blender 2.8. Can you check if 2.82a downloaded form here: https://www.blender.org/download/ works on your system? You don't have to install anything, just unpack it in some directory, then follow these instructions: https://github.com/vilemduha/blendercam/wiki/Using-Blendercam-from-github https://github.com/vilemduha/blendercam/wiki/Install-opencamlib-into-blender-2.80-on-linux https://github.com/vilemduha/blendercam/wiki/Using-BlenderCAM-with-OpenCAMLib
Blender 2.82a in principle run. However (due to the forced change to python3), I need to recompile opencamlib, which now requires a more recent cmake which is not present at debian. -> the good old dependency hell I started to compile cmake and will try to get a 2.82 based setup runnig. I think this will take some time. I will report.
Or maybe change required CMake version in CMakseLists.txt. It's possible that new version isn't really necessary.
I've just added a fix so newest blendercam version can be used without opencamlib, so you can avoid compiling it if you don't need it.
Thanks for the fix, came too late, I already was compiling... After some busy hours I now have a fresh compiled cmake, opencamlib for python 3, running blender 2.82a and the blendercam set up.
When starting blender I get a warning (for the sake of completeness)
Warning: property 'release_confirm' not found in keymap item 'OperatorProperties
Now that everything is running again (on the newest versions) i still have the same old problems.
Lets start with a simple profile operation. The screenshot S1 shows that the milling operation steps down to the end of the material.
This happens for both cases a) explicit given operation depth end (in this case -0.02m) b) selecting depth from object.
I cant upload the .blend file and therefore opened a topic in blenderArtists forum, which I usually use for blender related discussions: here
Might be that all this is a simple misconfiguration on my side. Any ideas?
Alex
P.S.:
The same affects the pocket operation.
If I separate the inset plane and apply a pocket operation, the operation in all cases is calculated down to the end o material:
Also using a setting fo skin (for coarse milling first) is ignored
The depth of the pocket is defined by the position of object's origin. Typically both pocket and profile operations should be used on curves, not meshes. The best way to do it is to select feature-defining edges in mesh, duplicate & separate them, then convert to curve. To get real pocket depth, use Set origin -> origin to geometry command on resulting curve.
I forgot to add that if you already have opencamlib, you could also try Waterline operation - it is very useful for complex geometries for which it would be difficult to extract curves manually.
Ah, sorry, I forgot to convert to curve and set the origin (as described in the machining technical parts
I did so, but still have the same problem:
The screenshot shows the curve, with its origin.
When applying a pocket operation on that curve, it still goes all the way down (with depth from object and amnually set depth limit):
the corresponding blend file can be found here:
blenderArtistsTopic
It seems like the object the depth is taken from is the cam material instead of the curve...
Do I still have a missconfiguration?
If I understood right, the curve toolbox should be able to extract the curve for me (instead of doing it manually). However selecting the cube and hitting 'get pocket surfaces' gives `Traceback (most recent call last): File "/home/alexp/wicht_soft/blendercam/scripts/addons/cam/ops.py", line 1197, in execute n = mw * face.normal TypeError: Element-wise multiplication: not supported between 'Matrix' and 'Vector' types
location:
location:
location:
It seems that the problem is in "Material size" option - material size overrides operation depth and it should be the other way around. If you select "Estimate from model" and "Depth from object" everything works fine in this example.
Hey, great you found that! However there is still an open issue: Even when selecting depth from object and estimate from model + a value for skin (which should leave some material for the finishing pass), skin setting seems to be ignored.
Workaround would be to use an explicit depth setting setting
I forgot: How about pockets with curved bottom face? I sometimes have this. So far I was using 3d stragies like parallel, which is a pain as the contour will not be exact.
Edit:
to illustrate what I mean here a part of a really milled, build and used SUP board:
we have a curved lower skin (for channels). the board is milled in upper and lower half in oder to apply lots of pockets for weight reduction.
The pockets end in a curved surface (exactly parallel to the real suface, e.g. 5mm for the surface having enough stability.
ripping off some surface pannels shows this;
In my opinion the best option for extremely complex geometries is to use parallel and waterline strategy (waterline requires opencamlib). Waterline strategy will guarantee that the contour will be exact. I don't think the 'skin' parameter works right now. It would be easy to fix though - 2*skin value should be added to cutter diameter when operation is computed and object geometry/operation depth should be raised by skin value.
Thanks for the hint with waterline, I will test it. Regarding the Skin parameter you are referring to the python code - right? Any hints in which files to look for it? I could have a look and could try to fix it.
I've just added skin parameter for opencamlib. Let me know if it works.
I'm stuck with that divide by zero error when using custom material size - I can't figure what "betweensample" variable is for, so I don't want to break something by chance.
Can you try adding skin parameter for pocket and profile strategies?
the relevant functions are in utils.py:
def strategy_pocket(o):
def strategy_cutout(o):
I've also fixed Get Pocket Surfaces.
Hi, thanks for your fixes, and sorry for the late response. I got 'sidetracked' by the main job. I will pick-up this in the coming days again. Alex
Started testing today, retrieving the pocket surface also works for me now (most recent master version). Regarding the skin parameter; I can try. What is the best approach for debugging the python code? Can I debug it from within blender or do you call the respective routines directly in an external IDE?
Hi all, I'm using blendercam for a while now, but ever since have the problem that depth from object or operation depth end set manually is ignored. The toolpath always goes as low as the material's Z depth.
I'm setting the material depth accordingly as workaround. However, it would be good to get this working.
Does anyone have the same problems? Any ideas?
I'm currently using blender 2.79b and blenderCAM commit edcd11f13fb5464f72089503e97cde255022aa2d Merge: 9542d74 1ac18e4 Date: Mon Feb 20 21:32:22 2017 +0100 now updated to the current head in master