Figured out why those feedrates are being ignored. They need to be G1 instead of G0. Still learning.
3 Likes
Interesting, I thought the max was a fallback if it was not specified. Dang this stuff is never as simple as it seems. Good find!
Since I was reminded of this, I looked at this a bit. The Z rapid move did crash into the spoilboard on my LR3. Depending on how far my endmill is sticking out, I’m looking in the 60s before it hits the spoilboard. So, even 80% of 80 is cutting it close.
Mine was very close… maybe 5mm before the probe hit that it slowed down.
This was LR4 at -110.
A little more wiggle room might be worth it
Ok… I just ran it.
So here’s my feedback if you want it.
(Ignore it if you don’t 
)
What I changed before running it
(started with @vicious1 version above)
- At the beginning of the script, it homes all. I changed it to Home Z, then X only. I wanted to choose the better spot on my spoilboard, but didn’t want to have to measure to get it right.
- Updated all the G0 to G1
- Before moving to the right probe position, there was an additional
$HX. That seemed unnecessary to me since we just Homed X at the beginning before probing. Removed it.
What I didn’t like
-
The Z Home between each probe I didn’t like. My probe wire is not long enough to stay on the table at the home position. this meant I had to lift up my probe, and place it again between each one. For the tiny touch plate, this means I can’t tape it down flat, and can’t even hold it steady between probes, potentially increasing the possibility for error.
-
For me, this felt like it was much better as an extension that could offer better controls. For a lot of us that operate off of a tablet or iPad, if one of the values is wrong, it’s not easy to update a gcode file from there. If my X offset was wrong, or some other parameter, that’s a lot of trips back and forth to get things just right.
-
My first probe failed to register and kept driving into the table. I knew my average was going to be bad, so I attempted to cancel out of it. Since it’s running in gcode, there was multiple immediate popups happening that made it so I couldn’t cancel out without hitting the X on all of them. I can’t remember the exact sequence of buttons I pressed, but I was attempting to issue a hold command, then a soft reset, but was met with many successive dialogs.
-
Maybe back to this being better as an extension… At the end I just get a resume button with the text “Continue to update pulloff values”. I have no way to check that these values look reasonable or not before writing them, and no way to stop them from being written.
I think my total correction ended up at 0.441mm. So overall I think it was probably pretty close, and relatively easy to use, but it’s tricky enough that I probably wouldn’t suggest it yet for a new person.
for xTotalDistance, I’m also wondering if Rail Length + (2 * XZ Plate Thickness) is not a better recommended measurement that is consistent for both the LR3 and LR4. Maybe I need to look closer, but it seems that would be the actual length between pullof points for Z (I guess measuring from the outside of the XZ plates across is the easier way to say that)
1 Like
I appreciate the feedback.
I performed some of the same initial changes.
Ryan added that so that it would be including the home in the averaging as well. I’m not sure if that is necessary. It already does the fast then slow thing automatically and I recall another thread talking about how accurate those switches already are.
I agree with that. One advantage of it as gcode is that it works on WebUI v2 as well. This started as a hey cool look what we can do with gcode thing. I think that an extension could leverage some of this gcode.
I forgot I actually wrote an extension for this, if I can remember where I put it…
I just did a soft reset followed by clearing the alarm.
Maybe. I have a hard time wrapping my head around that number sometimes.
1 Like
I have an old copy if you need it.
Definitely was a cool learning exercise to see what could be done, and also useful in general.
II guess center of leadscrew to center of leadscrew is probably more accurate, but I’m guessing they are all probably “close enough” for what it is…
Was just thinking it would be good to have a reference that is consistent between LR3 and LR4
1 Like
I found it but it doesn’t quite work right. Maybe some WebUI changes broke things. I also think this was the first extension I wrote and I’ve learned a few things since then.
This has some issues.
zlevel.html.gz.zip (6.0 KB)
The one I had definitely had the same G91 and G0 issues at least.
For these movements in an extension, it might make more sense to use the Jog command so you can specify G90 vs G91 directly in each command without affecting any other state.
Also, since you don’t know what the user has done between button presses, no assumptions have to be made about the current G90 vs G91 state.
Although, technically you can query for this if you need…
The layout at least looks right, but I haven’t tried to use it in a while
I feel like that makes logical sense, but didn’t work out in practice, at least on the LR3. Maybe the math isn’t accounting for it correctly. It may need to consider the distance between the left leadscrew and the min X position, and the right leadscrew and the max X position.
Yea, in the extension, the movements were off in my quick test. At least if I set that Left X position greater than 0, I was crashing into X max. It also wasn’t saving/loading those config values, which worked at one time.
I’m accumulating too many projects that don’t involve making chips. 
1 Like
Story of my life…
3 Likes
Just stumbled upon this thread, any updates or is this idea pretty dead now?
Well, when I have time, I have a tendency to focus on whatever the shiniest thing is at that moment.
I have intentions of upgrading my LR3 this fall/winter and will likely revisit it then.
3 Likes
Lol, you must be the brother i never knew i had! My shiny new thing is trying grblhal!
4 Likes