Wow. Things going along just fine, and then we just took off on a rapid move to somewhere near the HOMING position. I had burned the A-side with my laser, switched sides, loaded the new gcode file and clicked OUTLINE (which I also did on the A-side.)
Iāve been using the āG55(P2)ā workspace feature. Nothing like this happened in 0.7.3, so it took me by surprise.
Iām using a J-Tech laser and have added the offset with G92. (BTW, this would be a good feature to add to gSender. I put this offset in my post.)
I think in loading the new version 0.7.4, it defaulted the Spindle/Laser mode to spindle. That seems to be the only thing I can find different or not-set-correctly by me.
Iām wondering if that would make the carriage rapidly traverse to the Homing position (back right corner for my machine) not under program control? Even after stopping the running program?
Howdy over here, @NeilFerreri ! Iām thinking this thing that started happening is in my gcode not in gSender (happens in 0.7.3 and 0.7.4.) The timing is that my router went sailing to the homing position at the beginning and end of the program instead of to XYZ zero. Doesnāt make any sense to me, but its got me a bit shy about hearing those grinding sounds!
G0X0.0000Y0.0000
G0Z0.0000
One other event happened before this started; I used Carbide Motion to mill 4 juice grooves in small cutting boards. However, the machine was off for 2 days in between.
The $# list included shows that workspace XYZ in G54 and G55 are mostly the same because I desperately was trying to make sure I had XYZ zero set, and then it went sailing off to another potential crash before I cut power.
So, in reference to my original āproblemā, I can only surmise that it ultimately resulted from what this; the workspace setting (āG54(P1)ā, āG55(P2)ā etc.) doesnāt seem to be sticky. It could be that I completely donāt understand how these workspaces are designed to work. It very well could be my gcode causing this to happen, too.
If Iām using āG55(P2)ā, just about anything will set the workspace back to āG54(P1)ā, and I didnāt notice this happening. Compounding this issue was that I hadnāt set XYZ zero in āG54(P1)ā, so gSender sent the carriage back the machineās initialized XYZ zero. This was also compounded by using Carbide Motion which reset the āG54(P1)ā workspace back to 0,0,0.
Iām kind of guessing, but that does seem to explain what happened. If I continually monitor and continually set the workspace to āG55(P2)ā, I donāt see any problem.
Hey @CrookedWoodTex . Sorry for the late replyā¦Iām not around here much.
So Motion will do that. it resets your Work zero on G54.
G54 is grblās default work coordinate system (WCS), so anytime you reset your controller (disconnect & reconnect) youāll default back to G54. Iād recommend using a G55 command in your gcode as good practice to force the WCS at the start of a job.
You can always check your offsets with a $#, and you can check your current modals (including the current WCS) with a $G.
Are you using lightburn to generate that g-code. I donāt like the G92s in there, but they do their own thing over there.
Motion reset your G54 offsets, as it does. When you came back to gSender, grbl reset and defaulted to G54. Your work offsets in G55 were still stored, but gSender was working in G54 which, for you, had work zero set at you limits in the back right. Any motion to positive work coordinates would crash the machine back right.
Thanks, Neil (@NeilFerreri ), for the confirmation. For now, Iāll have to add G55 into my postprocessor, but it would be better if I could build it into a Vcarve toolpath. The problem is G54 is executed when I donāt recognize it happening. Iām still not sure how that happens. I can expect it after reset, but I think it happened after I stopped a running gcode program.
The G92 is used to get the offset between my laser and router. Gary Mitchell was kind enough to share that with me, so I built it into my postprocessor for Vcarve. Iāve had no trouble with that, except the 3D view in gSender and CNCjs offsets the purty picture. Since its a permanent offset, Iām aiming to build it into gSenderās start macro ā¦ one of these days.
Stopping a program running runs a soft-reset on the GBRL board which would reset your set WCS. This is generally pretty common in most senders (I know CNCJS, Openbuilds, and UGS all do it). Thatās why you see the WCS being reset on program stop - itās the ensure a baseline state for the board so the next program can be run successfully.
I see. That makes sense. @KGN, it would be nice if gSenderās WCS āselectorā showed the active WCS. As it is currently, it will only display the correct WCS if it was changed with that drop down.
In CNCjs, the Work Coordinate System dropdown menu also works to display the current WCS whether or not it was changed using said menu. Relevant code section (maybe?)
@KGN , as Neil said, as you have WCS selector now, I have had no way to tell what WCS I was working in so when it changed I ended up mostly crashing my carriage (before I stopped it.)
I believe this selector is out of tune with the rest of the UI.
Upon further thought and use (I added āG55ā to my gcode), this āresetā is what will cause a CRASH when XYZ zero work offsets in G54 are unknowingly set to zero (as Neil says and I found out.)
Iām wondering if there could be an easier solution than the one Iāve been using? (Which is to always/every time manually set my G54 XYZ zero and manually add my āG55ā command to my gcode.) Iām guessing this is the time to use a MACRO of some sort.
If itās code you run every time on program start, you could add it to āProgram startā section in Start/Stop G-code in preferences. This will run whatever gcode is entered before program start for every single program. If you always need a G55 manually inputted into a program, it would probably be significantly faster for you to just enter the command there, along with whatever else you consistently need to do on program start.
Currently, Iām producing a couple of small parts for inventory. Each has a ālast minuteā customized area for a name, etc. Each has a fixture that I just leave mounted. The fixtures use G55 and G56 for XYZ so I can quickly change fixtures without losing the G54 XYZ (which got complicated with G54 getting reset.)
So, I can see that a dedicated macro could possibly set the fixtureās XYZ values for G54 use, but as I was contemplating that, gSender came along.
I donāt see it mentioned here, but with 0.74 when I click on GoTo Y0, it also goes to Z-5, which also appears in the Console. Several 0.035 drills died bringing you this message
