gSender 0.7.4 Problem

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.)

KN_BSide_Laser Cut StarsOutline 50-20-1.gcode (9.8 KB)

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?

Hey @CrookedWoodTex
Can you report the reply when you send $# through the console?

1 Like

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.

gSender_$#.txt (2.2 KB)

[EDIT - ADDED]
Here’s the console report on a test run of the file loaded above. gSender just seems to quit testing the file?

gSender_FileLoaded_Test Run.txt (2.2 KB)

[EDIT2 - ADDED]
This is the console report from Carbide Motion. Notice that it has zeroed G54 but left G55 alone.

CarbideMotion_$#.txt (2.9 KB)

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.

1 Like

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.

1 Like

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.

1 Like

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.

2 Likes

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.

This is something we can add for the next build for sure. Thanks for the feedback.

2 Likes

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.

2 Likes

@CrookedWoodTex Why are you using G55? Do you always use G55?
There is probably an easier way.

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. :smiley:

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

This should be fixed in the next build. RIP bits.

The way WCS selector works now is just fine. I can look at it and see where it is set. +1

1 Like