I was working on my bucket_mill.py project again. https://github.com/nathanielstenzel/bucket_mill/releases/tag/0.86
Originally shared by Nathaniel Stenzel
I have silky smooth STL to X,Y,Z now. I have no idea what the line is going through my part though. I really need to check on that. Regardless, release 0.86 now.
I keep making this a little bit better. I may tackle the end-mill bits that are cylindrical but has the cutting size smaller than the shaft sometime soon.
I understood your project input was a bitmap. Right? What is the role of the STL you mention now? Thanks.
It can take in different image formats or an STL file. Later, I may have it also capable of taking in gcode files.
STL files are common due to 3D printing (which is one of my hobbies) so having it take object shapes from them is only natural in my opinion.
Thanks @NathanielStenzel , I missed the STL addition then. I do agree it is welcome addition. But now I have to look at your code 
+Miguel Sánchez, it was just me writing it, so hopefully it is not too messy for you. If you copy any of it for another project, please make sure to give me credit and to send me a link to it. Meanwhile, if any parts are not clear to you, ask and I will explain it and comment the code some. While I am doing this for my own entertainment, my own use and then others’ use in that order, I still want it to be easy for others to work on the code too. Maybe I will luck out and get some help with spots that I can not manage to tackle yet. The only file you need to look at is bucket_mill.py if you want the code. It is the only python file in there so far.
@NathanielStenzel I will have a look at it with interest. I wrote my own CAM in Java, based on dropcutter algorithm thanks to @Anders_Wallin blog explanations. It did not become a commercial product nor an open source project but a service for local artists (CAM is just one of several elements of my workflow).
@Miguel_Sanchez in your work flow, do you have issues with the produced gcode making too deep of cuts or certain bits not being supported? Maybe gcode generation being too slow? Do you require high precision? Precision is something my software does not really focus as much on, but if you need 1/X mm accuracy, you can get it. It just makes more processing to do it.
I have given it a go but I am not understanding the whole thing yet. From an STL it seems to work ok though fine detail (like curves) seem to become a bit minecraft-like. Stating that numpy-stl is needed may help too.
The mine craft look is to be expected unless you set a higher stl detail level. The default is only 1mm. For rough cuts, I would probably keep it at the default. For final cuts, choose the dots per mm. Something like 2-4 is nice as far as I am concerned. I could try to get path smoothing, but it may make more trouble than it is worth.
Run the script with no parameters to get it.
