First Travel not raising and cutting into stock

Mostly Printed 3D Printer - MP3DP Troubleshooting
1

I am using kiri:moto for toolpaths and repetier for cutting. The origin is at the top left. The mesh is centered at the bottom (not the top) of the stock (issue?). I set bit to desired bottom left and zero G92 X0 Y0 Z0. When I hit run, the bit does not raise, it just eases down as it travels to the first cut and cuts into the stock.

PXL_20231203_185652850
PXL_20231203_1856528501920×1080 192 KB
notice those diagonal lines as the first travel cuts into the top. It seems to get deeper as it travels and is maybe 0.5mm deep total. But enough to ruin the piece. Also note that follow up cuts are not an issue, I guess they are honoring the travel height but the first cut doesnt seem to be.

I tried changing the Z travel height to 4 mm (plenty) and turning off ease into cuts. I made sure I was running the zero g92. I turned off “tool init” as I have the 1 needed bit already loaded. Nothing i’ve tried seems to change it. WHich makes me wonder if it is perhaps a setting in repetier-host instead of kiri. I ran into this a while back but I am wracking my brain trying to remember the solution. I am gonna go try orienting the stock to the top but don’t have hope as the stock is supposed to be the same height as the workpiece.

ideas?

2

I have not used kiri but do know it is documented here. Kiri:Moto Basics - V1 Engineering Documentation

It looks like zero did not set correctly. How did you set it? With a touchplate? Or manually?

3

I set it with a script using
; set current location as origin
G92 X0 Y0 Z0 I actually have it in the start code and in script 1 in repetier which I click script1 manually

Set Position | Marlin Firmware so 92.1 is the same thing?

edit: adding log details, looks like it ran it 3 times . Hmm

16:36:43.906 : N123 M105*39
16:36:45.183 : N124 G92 X0 Y0 Z0*94
16:36:45.191 : X:0.00 Y:0.00 Z:0.00 Count X:-8000 Y:-12500 Z:4760
16:36:46.907 : N125 M105*33
16:36:47.358 : N126 G1 Z-10 F240*43
16:36:48.807 : N127 G1 Z-20 F240*41
16:36:49.908 : N128 M105*44
16:36:52.909 : N129 M105*45
16:36:53.136 : N130 G1 Z-30 F240*46
16:36:55.910 : N131 M105*36
16:36:57.543 : N132 G92 X0 Y0 Z0*89
16:36:57.553 : X:0.00 Y:0.00 Z:0.00 Count X:-8000 Y:-12500 Z:-7240
16:36:58.911 : N133 M105*38
16:37:01.913 : N134 M105*33
16:37:04.913 : N135 M105*32
16:37:07.914 : N136 M105*35
16:37:10.915 : N137 M105*34
16:37:12.570 : N138 G92 X0 Y0 Z0*83
16:37:12.571 : N139 G21*17
16:37:12.571 : N140 G90*21
16:37:12.571 : N141 G0 X70.5704 Y41.8437 F6000*64
16:37:12.571 : N142 G0 Z3 F300*50
16:37:12.577 : X:0.00 Y:0.00 Z:0.00 Count X:-8000 Y:-12500 Z:-7240
16:37:12.578 : N143 G1 X70.5744 Y41.8429 Z2.998 F250*39
16:37:12.582 : N144 G1 X70.918 Y41.8044 Z2.8251*122
16:37:12.585 : N145 G1 X71.1783 Y41.7897 Z2.6948*67
16:37:12.585 : N146 G1 X71.5627 Y41.7828 Z2.5025*78
4

In an attempt to not carry over any settings, I started with the defaults on kiri and reset it up again using the docs linked. I used the new dev kiri instead. I freshly loaded the settings. I reloaded the mesh again. I redid all the toolpaths. I changed the order to cut the closer pocket. Less travel to the first cut. Exported the gcode.

I zeroed the machine on the Rambo 1.4 LCD “reset all coordinates”. I connected to Repetier host. I ran the script 1 to set the positions.

It still dives at about the same rate (the depth at the same distance is the same as before).

So I tried to understand the g-code. Still new and trying to understand it…

G21 ; set units to MM (required)
G90 ; absolute position mode (required)
; starting trace op
M6 T2 ; change tool to 'end 1/8'
G0 X15.4984 Y14.8247 F6000
G0 Z3.0 F300
G1 X16.0841 Y14.2643 Z2.5947 F200
G1 X16.6933 Y13.7295 Z2.1894

it looks like the Z3.0 is after the first move. Should it be before?
There is no Z in the first move so it should not be dropping Z anyway AFAICT.

5

Yeah i think someone else needs to help you. That rise should definitely be first, but even not it should not go into the wood like that. It should skim over.

What is the status. Have you had success before with this machine and kiri? Is this the first carve? Have you done the test crown? Just to verify things! Does your z go the correct directions?

6

I don’t have any idea about a real solution, but I was wondering about a hack. Since it appears that you set the origin outside of your job, what happens if, after setting the origin, you move the router 20mm above the stock before starting your job?

7

I probably wont be able to get out to the shop until tonight (if then) to test further.

When you say “job” do you mean the part/mesh/object? Because I have the origin defined at the top of the stock which is somewhat standard I thought? Wondering if you are seeing something I am missing. What I do know is that when I set the height about 0.2 higher it did not scratch the surface as it was high enough to account for the drop.

I guess I wonder if you have an expectation here and what you might derive from it? I don’t see anything in the g-code to lower the Z so I would expect it to cut in the air. Since that first drop is so minor I wouldn’t expect to be able to see much. But its still an interesting test. Wait how would I even accomplish said move safely without generating power to the board? Maybe disable steppers in the LCD? If I turn off power it will reset the home on the Rambo so do not want that I dont think.

A few thoughts that I am unsure if they tell us anything but I do not think they do. The first travel “drops” as it moves but once cutting it seems to do fine. It goes from letter to letter without incident. Though I only see 3 of the G0 Z3.0 (3mm clerance) in the entire file which surprised me. I guess that is maybe “between operations” (I do not know what to call the tasks at the bottom of Kiri:moto). I do see a Z on many of the G0/G1 (cuts?) though. I even see some raise to G0 Z8 which is odd and I do not know why. But probably irrelevant. Still trying to learn.

I probably need to come up with a manual move test to see if the Z is dropping on its own. Perhaps the clearance has just been high enough to not notice. Though I’ve had it at 1mm and I wold thing I would have seen that.
I have other jobs which I set the same way and it doesn’t do this. They traveled fine. Even recently. Though as always the devil is in the details when troubleshooting I will need to run one of them again. I suppose it could have just started slipping at this job. But that I had this same exact issue earlier this year and fixed it by changing a settings of some kind leans me towards this being a software issue. Also I think I was using estlcam then. Which confuses me even more since it sounds like maybe the g-code generated is wrong and that Z raise should be moved up 1 line. If that is the case changing from ESTLCAM to Kiri should not have migrated this issue. So some sort of multiverse confusion going on that or “There be gremlins!”

8

After reading your first post, I assumed this was a kiri:moto issue where it was not moving to clearance height before taking the first plunge. I’ve never used kiri:moto, but my suggested hack was to start the router high, so it would need to descend to the first plunge. After reading your last post, I’m less certain that this is a kiri:moto issue. As a start, could you upload the g-code file that had this problem? A file with a .gcode extension is one of the file types that can be uploaded without putting the file in a ZIP file.

Since you mentioned Estlcm, I’m not an Estlcam user, but if this was Estlcam, I might suggest looking at this setting:
image
Another thing I might suggest is looking at the feedrate for rapids. If rapid movement is too high, you will lose steps on downward Z movements.

9

Thanks all for the help. I did a bunch of testing tonight and here are the results.

Summary
* changing the gcode to move the Z raise step up 1 line (before xy move) fixed it
* doing a very similar svg (My first draft) in ESTLCAM properly put a Z raise in the generated g-code BEFORE the first move.
* seems a lot of evidence to suggest a kiri:moto issue.

At least I have some idea what I can do now (change the g-code or use estlcam). I can reach out to the Kiri moto dev (again).

THE WEEDS

recreated again.
new "CNC printer (setup same as v1 docs)
lowered travel speed to 2100 (as stated in v1 setup docs)
everything to v1 specs this time.
updated repetier version v2.3.2
cuts the same with new file
Rambo 1.4 > v1 custom menu>reset all coordinates
both LCD and Repetier change to zeroes on all axis
script G92 X0 Y0 Z0,
still zeros
Repetier doesnt show the first travel either.
how does it know which to label as travel?
try again raising 20mm Z
left zero on top of workpiece
used repetier-host manual control to raise to 20mm above zero
cuts into air

try changing the g-code to move the raise Z up
Hmm will I also need a drop Z?

BEFORE

; --- tools ---
; tool=[object Object] flute=undefined len=undefined metric=undefined
G21 ; set units to MM (required)
G90 ; absolute position mode (required)
; starting trace op
M6 T2 ; change tool to 'end 1/8'
G0 X70.5704 Y41.8437 F2100
G0 Z2.0 F480
G1 X70.5744 Y41.8429 Z1.9980 F250
G1 X70.9180 Y41.8044 Z1.8251
G1 X71.1783 Y41.7897 Z1.6948

AFTER

; --- tools ---
; tool=[object Object] flute=undefined len=undefined metric=undefined
G21 ; set units to MM (required)
G90 ; absolute position mode (required)
; starting trace op
M6 T2 ; change tool to 'end 1/8'
G0 Z2.0 F480
G0 X70.5704 Y41.8437 F2100
G1 X70.5744 Y41.8429 Z1.9980 F250
G1 X70.9180 Y41.8044 Z1.8251

Setting up to run this I noted if Z is particularly high my dust shoe hits the bolts and might rack the Z. I can maybe sand this down but I think it is too high to be of consequence.

I also notice that when I try to do F0 X0 Y0 Z0 to return to the zero that the Z is up in the air now. Not sure why?? I will reset.
this time I ran the Script 1: g0 X0 Y0 Z0 instead of the LCD and confirmed the script worked to reset all to zero. (the bit was at the top of the workpiece in a new fresh position so I can evaluate cut).

load modified file, which I expect to cut 2mm (Clearance distance) in the air.
Interesting, it worked as desired not as expected. It raised then moved then dropped and cut. And the resulting depth of the lettring is the SAME as the previosu cut. So somehow the drop was accurate without change. I guess the G1 moves specify absolute positioning as per setup so it worked. Very cool. I still do not know why it is "out of order but hey.

I opened a slighlty different file I had as SVG (different font and not 3D) I pathed it up in ESTLCAM and saved the gcode.

The gcode

; set current location as Origin
G92 X0 Y0 Z0

G90
M03 S24000
G00 Z2.0000


;No. 1: Hole 22
G00 X15.3616 Y15.4841
G00 Z0.5000
G01 Z0.0000 F180 S24000
G01 Z-1.0000
G01 X327.9065 F900
G01 X328.8952 Y16.6766

okay when it ran it raised up automatically for travel. Notice the initial G00 Z2.0

so it looks like something in the Kiri:moto output is putting the Z raise in the wrong spot.

the_millers_file-002.gcode (113.2 KB)
The above g-code is the not raizing the Z before the move

TheMillers_as_paths_for_estlcam.gcode (151.0 KB)
This second gcode file is the once from estlcam which worked raising the Z before the move.