JTech laser/GRBL spindle issues

The [G54] line seems suspicious with the -.7874. seems to jive with the depth that the Z axis travels

That is the Work Zero position in Machine Co-ordinates. Do you home your machine?

I dont. I never saw the purpose in homing the machine. I always just jog the machine to where I want to start the carve “zero” it via the “do you want to zero the current position before starting” prompt and proceed from there. my Z axis limit switch is also broken.

There are many advantages available if you home your machine.

This could be the root of your problem as you almost never have the same Machine Zero and since the Work Zero position is referenced to Machine Zero the order in which you do things on your machine determines whether or not it is going to behave as you expect.

There is also a potential problem with the addressing mode (G90/G91). You have Z movements in your G-code file and depending on the addressing mode you are either moving directly (G90) to Z = 0.8 inches and then over many lines of G-code you move to Z = -0.0010 inches, or if you are in incremental mode (G91) you are moving from the current Z position by 0.8 inches and then moving from the last Z position by -0.0010 inches throughout the G-code file.

At the end of the G-code file you either move to (G90) Z = 0.8 inches or (G91) move 0.8 inches from the last Z position.

Is that Easel?

I never use easel. I use Vcarve pro and then GRBL Controller to send gcode to the machine.

It seemed to come from the version of firmware I was using. I updated it to a different firmware version and it stopped prompting me to accept the current position as zero. Now that Im using the version Larry built, it asks for it again (only in GRBL Controller)

Larry - How do you suggest fixing the issue with the (G90/G91)?

Ok, you had picture of PicSender, so I assumed that was what you were using.

Since I don’ have GRBL Controller I have no idea what changes it makes prior to running the G-code, but my best guess is that you have a problem with the internal state of Grbl when you have a job that doesn’t run correctly from the exact same G-code file as the previous run that was successful. This is not a grbl problem, but is a problem with the software that generates/sends the G-code to grbl (not necessarily a bug, could be user setup issue, post processor anomaly, etc.).

The post processor that you are using is not causing the problem, but could be aggravating it.

I just tried using PicSender today - normally I use GRBL Controller.

When you say “software that generates/sends the g-code to grbl” are you saying its Vcarve (g-code) creator or my sending software (GRBL Controller/UGS/PicSender)? I tried using all 3 and each one did the same Z dive

You can try this experiment.

Edit the G-code file:

original

T1
G17
G20
M03 S0
M05

to this

G17
G90
G20
M03 S0
M05

Basically, remove the T1 and add the G90 after the G17

Be prepared to stop your machine if it doesn’t work correctly.

[Edit] when you jog the Z axis, which way does the spindle move when you move in the positive direction?

First of all, thank you guys all for the help. I feel like a complete moron asking these seemingly freshman questions about programming etc. Larry - extra apologies and thanks for your patience.

In regards to editing the gcode like you suggested - how would I go about doing that???

With that being said - I hooked up the machine and fiddled with things and SOMEHOW ended up with a new G54 Z value of -2.001 or so. Completely exaserbated I opened pic sender and selected “set offsets” then option 1 for G54, and set X,Y,Z to 0.

Checked $# and found G54 was zeroes across the board. Tested a file and lo and behold - shes back to working as I understood as “properly”.

But my sense of proper function seems to be a bit erroneous as Larry has pointed out.

I need to develop a SOP for things Ive realized - and most of my practices (not homeing for instance ) stem from ease of operation. I hated having to go from UGS to set my tool start point, switch to GRBL controller (UGS doesnt have a working visualizer for me, but is easier to jog the machine. Also it would occasionlly go off in the weeds when I would send gcode to it) (GRBL controllers manual jog sucks which is why Id use UGS). I then decided to bypass UGS all together and physically position the router or laser, physically rotate the z thread by hand (off power of course), turn on the machine and go into GRBL controller and start the carve there.

It seems this is a poor way of doing things?

What changes to SOP should I adopt for better performance?

Since you don’t home your machine you will almost never have the same G54 values when you set Work Zero.

The G-code file is just a text file. Open it with Notepad or your favorite text editor.

Should be able to get it working without homing. I just haven’t figured it out yet. At this point there seems to be more than one issue, but I’m trying to take them one at a time.

Hard to say since we don’t really know what the root causes of your issues are.

Im going to be away from my machine until the end of the month - when I get back from overseas I plan on trying to tackle these issues. In the meantime I’ll get a new limit switch for my Z so I can start properly zero my machine.