Messages

1

CamBam help (General usage) / Re: zConst Calculations: why does it take soooo long?

« on: March 24, 2025, 16:15:04 pm »

Ralf, that helped a lot!! Thank you!
I managed to reduce the file size to 4MB like in the tuorial and it still looks good. Now calculation time is only a few minutes! Instead of hours. Incredible what a difference that makes.
You made my day!

Jens

2

CamBam help (General usage) / Re: zConst Calculations: why does it take soooo long?

« on: March 24, 2025, 11:28:34 am »

Hi ralf,
thanks for your reply.
Actually I rely on FreeCAD because I need to be able to stick to close measurements and parameters, and also be able to modify these in the process.
And something like blender and co. (I do use only linux which reduces the possibilities) I would have to learn completely from scratch.
So I think it is good to go with FreeCAD and work around the backdraws in the process. So I am very glad to find some hep here.
Meshlab is a software that runs on my system here, but I have not used it yet except for analyzing the mesh for errors. I will look into a possibility to reduce the polygons. For more hints I'd be grateful of course.

Anyway, even with a big stl, as I wrote in my initial post, sometimes the calculations were done within 3 hours, while now it has been calculating for 4 or 5 days and still going.. wonder how the result will look.
So there must be some more reasons, not just the size of the mesh.

Jens

3

CamBam help (General usage) / Re: zConst Calculations: why does it take soooo long?

« on: March 24, 2025, 07:14:35 am »

Hi Dave,
thanks a lot for your response and the ideas.
I will look into the 2.5D option, didn't even think of that.

For the meshs, it is not comparable to your example with the nema motors.
In a mouthpiece, unlike with the motors, there is not a single planar surface. Everything is curved, and especially the curves on the inner part of the geometry are crucial to not have any deviations from the designed model.
I also think that the file size is huge, but I played a bit with the standard meshing algortihm of FreeCAD now, and the results are disappointing, just as they were when I started doing this long time ago (thats why I use mephisto).
If I set the parameters in a way that will result in s smaller file size, the mesh look super ugly with lots of failures in it and planar sections where they must be rounded. When I set the parameters in a way that I get the smooth surfaces I need, I get a very ugly mesh AND the file size is even bigger than using the mephisto algorithm..
I would be grateful for a good solution that has a decent file size and little deviations from the originating 3D model.

I attached two files, one is the mephisto with the well spaced polygons, the other one is the standard meshing algorithm with the weird ones. File size is ca. 25 VS 30MB.
I also don't get why the files are so huge. Could it be that FreeCAD exports this in a weird way (I export using the mesh workbench)?

For the manufacturing: The inner part is done manually with other tools. I use the CNC to machine the blank on the outside and the inside to the point where the mill can reach (using 4 axes btw.). The rest is done manually.

Thaks so far and best regards,
Jens

4

CamBam help (General usage) / zConst Calculations: why does it take soooo long?

« on: March 23, 2025, 15:52:04 pm »

Hi,
I am getting more and more frustrated, because I can't continue with my work because of Cambam.
The problem: I have 3D Models that needs to be milled, and the zConst roughing calculations do take forever (and due to bugs in the linux version, often fail completely).
The models are rather simple (saxophone mouthpieces) and only parts of the whole model need to be calculated (using outlines for these areas).
The stl files are between 25 and 30MB, because I need the resolution and smoothness of surfaces (524440 polygons for a certain model here).
The stl files DO NOT HAVE ANY ERRORS that I could encounter using several analyzing tools like meshlab or FreeCAD (which is used to create these using the mephisto meshing algorithm).

I even test the windows CamBam using wine under Linux to see if it is related to the build, but it seems it isn't. Under Linux as well as "Windows" Cambam has been calculating for 3 Days! And this is only one operation of many. It just doesn't get to an end, and when it does, I often get errors like unsecure tool paths (which might be related or not, it takes forever even when the result is fine).

I use depth incremets of 1.5mm to 2mm, so max 10 planes that have to be calculated.

Sometimes this goes much more quickly, within 2 or 3 hours, but with my latest models, which are even made more elegantly and definitely without any erros, it just takes forever.
Can somebody give me a hint what this could be related to? Why are there models that are "quickly" calculated and why does it take 3 or 4 days sometimes?
My computers are not of the slow kind, for sure not the fastest but it shouldn't take that long.
There must be something wrong but I can't find it, tried literally everything I can think of. Yet Cambam hinders me to continue my work and earn my f......g money. Help!

Frustrated regards,
Jens

5

Members Projects / Re: Mill Mage

« on: February 05, 2025, 19:08:08 pm »

Let us know how it works with 3D operations and 4 axes!

Jens

6

Bug Reports / Re: CB 1.0+ Linux: Wrong path calculation when 3D object, transformation matrix

« on: February 05, 2025, 09:30:49 am »

Thanks David, I will test these methods.

Jens

7

Bug Reports / CB 1.0+ Linux: Wrong path calculation when 3D object, transformation matrix

« on: February 04, 2025, 20:07:11 pm »

A bug that has been bothering me for a while is about wrong paths beeing calculated in z constant roughing mode.
I have a 3D Object (imported stl) that I rotate around in the 3D space using the transformation matrix ("Einheitenmatrix" in Germand CB).
The values in the matrix are then some crude numbers, not the 1s and 0s in all the fields.
When now calculating the Mops, it looks like a good path generation, but I get offsetts that can be subtle or machine destroying, so be careful!
So e.g. a complete path is 5mm apart in one direction or it might be 0.5mm. Both happens.
The bug is reproducible, because I get it alle the time with different 3D objects (always similar workflow-> import stl, rotate in space).

Now what has to be done as a workaround (and must not be forgotten, see above) is doing the align operation ("Ausrichten" in german CB) for it sets the tranformation matrix values back to 0s and 1s.
Then and only then the path generation works correctly and can be trusted.

CB is 64Bit Version.

Jens

8

Bug Reports / Re: [V1 - 81] Linux: Boundary Method: Selected shape" can randomly get messed up

« on: January 01, 2025, 08:34:06 am »

Anf it happend again, after waiting full 3 days (!!!) for a gcode generation to be finished. AAAHHHHHHHHHHHHH!!!!!
Happy new year folks!

9

Bug Reports / Re: CB 1.0+ on Linux crashes when exploding polylines

« on: January 01, 2025, 08:32:33 am »

The number of segments is not that high. In this case only 6325.
If the bug doesn't occur, the calculation is finished in 3 or 4 seconds. If it occurs, it crashes the whole window manager so that you can wait forever.

10

Bug Reports / Re: CB 1.0+ on Linux crashes when exploding polylines

« on: December 30, 2024, 20:06:17 pm »

Yes I found the file I installed years ago, it is the 64 bit Version.

The "poor drawings" are actually polylines generated by CamBam itself using the Edge detect function.

Jens

11

Bug Reports / Re: CB 1.0+ on Linux crashes when exploding polylines

« on: December 30, 2024, 10:19:30 am »

I think this is written nowhere, you can just download one sort of Cambam for Linux afaik.
About sais "Cambam plus [1.0] rc-3 Linux".

Jens

12

Bug Reports / Re: CB 1.0+ on Linux crashes when exploding polylines

« on: December 29, 2024, 10:09:23 am »

Btw, this crash also seems to happen frequently when Cambam has to deal with many line segments selected at the same time.
In my file that crashed (see above), exploding worked the second time, but then after I selected half of the resulting line segments and moving them around using the transformation matrix, it suddently crashed again (no response from UI) and I had to kill the process from the text console.
I suppose this is somehow connected to some memory problems, since I deal with fairly huge files (3d operations and complex models).

13

Bug Reports / CB 1.0+ on Linux crashes when exploding polylines

« on: December 29, 2024, 09:55:25 am »

CB 1.0+ on Linux crashes when exploding polylines.

This happens often, but not always. Yet another worrying bug. The moment I click on explode, the polyline gets separated into the small segments (I can see in the tree view) but the linux window manager freezes. Have to change to a non graphical console, kill the "mono" task to revive the graphical user interface.
Then restart cambam, try again and da capo...

14

Bug Reports / [V1 - 81] Linux: Boundary Method: Selected shape" can randomly get messed up

« on: December 13, 2024, 09:19:05 am »

Hi, as my first post I write a bug report about the bug that annoyes me most, because it gave me machine crashes twice. Sorry if this got posted somewhere already..

The value of  "Boundary Method: Selected shape" can randomly get messed up when creating the paths:

You put a number in there (the desired shape), and sometimes, here in maybe 10 to 20% of cases, when calculating the paths this exact number gets exchanged by some another (often the ID of the surface or another shape, never a random number!)
You only see this after the calculation is finished (after a few hours). Then you can see that the number value in the filed changed.
If you are lucky you see it in the graphical representation.

Here is why this is a huge problem: First, I work with high detailed complex 3D Shapes, which leads to calculation times often between 2 and 5 hours. It is simply frustrating seeing after all that time that it got messed up.
Because you have to start over and hope it works next time. There is afaik no secure workaround for this.
Second: if you are unlucky the number gets exchanged and you don't realize it, because your bodys and shapes interact in a way that the expected end result looks nearly the same.
In the 2 cases I crashed my machine, because suddently there was a tiny path reaching through the  clamping.
Check your gcode first everyone says which is correct and necessary.
But in this case it was part of a workflow, where I sometimes change small model details, update the model in cambam and recalculate the same paths. If this works 10 times in a row you don't expect the 11th time, that there is a small little line in your software that you overlooked because the coffee was too weak.

There are a lot more bugs and worries, here I really ask myself where cambam is going.
Obviously nowhehe, which is a tragedy for me. As a linux user you have little choices and cambam can do what I need and I have been working with it for years now, I like the workflow and can do with it what I need.
I really want that these annoying bugs get fixed. If the Dev can't or doesn't want to work on it anymore, that is a huge letdown for the people who bought it and have their production methods aligned.

If there is any way to rescue CamBam I'd support it! The actual situation is plain frustratign for me...

Anyway, thanks to David again for adding me,
Jens