Upgrading LR3 to LR4 in Seattle

LowRider CNC Your Builds
41

I have interest in this because my probe script has been using G38.2.

According to https://snapmaker.github.io/Documentation/gcode/G038

  • G38.2 probes towards a target and stops on contact, signaling an error if it reaches the target position without triggering the Z endstop.
  • G38.3 probes towards a target and stops on contact. No error is given if it fails to trigger the Z endstop.

So it sounds like the “no error is given” is the only difference. If the error is triggering a drop that’s an issue.

However, I have gotten some errors with G38.2, but without any dropping. My errors were perhaps of a different nature (seem to be) as they were caused by when I started the probe while positioned too low. I instantly get an error saying I’m trying to probe out of bounds. I say “perhaps of a different nature” … as @coinbird 's error seems to have been “we reached the end of the probing distance and did not get trigger from material”

42

Interesting. I will try some more controlled tests to see what g38.3 vs g38.2 do exactly on my jackpot (with 3.8.1)
On a semi related note, I tried the Homing button on the Tablet v3 plugin, and X homing acted very weird, not stopping on the endstop trigger (Brrrrrrrrr goes the motor!). So I will just continue to use the main UI or pendant.

1 Like
43

I had a trigger failure yesterday probing Z and did not get a drop either. I have been doing a bit of testing with Jason’s code so I will look into this more.

1 Like
44

It’s possible it was a combination of things going on; I will be more scientific this time and report back…

45

You should let us know what you are doing exactly so we can prevent you from breaking tools anytime you have an error.

46

OK, here’s the results.

  • LR4 Jackpot + 3.9.1 [edit: typod the version #], v3 Web UI.
  • I believe @DougJoseph created these original scripts (thanks!) and they worked well for me on my LR3. I think the behavior was the same as reported here.

Repro Issue Test - SCARYProbe.g

  • Power up. Home Z, X, not Y because lazy.
  • Run script, SCARYProbe.g. Note that 75 mm is too short of a distance for me to reach my spoilboard. For the test, I am purposefully NOT hitting the touch plate.
G21 (MSG G21: Metric mode)
G90 (MSG G90: Switching to absolute positioning) 
G94 (MSG G94: Feed = per minute)
$HZ (MSG Home Z)
G38.2 G91 Z-75 F400 P0.50 (MSG G38.2: Fast probing to material)
G1 Z5 F400 (MSG G1 move Z up by 5mm, speed 400)
G38.2 G91 Z-6 F100 P0.50 (MSG G38.2: Slow probing to material. Plate thickness: 0.50)
G1 Z5 F900 (MSG G1: up by 5mm , speed 900)
G90 (MSG G90: Absolute positioning)
  • Behavior: Homes Z as per the script, moves down 75 mm and then Alarm kicks in, and the motors disengage/gantry drops. (First time, gantry didn’t seem to drop, but I was holding it up. Verified by running again, power cycling, and indeed it dropped on the first try.)
  • Partial log:
<Run|MPos:0.000,0.000,-62.845|FS:400,0|SD:47.46,/sd/macros/SCARYprobe.g>
<Run|MPos:0.000,0.000,-69.600|FS:400,0|SD:47.46,/sd/macros/SCARYprobe.g>
[MSG:INFO: ALARM: Probe Fail Contact]
ALARM:5
# (Motors disengage and gantry drops at this point)
<Idle|MPos:0.000,0.000,-75.000|FS:0,0|WCO:0.000,0.000,-96.000|SD:47.46,/sd/macros/SCARYprobe.g>
[PRB:0.000,0.000,0.000:0]

Second Test - LessSCARYProbe.g

  • Same code, but changed to G38.3
G21 (MSG G21: Metric mode)
G90 (MSG G90: Switching to absolute positioning) 
G94 (MSG G94: Feed = per minute)
$HZ (MSG Home Z)
G38.3 G91 Z-75 F400 P0.50 (MSG G38.3: Fast probing to material)
G1 Z5 F400 (MSG G1 move Z up by 5mm, speed 400)
G38.3 G91 Z-6 F100 P0.50 (MSG G38.3: Slow probing to material. Plate thickness: 0.50)
G1 Z5 F900 (MSG G1: up by 5mm , speed 900)
G90 (MSG G90: Absolute positioning)
  • Behavior - Script runs all the way through. Basically stops at Z-75, raises up 6 mm, re-probes for 5 mm, then raises up 5 mm to “finish.” Upside: no crashing, but downside is that no touchplate was detected without any “warnings.”
  • Partial log:
000,0.000,-42.930|FS:400,0|SD:47.46,/sd/macros/LessSCARYprobe.g>
<Run|MPos:0.000,0.000,-49.040|FS:400,0|WCO:0.000,0.000,-96.000|SD:47.46,/sd/macros/LessSCARYprobe.g>
<Run|MPos:0.000,0.000,-55.780|FS:400,0|SD:47.46,/sd/macros/LessSCARYprobe.g>
[PRB:0.000,0.000,-75.000:0]
[MSG:INFO: MSG,G1 move Z up by 5mm, speed 400]
[MSG:INFO: MSG,G38.3: Slow probing to material. Plate thickness: 0.50]
[PRB:0.000,0.000,-76.000:0]
[MSG:INFO: MSG,G1: up by 5mm , speed 900]
[MSG:INFO: MSG,G90: Absolute positioning]
<Idle|MPos:0.000,0.000,-71.000|FS:0,0>
<Idle|MPos:0.000,0.000,-71.000|FS:0,0>
47

I feel like not raising an error is just as bad. But can’t you just resolve this by changing Z-75 to Z-110 or some value that handles the increased Z of the LR4?

Also, I wouldn’t run any 3.8 version of FluidNC. Either drop to 3.7.17 or upgrade to 3.9.1 (which isn’t officially recommended yet).

48

Why did you put a g91 in the middle of a probe command?

49

I missed that entirely. 3.8.1 is not a working firmware. One of the 3.8’s has homing issues, might have probe issues as well.

Take a look at the suggest gcode here to get rid of that misplaced g91. Milling Basics - V1 Engineering Documentation

1 Like
50

Yes, this is easily remedied by increasing the value to something larger (Z-110.) Not blocking me or anything, just figured I’d document it. I wonder if there is a way to have it Alarm, but not turn off all the motors…

51

Don’t recall why the G91 is there, leftover copy and paste I guess. blame doug :wink: :wink: Also not the official guidance as linked, but I believe the G38.2 behavior acts the same. (The main “feature” of this code that I wanted was the 2-stage probing, where it moves down more quickly at first, then the second slower touch-off.)

Oh, shoot, I meant I am running 3.9.1, not 3.8.1! Understood that this is not yet the YBR build recommendation version, but hopefully soon.

1 Like
52

Your code probes twice and only moves up a little bit. If you are going to probe more than once you need to home Z in between each one. At the same time twice does nothing for you only the most recent one counts.

53

The idea was that the initial “fast” moving probe would be potentially less accurate than the second “slow” probe, so the intention was to throw out the first value. Moving ~100+ mm at the “slow” rate takes a long time, thus the two-stage approach (quickly get in close, then take the “real” measurement more carefully)

54

A fast probe is just going to chip a tool and damage your probe. I doubt two probes is faster than one slow one.

If you want to do that you
Home Z
Move down ~80mm fast
Probe the rest slowly.
pull off the probe.

This is exactly how we do it with an upcoming probing script.

55

That makes sense. For this method, the first F400 rate I’m using doesn’t seem actually fast enough to damage the tool, but just jogging closer to the workpiece, and then a slow probe would make sense too. Hardcoding an initial 80mm fast move down instead of a probe would be a problem when I use thick material and forget to change the script.

Out of curiosity I will do a little experimentation with the touch plate on a piece of foam to see if there’s significant difference in Z values between probing at F400 and F100.

I am not blocked by this Alarm->gantry-drop behavior (multiple workarounds,) but thank you all for taking a look at what I was describing!

At the end of the day I’ll try to just use the built-in probe feature in the WebUI and/or the Pendant, so this is probably mostly educational at this point. I do see that the WebUI has a drop-down to choose G38.2, G38.3, and the other probe styles.

56

There is jut no reason not to just move down instead of probe, it is actually less code and far less chance of any damge.

fluidNC doe not stop instantly, so the faster you move the further it overshoots a probe. not good.

1 Like
57

$HZ (MSG Home Z)
G0 Z-80 F600
G38.2 Z-110 F100 P0.50 (MSG G38.2: Slow probing to material. Plate thickness: 0.50)
G1 Z5 F600 (MSG G1: up by 5mm , speed 600)

1 Like
58

I see, that would work. I would have to be careful to change that Z-80 value if I switch to thicker material.
I will also play with the pendant and the webUI’s probe interfaces. I could see a workflow where I just jog to an appropriate location, get it close, then hit probe, and it probes those last few mm, instead of just automatically re-homing Z every time.

59

Exactly why my recommended starting and tool change code does not try to save one second with a faster move.

You are just introducing things you need to remember while changing tools and moving around. You will forget eventually.

Again at best what will you save 1 second? How long will it take you to push teh buttons in the webui??

60

I would invest all this gcode testing with actual cut testing. You can save hours with more efficient CAM.