I use this same method on 1” XPS foam (well, on any material I cut) and all work as expected except the 2” XPS foam. Stock measured 49.6mm. I entered 49.6mm into estlcam with my 2” XPS foam bit selected. it drove the Z to 56mm, which is now a good bit into my MDF spoilboard and needless to say derailed the gantry at the feed rate for the foam….. the immediate fix was to subtract the difference and re-output the Gcode. BUT why is this happening? my guess would be in the bit settings, but they seem right to me…. (at $53/sheet for 2” XPS, I want to eliminate the guesswork….
Are you zeroing Z with a probe on the top of the foam? If your zero is on top of the foam it shouldn’t be going down anymore than what you set your cut depth to. Can you upload your gcode file?
I run a 3-axis probing gcode then load my project gcode. ill upload the probing code (same i use on all other stock)
;Z-Probing: M3 (MSG Z-Probing)
G38.2 G91 Z-30 F200 ;Fast Z-Probing
G0 Z3 F5000 ;Lift Z again to 3mm
G38.2 G91 Z-10 F50 ;Slow Z-Probing
G92 Z1.8 X0 Y0 ;Reset Coordinates but with probe Thickness for Z
G90 ;back to absolute coordinates
G0 Z20 F5000 ;Lift Z to 20mm Axis
;X-Probing: M3 (MSG X-Probing)
G0 X-40 F5000 ;Move X 40mm
G0 Z-1.5 F200 ;Lower Z Again
G38.2 G91 X40 F200 ;Fast X-Probing
G0 X-3 F5000 ;Move X for slow probing
G38.2 G91 X10 F50 ;Slow X-Probing
G92 X-4.175 ;Reset X Coordinate (Tool Radius + Probe X side Thickness)
G90 ;Absolute coordinates
G0 X-15 F5000 ;Move X for clearance
G0 Z20 F5000 ;Lift Z to 15mm Axis
G0 X15 F5000 ;Move X Back for Y Probing ;
Y-Probing: M3 (MSG Y-Probing)
G0 Y-40 F5000 ;Move Y 30mm
G0 Z-1.5 F200 ;Lower Z Again
G38.2 G91 Y40 F200 ;Fast Y-Probing
G0 Y-3 ;Move Y for slow probing
G38.2 G91 Y10 F50 ;Slow Y-Probing
G92 Y-4.175 ;Reset Y Coordinate (Tool Radius + Y Probe side Thickness)
G90 ;Absolute coordinates
G0 Y-15 F5000 ;Move Y for clearance
G0 Z20 F5000 ;Lift Z to 15mm Axis
G0 X0 Y0 Z10 F5000 ;Move to 10mm above origin
You could try a slower feedrate in case that’s leading to skipped steps.
You should set the offset with a P parameter on the G38.2 command. When it hits the probe, it starts to decelerate so it actually moves a bit past the probe height.
That is a CRAZY fast speed for the Z axis (83.3 mm/s). Almost guaranteed that you are skipping steps on the upward movement. Any time you move your Z axis, slow it down. Even your plunge rates in EstlCAM seem pretty high.
all valid points and suggestions, however, if it was an issue of missed steps or too fast of a speed, it would effect any material Z height, not just the 2” stock. That code is only for the 3 axis probing ….
is there something in Estlcam that would cause the bit to over drive?
also as a precaution, what would you both recommend as safe numbers for the probing gcode. i took that from another member and just changed the bit diameters and thickness of the corner bracket that I’m using as my touch plate.
I’ve had skipped steps when lifting Z from thick material (3/4" plywood) before that didn’t happen at shallower DOC. It seems (maybe) that the drag of the bit against the stock adds some additional load. Slowing down the Z feedrate helped with that for me.
Not likely, but your picture doesn’t show what total DOC you are specifying (shows “Ask”), so maybe you specified the wrong DOC for that particular toolpath?
The actual probing feedrates (F200 for fast, F50 for slow) seem pretty reasonable. It is the upward feedrate of F5000 that is way too fast. I would suggest using F200 as a reasonable lift rate to start, maybe try increasing it slowly to see if you have any issues. Others may be able to chime in with their opinions.
Not true. The motion controller has to manage acceleration not just feed rate. For short moves, you spend very little time at the sustained feed rate. For longer moves, you’re likely to be sitting at the commanded rate.
understood, but the gcode above is only for the probing to home the 3 axis. the jobs have there own gcode.
the issue happens as soon as the z axis lowers to run the job. it overdrives in z before it has made any other moves. when I changed (cheated) the thickness of the stock (49.6mm) to remove the 6.4mm that was overdriven into the spoilboard, everything cut fine. I just can’t figure out why that is happening? and only on the large stock. everything else is 25mm or under….
Having cut about 20 sheets of xps foam in the last year or 2, i have little if any trust that the foam dimensions of XPS from a big box store made for insulation is better than 5 mm (+/- 2.5) for flatness across the surface of a 4x8 sheet. Some of it is bowed more than that and doesnt lay flat. It is very frustrating for carving when probing it on the corner and the corner is the thinnest section or thickest section… Still, 6 mm is a lot to be off.
I’d be inclined to say it could be acceleration related more than speed. I turned the lr4 acceleration down to 200 mm/s^2 where my printers run in the thousands (when they are working) but the mass moving is so much different.
The two are definitely interrelated. If you increase the feedrate too much, you need to reduce the acceleration setting to prevent skipping steps. It is a bit of a balancing act, for sure. Better to just keep the feedrate to within reasonable bounds (F5000 for Z is highly unreasonable IMO)
you do understand this is code used solely for homing the 3 axis before i run a job. right?
Funny thing is I cut a ton of 2 inch foam last spring for Cinderella and had “0” issues. the only thing that has changed is an older (shop) laptop and Estlcam has updated a bunch of times…none of which should give this problem. again to reiterate, I get the stock thickness with my caliper, i enter it into estlcam (i always have estlcam ask for the total cut-through stock thickness because it ALWAYS varies.) it generates the gcode. I copy it to the micro SD card and then run the job. (It has already run the homing gcode) as soon as the z axis drops, it goes deeper than my settings….
I think we all do, there’s a different something going on with your specific issue.
That said, F5000 for Z is in fact unreasonable for a LR4 or frankly any machine with a lead screw / stepper Z. I’m surprised you weren’t having issues with this all along with other jobs.
Back to your issue, when you have fully homed your machine with the problem job, what does FluidNC report for all of the machine coordinates just before you run it?
Have you tried re-ordering your probing sequence to do Z last?
Probably there is a maximum Z speed set into the config that will override the Z speed set here. Commanded speed is the greater of the F factor of the command and the machine speed limit set in the configuration. Either that, or the acceleration settings on Z won’t allow it to actually reach a problematic speed.
That said, I designed/built a 3D printer where X and Y are leadscrew driven, and it reaches print speeds over 6000mm/s with accelerations allowing it to actually reach those speeds. At the time I was unhappy with my belt driven printer and (incorrectly) blamed the belts for some of the artifacts and inaccuracies that were evident. The leadscrew kinematics did produce improvements in accuracy, and the print speed was satisfactory, so the experiment wasn’t a bust. So leadscrews can go that fast, though probably not a great idea for the kinds of loads that an LR is under.
Sure, pushing around a lightweight 3D printer gantry.
Exactly. The LR beam isn’t low-mass either.
Another rabbit hole for me to explore.
Edit: good find, Dan. It’s right there in the LR4 default config file. This explains a bit more. F5000 isn’t ever being used in motion. For the default config.yaml, a LR4 Z axis won’t go above 1800mm/min, and it won’t accelerate more than 80mm/s per second. it would take a full minute of motion to get up to that speed!
So, starting at zero motion, even with a F5000 command, the first second wlll not move the Z axis above 80mm/s. In the next second, it won’t move the axis above 160mm/s. The Z move will be pretty much over at that point going from Z min to Z max. I’m not sure anyone could ever get the axis moving too much above that. Remember that after halfway through the move it will be decelerating.
Exactly, any thoughts on what in estlcam could cause what I’m experiencing? I’m leaning on it being something there since that is where I’m an endmill and setting a depth ….thats were the gcode is created. Plus if the homing code had issues it would manifest randomly and I would see if the homed position was off before loading and running the actual job….
I will have to grab a snap shot of what the the homing numbers are… perhaps I do it with the 62mm and a 32mm but to confirm the numbers are the same….
