Regarding the pendant button causing a zero of axis that survives a reboot, I can certainly understand that seems like a workspace commitment. However, this probe code functions (as far as I can tell) exactly like G92. Other than the fact that one of the lines in the probe script is a different code, I’m not aware of anything I will need to do differently than before, i.e. when I was using G92 in my probe scripts.
Do you have this in multiple threads, I swear we were in another thread?
How about just give me some time before going crazy with this info. Please hold off on recommending it to too many people. My intention is to make a new place for this info that will not add to the confusion of new users. I am shooting to make a intermediate milling page of some sort.
I need this info to be separate so all the last 8.5 years of posts about G92 are not complete incorrect info. This way, new users and users set in their ways will still be able to search and we will not require all the helpful people around here to completely learn a new workflow and invalidate any current gcode they use on a regular basis.
I am still three days out on orders now is not the time for me to be working on this. I need some time to figure out a smooth way to recommend this to ONLY experienced users without leaving beginners feeling like they are being left out of left behind.
Think about how the instructions currently tell users to start jobs. Think about what happens a week later when they go to start another job be it the same or different.
I will work on this, just not right now. Please hold off on publishing a video about it. Also please remember If you do make a video about this, you are also probing different from how the instructions tell users to do it. I have users use it in the gcode as a starting operation so they do not have to think about doing it before they start a job. One step instead of two. Obviously I have no issue with you doing it any way you want, it just makes a disconnect between the instructions and how you might tell people to do it. If they forgot to probe before a job then it starts in the wrong place, if it is in the gcode that starting step can not be forgotten.
My goal is to make CNC as approachable for a brand-new user. Features, bells and whistles, LED’s, pendants, spindle SSR’s are all amazing, but just add to the learning curve. All those things belong in the intermediate instruction page and should NEVER be recommended to a brand-new user.
While workspaces offer job recovery, new users will not be using that feature until they fully understand how to run a job in the first place. It is best if they just start over instead of try to figure out how to edit gcode to recover a job. In my opinion.
1 Like
Up to now, and potentially still going forward… For each of my jobs, I have basically three different starting points. One of them is the near corner of a 49x97 MDF sheet. The second is the near corner of a 48x96 plywood sheet. The third is “anywhere else” other than the first two. When I start a job, I have some different “home+jog+probe” scripts: one for MDF full sheet start point, another for plywood full sheet start point, and finally a “home+probe” one for manual jogging to somewhere else. Since I have to do some nudging that would be different no matter what’s in the start code, it’s just as easy for me to include the probe in that, and my start code area in ESTLcam is blank.
I’m at your discretion. Just need to clarify this is not pendant, offset XY zeroing does not survive reboot, and as far as I can tell does not require any awareness of workspaces or any difference from the previous normal workflow. I won’t be publishing a video unless you are OK with it. If I prepare one regarding this, I will get your OK before going live with it.
In worksapces you do not need to do all that manually. When you change workspaces it knows to go to that location. You are overcomplicating it.
We are at a hard place. We have Marlin and GRBL users. When the dust settles from the holidays, we can all pow wow about how to handle this. Also I think we all need to use it and learn it far better before we start trying to tell others how to use it. I will not write any instructions until I have used them on a regular basis for a lot of jobs. How we currently work has been perfect for 8.5 years, there is absolutely no need to rush anything here, nothing is added that can not already be done as is. Currently if you write down your starting coordinates, it functions the exact same. Any change needs to be worth it, and crystal clear.
1 Like
Apparently it’s possible to have offsets that survive a reboot, and also that do not survive a reboot. This particular XY reset (in the probe code) does not survive a reboot. Surviving a a reboot has pros and cons. Side note: this definitely seems different from using the Fluid Dial pendant buttons to zero X or Y axis (at least as of when I tested it during development — it may be different now or become different later). For now, those pendant button offsets did seem to survive a reboot, while the above does not.
For sure. No disagreement. For me, the benefit of the different probe line change is the soft limits working [updated to add, that seems to have been an incorrect understanding], and does not require any workspace knowledge or any change in how I was working before. I totally get that I need to work with this for quite a while verifying all that, and getting to know it better.
I’m the first to admit I don’t use workspaces as provided by the Gcode wizards. My three different probe scripts that I choose from (MDF full sheet, plywood full sheet, or “other”) basically serve as my own style of workspaces, which worked by G92, and beyond that did not invoke or involve a workspace, and this edited probe script would allow me to keep working in the same way. Probably each maker has things he understands that work for him, even if not “orthodox.” My three probe scripts allowed me to zero in three different places (two quite commonly used) without learning workspaces. I may yet learn workspaces. 
Are you sure of that?
My understanding is that all of the “Zero axis” buttons use G10 L20, as this is the code that sets the current tool position to (0,0)
G10 L2 is used when you want to set the offset to a specific offset from machine coordinates, not based on the current tool position.
Without looking at the pendant code, I would assume that it executes the same “zero axis” command that the WebUI executes, which is G10 L20 P0 X0/Y0/Z0
Edit: Quick github search shows G10 L20 in pendant code
displayer.send_line("G10L20P0" + axisNumToString(jog_axis) + "0\r");
displayer.send_line("$Log/Msg=*G10L20P0" + axisNumToString(jog_axis) + "0\r");
OK, I have interesting news that is perplexing (no joke). It’s a mix of perhaps good news and perhaps not good news. I’m baffled.
I questioned myself just now on whether I somehow mistook whatever was keeping probing from working while having soft limits enabled, i.e. could it have been something other than G92, and I was misunderstanding?
I just now commented out the G10 line, moved the G90 line up above the XY offset line, and made the XY offset (re-zero) line a G92 instead of G10.
The probe process worked. The soft limits work. Great! But here’s the kicker. Now, with G92, the XY offset is surviving a reboot. The Xw and Yw values from the offset command, are surviving a reboot. Whereas with the particular G10 command I had in place, the values did not survive reboot.
Ryan is the expert. I leave this in his hands. I will try to learn and gain understanding, as at this moment I am somewhat baffled. For now I’m putting the G10 line back in, and putting it like I showed above. Shaking my head with a half smile of confusion. 
1 Like
I’m not super sure of much at this point.
You and Ryan are the experts, far more knowledgeable than I. When I say I’m a noob at this, that is not just kidding around.
I’m a sleepy-headed granddad, who used to be quite bright, but probably now has too much carbon dioxide floating around in the house, and has suffered years of sleep deprivation due to previously undiagnosed sleep apnea.
I have not yet delved into the code behind the pendant buttons.
All I can say at this point, is the pendant buttons led to an XY offset that seemed to survive a reboot, while my G10 on the WebUI did not, and just now a G92 on the WebUI led to an XY offset that seemed to survive a reboot. I’m confused, to say the least.
1 Like
This seems good. I just don’t understand why I seemed to get “does survive reboot” when I did it from the pendant, while getting “does not survive reboot” from the WebUI running a probe script. 
1 Like
Oh….expert I am not lol
I have probably logged a total of 5 hours cut time ever lol.
That was actually a question, not just a rhetorical one 
1 Like
I’m wondering if we should create a subcategory maybe in the lounge to discuss GRBL more and learn from each other.
1 Like
I don’t think that is needed. There are a lot of benefits of having open conversations.
Let’s be frank here: Coordinates are confusing and deceptively so.
I have learned from my many years of fighting them in software that it is easy to think you’ve got them, and then you don’t. Guess and check is fine for things like endstops, but I have found that doesn’t work with coordinates. You have to work on them analytically.
We have a primer on coordinates that goes from zero to workspaces:
https://docs.v1e.com/learn/coordinates/
This isn’t linked from the main instructions (AFAIK) and it isn’t in the basic milling either. The idea was to get people from assembly through the crown and into their first job without doing too much learning (there is already so much to learn). Then if they wanted more, we would have some learning section stuff with more. Or if they came to the forums asking about it, we would have a good explanation ready.
Doug, your videos are awesome. And you’ve always gone in your own direction with them. I don’t want anything here to slow down your passion. So I am a little worried by this exchange. It is fair to say that coordinates really intimidate new users (and our current methods are the least intimidating). It is also fair to want to try new things and that may be entertaining to you (and your audience). So maybe the solution is just in finding the right language in the presentation.
As for the actual gcode usage. There are more than one ways to do the same job. G92 is (for better or worse) the way it is done in vanilla Marlin. Thinkyhead made Marlin for 3D printers and when a lot of these decisions were made, it wasn’t clear if Marlin was going to work, let alone grow into all the machines it has. If G92 works in grbl, then I don’t care if it isn’t the “right” way to do it. It is a good method for both sets of users. If we have to fork all our conversations and say “if jackpot: G10 L20 else: G92”, then it will get a bit ugly in here. This debate has yet to happen fully. And it sounds like Ryan wants to learn as much as you have before he dives into the discussion.
That said, the theory of the docs is that they describe one “yellow brick road” that users can follow to navigate the many ways to CNC. If users want to walk off trail, we have some rangers in the forums that can help them a little. And if you want to go somewhere very off trail, we shouldn’t stop you.
So if you want to talk about new coordinate gcodes and how they affect grbl, and develop new probe scripts, IMHO: go for it. If you want to do new users a favor, make it clear you’re trying something a little more advanced and it isn’t necessary for someone getting started. Or maybe Ryan is hoping that with a little more time, we can be confident this is the best way for beginners and then that should be the message. IDK.
4 Likes
Yeah, at this point I am ready for a clear line in the sand. Milling basics, and milling beyond the basics (or something). We have the SSR’s, leds, vac triggers, probably even lasers, workspaces, tuning for laser speeds, accel tuning, jackpot modules, adding fans, ect. Maybe even make the basics page more basic. Then an intermediate page for end stops and 3D carves, and an advanced page for things that require wires, and firmware editing?
When a new user comes here I am very protective of that experience. I want the build to crown path clear. I do not want “this or that”, the “correct way or the other way”. I just want to follow these instructions and go. If I put up a beyond the basics page I think it becomes very clear that those things are extra. Turning on your router and by hand is perfectly acceptable, adding a relay is just extra.
As we all gain experience we forget some of the struggles we had, I can tell you we still get a lot of g92 questions. Trying to explain two or more coordinate systems simultaneous is not for a beginner to worry about.
I absolutely do not want to slow down and videos or explorations, I just do not want people to think that is the way they have to or should be running. I agree the language or something is a bit off. It is just hard with that large of a following, video quality, and clear excitement you can steer people very easily.
I have said it before I am sorry if my tone comes off harsh I just try to react to these post as fast as possible because Doug you are fast. You can have a wonderful video up in a matter of 45 minutes, and then people are out ordering pendants that are not ready for prime time yet. So I drop what I am doing to add my $0.02. The fluid wiki even has a “please do not pester us with questions, we are still working on it”. I am not sure how to best change those to make it more clear this is a fun new feature that is coming soon. The videos are amazing and the excitement comes through crystal clear…I even reached out to M5 for a large bulk order after watching your video, then I looked into it further and decided to wait until developments slows down on it. The other side of it is with something new pointing out flaws is kinda two-sided dev has not had time to fully flesh it out so yes, you need to discuss flaws, but in a way that it is clear they seem like an easy fix that is currently being worked on.
As an example from me. I love the way my LR looks with LED’s, I love the little triggers to show what is going on. I filmed a video for it, I was very excited. Then I stopped. Doing that would open up a lot of questions and currently I do not thing there is a great way to implement it. I also understand ME making a video about it is different from everyone else. So having stuff like this implemented in a page that clearly says “advanced” might just be all we need. “If you want more details, here is a link to the advanced instruction page”. Since the instructions are user editable, anyone can write out a clear section ahead of time for people that want more info.
I am not sure and I absolutely mean no offense or to slow down and good content, just make sure to think about the presentation and who the content is for.
8 Likes
I totally get it. And by that I mean, I get your points here, not that I get coordinate systems! The only other video I have planned now… does not go into this discussion, and, at least at this point, I think I could make the video with using G92 in my probe script, and not even have to mention this line of questioning. It’s simply a video about getting the gantry trammed with the table, using probe samplings readouts from the WebUI with a Jackpot board.
Also, just to clarify again, it seems my supposition that G92 precludes use of soft limits was not right. I’ve gone through some of my recent posts and added stuff like “[updated to add:]” to try to prevent any additional misunderstanding.
UPDATE after testing G92 and G10 L20 with having hard limits and soft limits enabled
I just finished some batches of testing, both G92 offset and G10 offset. I was specifically testing to see if offsets survived reboot of the Jackpot (and accompanying refresh of WebUI). My findings were that:
-
Both ways had the offset made during probing to survive reboots.
-
Both ways had occasions of significant delay in reflecting that the offset stayed saved, such that for quite a few seconds after a reboot and refresh, it could appear that the offset did not survive the reboot, yet then suddenly the X “w” and Y “w” would update/refresh, and show that the offset did persist after reboot. I think this delay was a cause for why I had mistakenly formed the impression that G10 offsets did not survive reboot, and why it took me some time to realize the G92 offsets were also surviving a reboot.
-
Both ways can coexist with soft limits. Both ways can probe with soft limits enabled, provided that the gantry is high enough before starting a probing operation.
-
Both ways can refuse to probe and throw a warning about going beyond soft limits, if trying to start a probe operation while the gantry is too low such that the extreme edge of the probe operation would be below the soft limit edge.
-
I have an extra “G91” in my “G38.2” lines, which may or may not be necessary, but somehow along the way I got the impression it made one or both ways able to probe without warning/error.
Here are some details:
I created two probe script files to serve for macro buttons, one using G92 for setting XY 0,0, and the other using G10 L20 for setting XY 0,0. The attached zip has both those scripts plus my config.yaml.
My probe scripts and config file.zip (4.1 KB)
My config file has my table sizes in it, and has hard limits enabled and soft limits enabled.
This testing was all done with no dial pendant. That was completely disconnected.
My LowRider has “Dan’s Extra Tall” YZ plates, thus the “-124.9” in my lines of “G38.2 G91 Z-124.9” … If you don’t have the extra tall YZ plates, then you’d need to subtract about 50 mm or so (i.e. “G38.2 G91 Z-74.9”) in order to have the script work and play nice with soft limits enabled.
Here is the macro script I used for G92:
G21 (MSG G21: Metric mode)
G90 (MSG G90: Switching to absolute positioning)
G94 (MSG G94: Feed = per minute)
G92 X0 Y0 (MSG G92: Setting current XY position as workspace origin 0,0)
; M0 (MSG Attach probe)
G38.2 G91 Z-124.9 F400 (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.34 (MSG G38.2: Slow probing to material. Plate thickness: 0.34)
G90 (MSG G90: Switching to absolute positioning)
G1 Z30 F900 (MSG G1: go to Z30, speed 900)
; M0 (MSG Remove probe)
; M62 P1 (If used start spindle pin27)
Here is the macro script I used for G10:
G21 (MSG G21: Metric mode)
G90 (MSG G90: Switching to absolute positioning)
G94 (MSG G94: Feed = per minute)
G10 L20 P0 X0 Y0 (MSG G10: Setting current XY position as workspace origin 0,0)
; M0 (MSG Attach probe)
G38.2 G91 Z-124.9 F400 (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.34 (MSG G38.2: Slow probing to material. Plate thickness: 0.34)
G90 (MSG G90: Switching to absolute positioning)
G1 Z30 F900 (MSG G1: go to Z30, speed 900)
; M0 (MSG Remove probe)
; M62 P1 (If used start spindle pin27)
I made meticulous notes and took screen shots at times, which I time coded to index them with my notes, but I am not uploading that level of detail unless someone thinks it would be helpful.
Obviously I am not a GCode wizard, and just scratching to get by.
A more common process for probing would be to home, then manually jog down close to the material, and use a probe script with a closer target distance than my “-124.9.”
My reasoning for both that longer distance and for having two “G38.2” (one faster, from a farther distance, and another slower, from closer distance), is that I planned to be able to home, then line up the XY, and probe from all the way at the top.
My two most common setups are to home and then use one of two macros to jog over to either the XY corner of a full MDF sheet or the XY corner of a full plywood sheet, and also then probe from the top.
Now, although I guess I could modify the script to add in a downward jog before the probe, neither the material thickness nor the bit length are known in advance, so the script would still have to come up short on the jog. This way works fine for me.