S-MIN does not apply for fast G0/G1 travel via blank part of the job
ElfyShort opened this issue · 11 comments
In the "Target image" window the setting S-MIN does not apply to the fast travel through the white parts of the engraving model.
I don't know whether it is a feature or a bug, but I really want it to keep my laser working all the time at S instead of S0 in order to prevent enable relay to trigger on every S0 in the g-code.
Is it possible to make a checkbox just near the S-MIN text field to apply this as min value throughout the whole engraving script except for the first "M3 S0" and the last "M5 S0". This would be great, since now I have to export gcode, track all G0/G1 with S0 and change them on the line with S4 manually.
Thanks!
Here is the example of the gcode where I set S-MIN as 4:
G90 (use absolute coordinates)
G1 X-15 Y-15
M3 S0
F330
G1 X0.6 Y-14.96 S0
G1 X0.66 S5
G1 X0.68 Y-14.94 S0
G1 X0.66 S7
X0.64 S12
X0.62 S13
X0.6 S12
X0.58 S7
G1 X0.44 Y-14.92 S0
G1 X0.46 S4
X0.48 S6
X0.78 S6
X0.8 S5
G1 X0.82 Y-14.9 S0
G1 X0.8 S5
X0.78 S11
...
Have you enabled Laser Mode in GRBL configuration. I know it has to be disabled for the spindle, but if you are using a laser it should be enabled.
$32=1 for enabled, 0 for disabled.
I don't think it would be fixed, as it is more of a GRBL issue than LaserGRBL. If you are annoyed by the clicks, I'd suggest replacing it to a solid state relay
I created this thread because of the setting in a software works in a weird way and I do not understand its behavior. Why have S-MIN at all if it still create lines with «S0» in the gcode?
Pixel in image can have grayscale values from 0 (black) to 255 (white).
While white is always white, and therefore must be performed at S0, a slightly darker color than pure white (very light gray) may not be correctly reproduced via an S1 (or other very small S values) on some materials, as often some laser drivers need slightly higher values even just to turn on the diode.
For this reason LaserGRBL allows the assignment of an S-Min which is applied NOT to white, but to almost white (RGB 254,254,254) with the intention of igniting the laser with sufficient power to make a very light burn comparable to an almost white, but not white. This also provides a more "compressed" gray scale which allows to better use the laser modulation.
If the white movements were sent with S-Min instead of S0 this could result in "almost white" (instead of white) and this would not be the desired result. This is why white is not sent as S-Min but as S0.
Besides it is good for a laser healthy and power stability to be turned on continuously during the engraving process without it turned off completely.
A laser diode is a switching/pulsed device, it is switched on and off hundreds of times per second by the PWM modulation itself. It is not a problem for the laser diode to be switched off completely with G0 movement.
It’s just on «S0» my machine is configured to shut down current to the spindle as a precaution by turning the relay off.
It works just fine, just have my relay clicking like crazy.
What you describe looks more like a problem with your control board.
A laser diode can be switched off by simply send a logic "low level" to its driver TTL pin. No need to cut off its power by switching a relay.
Not only that, turning off the power supply is a problem because the circuit that powers the diode (laser current driver) requires considerable power-on and power-off times, so it should always be kept on.
So I agree with you that having a relay that turns on and off on the board is a problem, but I advise you to intervene on the board, or on the firmware, instead of thinking that the problem is on the software. There is no reason why a control board should intervene on S0 by cutting the power with a relay.
Thanks, now the request is clear to me.
You call it "fix", but it is not a fix. It's a feature request.
You are not the first person to ask for changes to how the g-code is generated. Usually the request concerns the on / off codes for those who use commands other than M3/M4/M5, the control of the Z axis for pen-plotters, the acceleration offset to avoid burning the edges and many others.
The reasons why I do not give flexibility and greater control over the generated g-code is that we must take into account the general complexity of the system.
LaserGRBL implements some core features (such as the preview drawing itself, or the ability to reconstruct the state and resume an interrupted job) which need knowing the very meaning of the commands, their modal state, the possibility of restoring them and with which syntax.
Also, the more options are provided such as control or configuration, the more complexity the program assumes that makes it difficult for most people to use. The audience of LaserGRBL is 99% of people who buy a laser engraver without even know what g-code is. It changes the configurations at random and then comes to ask why it doesn't work.
More unintelligible options = more questions... and you have no idea how many questions I already get!
But as I understand you are not interested in fixing software glitches as long as not half of the users will report the same issue. Will keep modifying gcode manually to fix this bug prior the engraving job as before.
Why don’t give people some extra options, especially if that will allow people with some exotic setups to still use your software, especially if the fix is faster to introduce than discussing why it would be nice to have it.
I don't understand the tone of your messages, but I find it rather arrogant.
The policy I usually apply for requests is that things that are easily achievable without effort I usually welcome and implement them in a short time, especially if I believe they are useful features for most users. But you should understand that this is an open source project developed and maintained by one person, for free. I give you my spare time, have no pretensions please.
Do you have urgency? The source code is here. Download it, you can modify it.
It is the maximum freedom you can expect.
Ps. I would like to make the g-code generation configurable, it's a good thing, but I would like to do it in the best way and this requires rewriting a lot of code. It is already in the develop roadmap.