EEPROM $$ settings continued

Previous thread locked, not sure how to continue.

I did some more testing and it’s nto actually working.

So adding $32=1 to the very first line in the NC file, and $32=0 at the end, has inconsistent behavior. It will sometimes throw an error on an unrelated line of gcode.

Adding a dwell after the settings gets rid of that issue.

However, the setting will not actually apply. If I run a laser job with the $32=1 and a dwell, the file will run, but you can observe the gantry stopping/starting motion between spindle commands. The behavior is the same as if you forgot to set laser mode in GRBL.

@greg5 I closed the previous thread, as I thought your issue was resolved. My apologies for jumping too quickly.

I re-read your original first post and I’m a bit confused. (Not an unusual state for me.) You say that you are using LightBurn, but then talk about errors in gSender. LB sends code directly to the Mill, so can you tell me what purpose you are using gSender for? From there, I may be able to help.

No problem!

I’m only using lightburn to generate gcode. Using gSender as the actual gcode sender.

@greg5 Understood, tks. Why are you using gSender? LB will send directly to the Mill. Did that cause you some issues?

Either option requires you to set $32 and $30. I use macros in both LB and gS to do that. I don’t use gSender with my LB files, but I do forget some times to revert back to “router” when I’m in LB, so I set the same macros up in both.

@gwilki , I do the same thing as @greg5. I generate gcode with Lightburn and then use UGS to send it. I have played with Lightburn as the sender, but prefer using UGS. I am gradually moving to GSender.
I don’t have any useful help for this issue because I just set $32 with a macro before running the toolpath.

1 Like

@paullarson Tks, Paul. Interesting. It really never occurred to me to export the gcode, even when I was using UGS. When I was using UGS, I had macros to turn laser mode on and off and to change the speed setting from 1000 to 3000. I have the same thing in gSender now. Works well.

Lightburn doesn’t run on a raspberry Pi :slight_smile:

Macros would work but I try to keep things as foolproof as possible. If I could add laser mode to the start of my lightburn files and regular mode to my cutting files, I’d never need to worry about forgetting to change modes.

@greg5 Oh sure, bring a Pi into the discussion. :grinning: :grinning:

I suspect that Paul knows much more about this than I do. I’ve never tried to add the laser on/laser off codes to the gcode file. I’m eager to learn how you solve this, though.

Hey Greg,

Is that always the case? As I mentioned elsewhere, those EEPROM writes create some interesting troubleshooting.
Was your $32=1 the first line in your file?
How long was the dwell?

Yes, first line in file. The dwell was 2 seconds.

@greg5 have you tried to implement the laser-mode command into a test file and run it in another g-code sender? It could be possible that the behaviour you’re seeing isn’t gSender specific rather it’s an issue with how GRBL processes the mode switch - requiring some time to change over similar to how we use dwell commends during probing procedures since sometimes the value won’t stick if not given some time to write first

I think it is GRBL related. The dwell was very inconsistent in terms of results.

1 Like