Managed to model a finger joint box with relieved fingers --- now how to actually cut it? Allow OpenSCAD to write out files?
On 8/15/2020 5:20 AM, William F. Adams via Discuss wrote:
So, could we please just get a command which would do that with a user configurable file extension?
and Jordan Brown responded:
Remember that the people doing the work are volunteers, >working in their spare time on things that interest them.
It does seem pretty simple. I'd offer to do it myself,
I would appreciate that.
but ... I got OpenSCAD to build successfully in December, >and since then I've found the time to spend maybe two or three hours >on the features that I want.
Understood, hence my mention of a machine.
I'm hoping to shake some funds loose for Bounty Source --- an estimate on what should be offered?
William
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 8/15/2020 5:59 PM, William F. Adams wrote:
Jordan Brown wrote:
What does your input OpenSCAD look like, that emits proto-gcode? I
don't see that in any of the pages you've posted.
I posted my source code at:
https://community.carbide3d.com/uploads/short-url/36SA8hMSvesRwUOKFocbbdxQmrl.zip
in the
message: https://community.carbide3d.com/t/cnc-finger-joint-box/8880/126
Interesting. So pretty much you have two programs interlaced - once
that models a 3D object, and one that emits a toolpath, and they don't
really have much to do with each other except for sharing some dimensions.
The shape of your fingercuts is a cool workaround for the round shape of
the tool.
I'd like to figure out how to drive my CNC machine from an OpenSCAD
model...
so far, I'm not seeing how, other than some tool chains that seem
fragile, unpleasant, or both.
This is just a proof of concept so far, but I think it shows progress.
Just to review --- which CAM options have you looked at or considered?
Thus far I've tried or worked with:
- export STL --- process in a 3D CAM tool such as MeshCAM or pyCAM
This is what I was looking for.
Last time I looked - don't remember exactly when, but a long time ago -
pyCAM seemed to be abandonware. Looks like it may have been revived.
I don't remember whether I tried MeshCAM. The fact that it's $250 was a
big stumbling block. I'm spoiled by the mostly-free world of 3D
printing. I think the only paid slicer in common usage is Simplify3D,
and it's only $149.
I looked at HeeksCAD and played with it a bit. I seem to remember it
crashing a lot.
I looked at Fusion 360. I don't remember whether it would import STL,
but it was very slow and I think I had a hard time understanding how to
use it.
- export DXF or SVG --- process using a tool such as MakerCAM or
Carbide Create
Only marginally interested. I want to model in 3D, not 2D with a fixed
depth for each shape. (Maybe that's an unrealistic thing to want.)
The toolchain should be able to do something useful with a half-sphere:
intersection() {
sphere(20);
translate([-100,-100,0]) cube([200,200,200]);
}
And maybe that demonstrates my naïvety; tool head geometry might
preclude doing that because unless the bit is more than 20mm long the
tool head might hit the sphere getting to the edges.
Tools like Carbide Create are commonly called 2.5D, but if I understand
them correctly I think that I'd only give them 2.2D. The device is
fundamentally limited in that it can only cut down (and so there cannot
be any overhangs of any kind), but it's perfectly capable of cutting
slopes. Carbide Create and the ilk basically have you draw out
something in 2D and then specify a depth for each shape; they don't seem
to have any notion of slope.
Maybe I should get over it, treat the CNC as a 2D device - basically, a
cutter - with very limited 3D capabilities, rather than wanting it to be
the subtractive equivalent of a 3D printer.
Wouldn't this require a post OpenSCAD package that operates on .STL files to drive a milling machine, somewhat of the complexity of a slicer eg Cura for 3D printers?
Otherwise if you are working from pure logical shape identities, why use OpenSCAD in the first place? It almost immediately makes extracting coordinates of shapes impossible or very convoluted.
It seems the answer to this is more than adding a filter to an output debugging stream into a new file format. Especially if a more generalised milling capability than the example given is required. If people designed their models in STL with the same caution as they do for 3D printing (eg resolution, overhangs, speeds, temperatures, etc etc) then it should possible to program a post STL processor that could prepare GCODE files for CAM that can work.
Personally I would find this a very attractive proposition, and useful to extend my (basic) OpenSCAD skills into this area. Cura began with just one line of code at sometime. But it certainly has grown full of useful features.
Cheers, RobW
On 16 August 2020 10:48:35 am AEST, Jordan Brown openscad@jordan.maileater.net wrote:
What does your input OpenSCAD look like, that emits proto-gcode? I
don't see that in any of the pages you've posted.
I'd like to figure out how to drive my CNC machine from an OpenSCAD
model... so far, I'm not seeing how, other than some tool chains that
seem fragile, unpleasant, or both.
$&#@*(. I hate mailing lists that set Reply-To to the list. I meant
that to be a private message; that's why I hit "Reply" instead of "Reply
All".
On 8/15/2020 6:36 PM, William F. Adams via Discuss wrote:
but ... I got OpenSCAD to build successfully in December,
and since then I've found the time to spend maybe two or three hours
on the features that I want.
Understood, hence my mention of a machine.
I have a machine. Just no time. I should make some time for some of
this stuff; quarantine has freed up a bunch.
SainSmart 3018-PRO
https://www.sainsmart.com/collections/genmitsu-cnc/products/sainsmart-genmitsu-cnc-router-3018-pro-diy-kit
It was $200 on Woot. That was within my "try it for fun" budget. I
just wish it had limit switches.
I'm hoping to shake some funds loose for Bounty Source --- an estimate
on what should be offered?
Not a clue. For me, personally, unless it was a ridiculously large
amount it wouldn't be a factor. My day job pays enough to keep me in
toys. Spare-time projects are for fun. Offering me $50 or $100
wouldn't get my attention at all, and I don't think you want to offer $1000.
Jordan Brown wrote:
Interesting. So pretty much you have two programs interlaced - >once that models a 3D object, and one that emits a toolpath, >and they don't really have much to do with each other except for >sharing some dimensions.
I'd describe it rather as a program which shows cutting out parts which has options to show said parts in various positions and to write out the G-Code (and some extra stuff which needs to be deleted).
The shape of your fingercuts is a cool workaround for the round shape of the tool.
Thanks! I've been working on this for a while now.
<big snip>
I want to model in 3D, not 2D with a fixed depth for each shape. (Maybe that's an unrealistic thing to want.)
I think that's a fine thing to want --- there's no reason it couldn't be done using the technique I'm showing you'd just have to model the movement of the tool in 3 dimensions --- hopefully I'll learn enough math to make that happen presently.
The toolchain should be able to do something useful with a half-sphere:
intersection() {
sphere(20);
translate([-100,-100,0]) cube([200,200,200]);
}
And maybe that demonstrates my naïvety; tool head geometry might preclude doing that because unless the bit is more than 20mm >long the tool head might hit the sphere getting to the edges.
It should be possible to do a ball-nosed endmill traveling over the surface of the hemisphere to shape it, then have a square endmill do a waterline path around the lower perimeter of it to cut that out.
Tools like Carbide Create are commonly called 2.5D, >but if I understand them correctly I think that I'd only give them 2.2D. >The device is fundamentally limited in that it can only cut down >(and so there cannot be any overhangs of any kind), >but it's perfectly capable of cutting slopes.
That's 2.5D described as a limitation over full 3D.
Carbide Create and the ilk basically have you draw out something in 2D >and then specify a depth for each shape; they don't seem to have any notion of slope.
Mostly. One can do V carving and textures --- I even did a joinery design abusing the Advanced V carving feature in Carbide Create.
Maybe I should get over it, treat the CNC as a 2D device - >basically, a cutter - with very limited 3D capabilities, >rather than wanting it to be the subtractive equivalent of a 3D printer.
There's always directly programming in G-Code --- with tools such as G-Sharp it might be workable:
https://github.com/NRSoft/GSharp
and there are more listed at: https://wiki.shapeoko.com/index.php/Programming
And Rob Ward wrote:
Wouldn't this require a post OpenSCAD package that operates >on .STL files to drive a milling machine, somewhat of the complexity of a slicer eg Cura for 3D printers?
No, please see my code from my previous messages --- basically rather than modeling the shape, one models the stock and carves away from it using tool-shaped geometry and one captures the tool movement as G-Code.
Otherwise if you are working from pure logical shape identities, >why use OpenSCAD in the first place? It almost immediately >makes extracting coordinates of shapes impossible or very convoluted.
I'm not, and I'm using OpenSCAD because it has a neat front-end in
https://www.blockscad3d.com/
and I've pretty much managed to solve extracting the coordinates.
<snip description of something more complex than what I envision>
I will note that if one modeled a tool such as:
https://www.amazon.com/gp/product/B07XG6MTMH
or a ball cutter on a narrow shaft one could do undercuts.
Personally I would find this a very attractive proposition, >and useful to extend my (basic) OpenSCAD skills into this area.
Thanks! --- I'd be curious what you think of my code or my discussion of this at: https://community.carbide3d.com/t/cnc-finger-joint-box/8880/126
I'll take Jordan's hemisphere description and see if I can make that into a test cut file to cut tomorrow.
I also need to make some test cuts for kerf bending plywood --- since I don't want to go through the tedium of faking it out in Carbide Create directly coding this in OpenSCAD is attractive.
William
On 8/15/2020 7:30 PM, William F. Adams via Discuss wrote:
I want to model in 3D, not 2D with a fixed depth for each shape.
(Maybe that's an unrealistic thing to want.)
I think that's a fine thing to want --- there's no reason it couldn't
be done using the technique I'm showing you'd just have to model the
movement of the tool in 3 dimensions --- hopefully I'll learn enough
math to make that happen presently.
Generating the gcode in the general case is roughly equivalent to the
problem of generating gcode for a 3D printer - what a slicer does.
There's an awful lot of calculation there.
The toolchain should be able to do something useful with a half-sphere:
intersection() {
sphere(20);
translate([-100,-100,0]) cube([200,200,200]);
}
And maybe that demonstrates my naïvety; tool head geometry might
preclude doing that because unless the bit is more than 20mm long the
tool head might hit the sphere getting to the edges.
It should be possible to do a ball-nosed endmill traveling over the
surface of the hemisphere to shape it, then have a square endmill do a
waterline path around the lower perimeter of it to cut that out.
I was thinking of the fact that the tool head - the thing that holds the
bit - is quite a bit larger than the bit itself, and on a near-vertical
surface with a bit that's shorter than the object being carved there's a
risk that the head will hit the piece.
And Rob Ward wrote:
Wouldn't this require a post OpenSCAD package that operates
on .STL files to drive a milling machine, somewhat of the complexity
of a slicer eg Cura for 3D printers?
No, please see my code from my previous messages --- basically rather
than modeling the shape, one models the stock and carves away from it
using tool-shaped geometry and one captures the tool movement as G-Code.
Another way to look at it is that you're specifying the tool path, and
building a parallel OpenSCAD model of the tool path.
That's an interesting way to look at it - totally upside-down from how I
normally think about modeling. Normally I think about the shape of the
object and the toolpath is largely the slicer's problem.
I will note that if one modeled a tool such as:
https://www.amazon.com/gp/product/B07XG6MTMH
or a ball cutter on a narrow shaft one could do undercuts.
The fact that tool head shape matters is part of what makes my head hurt
when I think about general CNC.