Allow $ commands

Would be great if CM would send $ commands. Could be an “advanced” menu option on if to allow or not.

I am pretty sure that this is disallowed out of concern for EEPROM write cycles.

1 Like

While a valid concern, anyone who knows enough to put $ in their pre/post should be aware of the concerns.

My main target is GRBL Laser mode. CM could allow-list only this if needed.
F360 will have $32=0 at the start.
LightBurn will have $32=1 at the start of the file.

Neither will have anything at the end of the file.

I can run cuts all day long without a single write cycle - GRBL does not touch EEPROM if the setting is not changed. ( grbl/eeprom.c at master · gnea/grbl · GitHub ) I could also run the laser all day without any wear. Going back and forth would cause no additional wear compared to if I had to do this by hand between jobs.

Do you send the GCode directly from LightBurn? If so, and it supports sending $ commands, you could put $32=1 at the start of the lightburn file, and $32=0 at the end of the lightburn file.

1 Like

No - I export the GCode from Lightburn to run on my machine. I use a Pi to control my Shapeoko.

I don’t know that the concern is for wearing out the eeprom. You’ll likely have a new controller for a different reason before that happens.
Writing to eeprom takes time. There can be issues with buffering and lost or corrupt data.
I’m sure that can be accounted for on the sender’s side and it can usually be mitigated with dwell commands. It does make for difficult troubleshooting and would potentially be a nightmare for support.

3 Likes

I send $ commands in the MDI window. Are you not referring to that? When I use Lightburn I use its macro functions to switch.

Lightburn does support this. They have a “Console” window that allows you to type GCODE directly to the board. It also supports user-defined macros that you can execute from the console. Just about everyone with both Lightburn and CM will use this, as the parameters for direction need to change. With recent changes in CM, I’ve added $X to the start of each of my Lightburn macros.

The only hassle is remembering to run the “reset” macro (mine is called, “UseCNC”) after completing my laser work, before going back into CM.

  • Gary
3 Likes

Lightburn doesn’t run on a Pi, so I don’t use it to control my shapeoko, merely as a CAD tool.

Using the MDI in Carbide Motion is an option, but it’s manual, and requires I plug in a keyboard.

Carbide Motion will error out if there is a $ command in the NC file.

1 Like

$32 aside, do laser files work with CM? We’ve never hooked up a laser to a machine here.

I’m happy to try but no reason it shouldn’t - here’s a file with the guts snipped out.

(I have Lightburn set to have the max spindle value at 1000 to match Shapeoko defaults, so it will interpolate 60% as S600)

Again, even if C3D wants to play it careful and allow ONLY $32 to be set from an NC file, and no other setting, that would be huge. I’d put $32=0 in my F360 post, never wear out my EEPROM, and then never worry if I ran a laser job last and if I remembered to set that value.

An aside - leaving $32=1 set will make “Spindle ON” in CM do nothing (BitRunner). I talked to Brandon in support last week as I thought my board died. I didn’t run a cutting job, and I don’t intend to test it, but running a job with $32=1 might cause a crash since the spindle won’t turn on. I measured the PWM output from the BitRunner header, it stayed at 0V when I toggled “Spindle ON”.

; LightBurn 1.0.04
; GRBL device profile, user origin
; Bounds: X296.68 Y83.89 to X395.2 Y93.79
G00 G17 G40 G21 G54
G90
G0 X0 Y0
G91
M4
; Scan @ 6000 mm/min, 60% power
M8
G0X-39.999Y-4.95
; Layer Labels
G1X15F6000S0
G1X0.716S600
G1X15S0
G1X40.232Y0.1S0
G1X-15S0
G1X-0.948S600
G1X-39.007S0

...

G1X-0.948S600
G1X-15S0
M9
G1S0
M5
G90
; return to user-defined finish pos
G0 X0 Y0
M2
1 Like

That’s what you want. They’re shouldn’t be any pwm voltage unless the machine is moving.

@greg5 Did you see my post above related to eeprom? I don’t think anyone is worried about wearing out the eeprom. I’ve seen, in testing and helping others troubleshoot, some really inconsistent behavior when streaming $32 settings in gcode. Have you tried in any sender’s that don’t filter the gcode?

Ah good point on the spindle.

I repeat the EEPROM as I’ve seen it touted here and there. Some think wearing it out is an issue.

I should have time tomorrow night to try it out. I feel like in gSender 0.7.4 it didn’t work, but in 1.0 I didn’t get errors… we’ll see. I don’t see why at the start or end of a file it should cause any issues, a $ setting is similar to a realtime command. No doubt during the actual program it could possibly cause issues, EEPROM read/write I think will block on AVR but it just means some dead time for movement, I can’t see the software having such a tight timing loop that a few CPU cycles dropped break everything? I’ll report back.

From the following site: Arduino - EEPROMWrite

An EEPROM write takes 3.3 ms to complete. The EEPROM memory has a specified life of 100,000 write/erase cycles, so you may need to be careful about how often you write to it.

With 100,000 write/erase cycles average you will be pretty old by the time you wear out an EEPROM. Likely the source of the idea that you will wear out the EEPROM likely came from the statement above. In a lab or test facility you might wear an EEPROM out but in my 40+ year career as a field engineer I never saw a worn out EEPROM and I have flashed a lot of EEPROM’s over the years.

1 Like

Neil, you are correct. GSender does not like $32=1. I get an error on an unrelated line of code reported. I can hit resume and it will keep going, but that’s not exactly confidence inspiring.

Edit: a dwell after setting $32 has things running just fine.

Edit2: disregard. While the dwell made the file run, the setting actually did not change the parameter. There is still a delay when issuing spindle commands so it’s not truly in laser mode.

CM won’t load the file. If I comment out those two setting, it runs it just fine. (Dry run)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.