I’m looking into kiri:moto for some through cut CAM work. In general, it is awesome . I’m not sure I have quite enough capability to configure it the way I need to for the MPCNC/Low Rider.
I noticed that the first plunge (in the gcode I generated) doesn’t have the plunge rate set right:
; camFastFeed = 2001
; finishingSpeed = 802
; finishingPlunge = 253
G21 ; set units to MM (required)
G90 ; absolute position mode (required)
; starting finishing
M6 T2 ; change tool to 'end 1/8'
G0 Z20.05 F2001 ; Too fast for Z
G0 X489.9449 Y52.0166 ; Z feedrates would be too slow
G1 Z16.129 F802 ; Uh oh! Wrong feedrate here, this should be the plunge.
G1 X489.9849 Y51.6522 ; No feedrate set here.
G1 X490.0406 Y51.2896
The G0 feedrate isn’t broken down into Z and XY. The firmware should limit this, but a lot of users don’t have this well configured, and we’ve had trouble in the past (a long time ago) with Marlin actually ignoring the max Z feedrate. The MPCNC (and many CNCs) have different speed capabilities in Z vs. XY. This is probably a minor issue.
If there is only one tool used, do we need the initial tool change (M6)? It would be nice to have a well defined tool change script as the default, and Marlin has some good gcode features we could use, like M117, G28X, etc. But most people (at least those who are starting) aren’t going to use two tools in one job. In those cases, a tool change script can be a hassle (they may not have an LCD attached, for example).
I am working on the side of a piece of furniture. It has to be cut out, and it needs some joinery cut out as pockets. I love that it just accepts the .STL from my CAD, instead of using a .DXF. But I can’t seem to find the right settings to just cut out the inside hole (which is all the way through the .STL), but do create pockets on the holes that don’t go all the way through.
I don’t want to sound like it’s all wrong. So much of this is excellent, and I really want it to work. As a Linux user, it seems like a great component in my workflow. And as a fan of V1, I would love for it to be documented as a good way to get started with CAM.
@scrounge79, I know you’ve been using this too. If you have any tips, please share.
this is wrong and i’ll look into reproducing and fixing. the screenshot is missing all your settings. Setup -> Export and email me the .b64 file (sa@grid.space).
each operation (rouging / finishing) has a separate plunge rate. that should be used for z only operations. will look into this.
if you clone / edit a device, you can override the default tool change script.
select “pocket only” and it will do what you want. i still need to optimize through pockets when roughing is selected. a known problem especially with the part you are showing. it’s on my short list to fix once i get some other work out of the way.
After #1 is fixed, the plunge on the finishing looks fine. But when traveling (camFastSpeed), there doesn’t appear to be a separate Z setting. This means the G0 commands are moving either too quick for Z, or too slow for XY.
Changing the script is no problem.
What I was asking for is: I am assuming you have a loop something like this:
for (toolpath : toolpaths)
{
changeToTool(toolpath.tool)
toolpath.writeOutToolpath()
}
But in the case of only one tool, we don’t need a toolpath script. I suppose I could just delete the tool change script completely if I only have one tool to do (like I do this weekend). But what I was thinking was something more like this:
for (toolpath : toolpaths)
{
if (toolpaths.length > 1)
{
changeToTool(toolpath.tool)
}
toolpath.writeOutToolpath()
}
Maybe that pseudocode makes no sense to you, IDK… It may also go against the vision of kiri:moto. It may be a bit of a surprise to not do a tool change if there is only one tool.
I will play around with it a bit more. I can’t seem to get it to make a pocket for the small pockets, and also not make a pocket in the giant middle hole. “pocket only” in the finishing seems to only turn off the outside edge cutting. “pocket only” in the roughing will pocket the smaller joinery, but also pockets the huge pocket in the middle. It seems like it needs to understand that the giant hole in the middle is completely through all the Z, and it shouldn’t need to turn that piece into sawdust.
I’m not in a hurry, and I’d like to promise to look at the code myself, but I am pretty sure that would be an empty promise, since I am so busy with my other projects, ATM. But I am pretty good with a keyboard, so if you’d like to me try a branch or something, I can probably figure that out.
Thanks for pointing this out. I hadn’t had issues but haven’t used it a whole lot since I got it all set up. I have been so busy working out all the technical details of our live-streamed services I haven’t done much CNC. I have been 3D printing camera mounts though! I think I have finally gotten all the hardware and cabling set to have a good stream so now I can relax and get some CNC work done. I’ll check this out.
@jeffeb3 I’ll fix this one way or another this week. the initial tool change is intentional even when there is one tool. I use it to know the job has started properly. my sender will pause on a tool change and wait for me to acknowledge it. some senders will just ignore it if they don’t support tool changes.
making roughing aware of through pockets is on my todo list. hopefully i’ll get it sorted this week, as well.
@jeffeb3 pushed an update to Kiri just now (2.0.5) that has a new option under roughing “pocket clear” which is on by default to retain backward compatibility. uncheck that and through pockets will be cut out instead of cleared.
Very cool! It works great. Thank you! I was poking through your issues, and it looks like this has been bothering you for a while, so thank you for finding the time to work on it this week. The fact that this is javascript in the browser makes it so easy for me to “update”. I am really liking this workflow.
Regarding #2 above, What do you think about a “rapid feed” for Z and XY in the common settings?
On my list for this coming week. Regarding workflow, I spent the last week laying the groundwork to run multiple versions of Kiri in parallel. This would allow you to choose, for example, between production, testing, and bleeding edge features.
IDK if you know, but I run sandify. I have been thinking I’d like a way to do that myself. I’m hosted on github. My github actions deploy from master when I make a release. I am wondering if there is a way to npm build to a url like sandify.org/testing on any merge commit to master, and then npm build to sandify.org when I make a new release. It is something I’ve considered. I could probably also just do a different cname, like testing.sandify.org, forwarding to a different host.
@jeffeb3 cool project. I have my own back-end app server and thus more flexibility (and work). A slightly unusual requirement for me is to serve different files on the same host/url to different people based on a setting. It’s an odd requirement because of Onshape integration.
Took at look at this and the rapid Z moves are happening when the tool is being lifted, not during cutting moves. I will add another setting to cap this speed.
I like this new UI. I think it helps to not overwhelm the user with options all at once. I had a little trouble finding the back button in the upper left when I was in the preview, and my mill options were gone, but it took me 4 seconds to find it.
Looking at the gcode output. I set my max Z travel to 300, and my Z plunge to 250. Here’s the starting gcode:
G1 Z1.0 F300 ; Good. This is my Z rate I set.
G1 X48.4007 Y79.0481 F1000 ; Good. This is my XY travel rate that I set
G0 X0.0 Y0.0 ; We probably don't need to drive back to 0,0?
G0 X48.4007 Y79.0481
G1 Z-3.8119 F300 ; This is the first cut. This is a plunge, it should be 250 here.
G1 X48.1065 Y79.2446 F480 ; Good. This is the feedrate I set for this operation
G1 X47.8221 Y79.4531
And here it is pluging a little deeper later:
G1 X47.6287 Y79.2012
G1 X47.9244 Y78.9844
G1 X48.2302 Y78.7803
G0 X48.4007 Y79.0481 F1000 ; We didn't lift the bit. We are still in the material here.
; This F1000 is too fast, and on grbl, the G0 would mean it would go max speed.
G1 Z-6.669 F250 ; Good here, This is a plunge at the right speed.
G1 X48.1065 Y79.2446 F480 ; Good here, we set the speed to cutting speed again.
G1 X47.8221 Y79.4531
G1 X47.5471 Y79.674
G1 X47.2815 Y79.9069
Here, we are traveling up, and over to a new part:
G1 X47.9244 Y78.9844
G1 X48.2302 Y78.7803
G0 Z1.0 F300 ; Good. travel Z speed to raise the bit
G0 X26.9875 Y93.6625 F1000 ; Good, travel XY speed to move to the new spot
G1 Z-3.8119 F300 ; This is a plunge, this should be F250
G1 Y138.1125 F480 ; Good. Cutting speed again.
G1 X23.8125
G1 Y93.6625
The first section was on the first cut. The later parts were each time it transitioned between parts to cut. I didn’t see a way to export my b64 file with this interface. Here is the gcode, if you like:
. I’m not sure I have quite enough capability to configure it the way I need to for the MPCNC/Low Rider.
