Is there a pre configured z offset in the firmware somewhere?

Marlin_V1CNC_Ramps_Dual_2.0.9.2_513-src’

I just noticed that on the parts I’m cutting out the Tabs I have set are .5mm from the top surface despite asking for full height tabs in EstlCAM.

This is the line that sets the z height for one of the tabs in the GCODE;
G00 X101.7603 Y9.9095 Z0.0000 F500
in reality that is actual -0.5

The g-code looks fine, so for some reason it thinks that Z=0 is 0.5mm below the top surface. I’m not an EstlCAM user, but often when I see issues like these come across the forum, the problem is in these settings (Setup/Basic Settings):

image

There are other possibilities including your spoil board plane not being parallel to your CNC plane, failure to zero the origin of the job, wrong compensation for a touch plate (assuming you are using one), uneven stock, and lost Z steps (loose grub screw or too high of a feed rate for Z somewhere in the g-code).

2 Likes

Setup Basic is same as your image;
the tabs are uniformly positioned around entire part and each has the same -0.5 top.

The Program start looks like this;
;Project Control Arm5
;Created by Estlcam version 11 build 11.242
;Machining time about 00:37:15 hours

M42 P5 S0 ;make sure spindle is off
G90 ; Absolute positioning, just in case
G0 X-20.0000 Y-20.0000 F3000
;G92 X0 Y0  Z0 ; Set Current position to 0, x/yz axes
G1 Z5 F500 ;Raise z axis 5mm
M0 Drill 1.5mm-Attach
M0 Position z-Probe
G28 Z ;auto home z axis
G92 Z0 ;Material is probe  (eg aluminium/metal) or
;G92 Z-0.5 F150 ;account for probe thickness
G1 Z5 F500 ; raise z axis to 5mm after homing
M17 ; engage steppers
M0 remove z-probe
M400
M300 S440 P100
M0 start spindle?10000
M0 Confirm?
M42 P5 S255 ;Turn spindle On
G90 ; Absolute positioning, just in case

Tool changes look like;
;Change tool: 1/8"Alum

G0 X-20.0000 Y-20.0000 F3000
M400
M300 S440 P100
M42 P5 S0 ;spindle off
G1 Z15 F500 ;Raise z axis by 15mm
M18 Z ; disable z stepper motor
M0 1/8"Alum Attach
M0 position z-probe
G28 Z ; Auto Home z axis
;G92 Z-0.5 ;acccount for thickness of z-probe
; and put bit on surface of workpiece
;disabled when doing aluminium as the aluminium
;surface is used as the touchplate
;G1 Z0 F150
G1 Z5 F500 ;Raise z axis by 5mm
M0 Remove probe
M0 Auto Start Spindle?17200
M0 Confirm?
M400
M300 S440 P100
M42 P5 S255 ;spindle on

I see nothing wrong in the active g-code. If you want to to attach the full g-code file in a post, I can look a bit more. You should be able to attach it directly to a post, though if you have an issue (like it complains of it being too big), you can put in a ZIP file and attach it.

FYI: There is an issue with the following inactive line in your g-code:

;G92 Z-0.5 F150 ;account for probe thickness

First, G92 sets the position. It is not a movement command, so you would want to set Z to a positive value representing the touch plate thickness. Second, since it is not a movement command, it does not have a F parameter. Assuming Marlin ignored the F parameter issue, the code as it is would result in your cutting being 1mm too high (.5 for the touch plate, and .5 for the G92).

Note the most likely cause I list in my previous post given your additional information is somewhere having a Z feedrate too high. The Z feedrate can be limited in the firmware using a M203 g-code. If you execute an M500 after the M203, the setting will be saved. In addition, in EstlCAM Setup/CNC Programs/Coordinates you set the max feedrate for rapid (G0) commands. If you haven’t already set this value, V1 recommends 480 for the Z feedrate limit.

Is the profile cut too deep, or is it just the tabs? What thickness of aluminum are you cutting?

Edit: Consider putting a G28 Z0 near the end of your g-code file to see if the bit is returning to the correct Z zero height.

Marlin does have a probe offset, it’s stored in the Eprom settings, you should be able to change it from the menu. This should be enabled in V1 firmware. Don’t forget to save to Eprom again. I think that the firmware default value is zero though.

G92 overrides all of this though. If you add a G92 Z0 to the code after the G28 Z line then this will override everything.

You can check on the LCD. After a G28 Z, the LCD will show you the current Z coordinate. If this is not 0 then this is the problem. If it is 0 then the problem is elsewhere. (You can use the touchplate to check this)

Rather than relying on the G92 command, it would probably be better to include adjusting the probe offset as a part of your material setup, if it means having to manually edit the Gcode file. I prefer not to have to do things like that.

@robertbu
Thanks for your insights
Zip file attached.Alu(5).zip (1.2 MB)
I have z feedrate limit in Estlcam set to 500.
The material is 2mm thick

I 'll see if I can get a measurement of how much it bites out of the waste-board when I get home from work tonight.

@SupraGuy
I did try to get into the config via the LCD to see what the offset was… I am looking the config/advanced/set offsets menu in the LCD. But when I click on it it just says ‘offsets set’.

I’ll have a look at all the other suggestions tonight. Thank you.

I looked through the g-code file, and did not find anything that would cause lost steps, nor anything where the Z height would be set wrong. Part of the troubleshooting is to decide whether the g-code is the root of the problem, or if your machine is losing steps. I’d lean towards lost steps at this point. There was one weirdness where the g-code would output something like:

G00 X303.8899 Y-0.0551 Z5.0000 F3000

So it appears like the g-code is pushing Z too fast, but each time I found one of these, I find on a previous line with something like:

G00 Z5.0000 F500

So, since the Z was already at the target height, Z was not being pushed too fast. I assume this is EstlCAM’s hackish way of handling a lower Z feedrate for rapids.

I did notice you boring to 3mm, and doing your contour cut to 2.25mm. This means you could be losing steps anywhere in the process since the lost steps would only show in the tabs. Other operations would just have deeper cuts into the spoil board, which probably wouldn’t be noticed. With this in mind, be sure you’ve checked the grub screws on the Z axis connector.

I have my drill holes set to 3mm deep to ensure I don’t end up will anything left over on the underside due to actually using a drill bit.

The 2.25mm depth seemed to be the depth I ended up at that would ensure the the cut was always all the way through. If I set at exactly 2mm I would occasionally end up with an ultra thin layer at the bottom or a ragged bottom edge. I had assumed this was probably being caused by the z home touch point being slightly thicker material…

Just another thought, are missed steps not more likely to happen when pushing through the material, so the tool would end up higher than expected?

I’ll check the grub screws again tonight.

Grub screws are good, I’m just waiting to take delivery of new laptop so will be able to do some live tests/experiments to see what’s going on in a couple of days.

Lost steps can occur for a variety of reasons. I was specifically looking for lost steps on the Z axis due to the feedrate being too high. As you increase the feedrate, you lose torque. It takes significantly more torque to lift the router than to allow it to descend, so typically steps are lost as the router rises. The result is the router being lower than expected.

Pushing against material can also lose steps as you suggest, but typically high feed rates are seen for rapids which are non-cutting moves.

I have my drill holes set to 3mm deep to ensure

Your reasons for using 3mm and 2.25mm are good ones and what I expected. I’ve done the same. My only point is that given the operations you are doing, it could/would hide having the router 0.5mm lower than expected for other cutting operations, so the issue might be happening anywhere in the file. If you were boring/cutting the exact depth of the material and barely scaring the spoilboard so that only the tabs were bad, then it would be a strong indication the problem is in the g-code and therefore likely an EstlCAM issue of some sort. Since that is not the setup, then the cause of the issue is very much open.

I’m stumped with your problem…at least without some additional information. At the end of your g-code file, you return the router to (0,0,0). Is the tip of the bit the same height as it was when you set it at the final bit change?

I didn’t finish setting up the new laptop til late so I didn’t get to do a great deal of testing.

I created a guide file with just the start and tool charge gcode with g0 x0 y0 z0 at the end of each.

I then re attached the original probe and ran it…the 0.5 was maintained so I can rule out some sort of default offset.

More testing this weekend.

Progress!!

I turned down the max z feed rate to 280, I also set the steppers to stay on at the end of the program. The job completed and the tabs were still not full height. Because the steppers were still engaged I was then able to measure the reduced Z0 position. It was tiny bit over 0.6mm.

I decided to go ahead and run it again since this issue is not actually ruining the job and I’m desperate to get get these things done. On starting the job I forgot to reattach the dust shoe, I couldn’t be bothered messing about to put it on after the job had started so I left it off… Lo and behold the tabs are now full height!!

I am struggling to explain why however, the bristles do offer up some resistance as they engage with the surface but eventual bend and give way. My logical mind tells me if steps are lost here then I’d end up with the z axis too high not too low.
or
Maybe it’s the vacuum hose at some point pushing down too hard causing steps to be missed on the upward movement.

What is truly bizarre is how every single tab is missing the same amount of height. The lost steps must happen right at the beginning and then not occur again

The higher the feedrate, the lower the torque. The more weight on the Z axis, the more torque required to lift the router. This is what I suspected was the problem in the beginning, but I never identified any lines of g-code in your file that would cause this problem. Things you can do:

  • It is recommended that your vacuum solution attach to the core and not the Z axis. That way the Z axis is not carrying the weight of the shoe and hose.
  • Limit the Z feedrate in the firmware using an M203 g-code. Note the values in this code are in mm/s not mm/min. If you use an M500 after executing the M203 g-code, the values will be persistent, so you only will need to run the command once rather than in the start of every job.
  • Increase the voltage to the stepper motors. Higher voltage will give you more torque when moving fast. The maximum voltage for the motors and the logic of a control board are often different and therefore must be powered separately. Look at the specs of your board.
  • Make sure your Z axis is well lubed and moving smoothly without any binding or resistance. Any resistance will lower the feedrate at which point you will begin to experience problems.
  • Look for any interference between the vacuum solution and the core. If the hose or shoe is at any point rubbing on the core, it will create resistance that will require more torque to overcome.