S-MIN does not apply for fast G0/G1 travel via blank part of the job

[ElfyShort]

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

[ElfyShort]

M3 works just fine as I am controlling the laser power by PWM. 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.   Conveniently enough I found S-MIN option which would have solved my problem, if only it would do what I thought it should :).   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. 

Sunday, October 25, 2020 12:36 AM +02:00 from Stuart notifications@github.com:     Use M4 instead of M3 in target image settings. M3 is more for cutting than engraving. What's the relay you mentioned, is that what you use to turn the laser on and off. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe . Sincerely, ElfyShort

[StuartB4]

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.

[ElfyShort]

I tried that as well. With M4 ruling ball I get the same result. Thank you for trying to help me to fix my setup, but it does not require the fix. 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?   Here is the g-code generated with $32=1 and S-MIN = 4:   G90 (use absolute coordinates) G1 X-15 Y-15 M4 S0 F330 G1 X0.7 Y-14.95 S0 G1 X0.65 S8 X0.6 S16 X0.55 S6 G1 X0.4 Y-14.9 S0 G1 X0.45 S8 X0.5 S32 X0.55 S53 X0.6 S64 X0.65 S71 X0.7 S66 X0.75 S54 X0.8 S29 X0.85 S5 G1 X0.9 Y-14.85 S0 G1 X0.85 S5 X0.8 S39 X0.75 S76 X0.5 S100 X0.45 S80 X0.4 S55 X0.35 S36 X0.3 S18 G1 X0.15 Y-14.8 S0  

Sunday, October 25, 2020 2:06 AM +01:00 from Stuart notifications@github.com:     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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe .  

[gmmanonymus111]

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

[ElfyShort]

This has nothing to do with a machine  or GRBL. The problem is that the LaserGRBL creates a gcode with S0, even after I tell it rescale from S-MIN to S-MAX.   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. Have a nice day.  

Sunday, October 25, 2020 12:55 PM +01:00 from Alex notifications@github.com:     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 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or unsubscribe .

[arkypita]

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.

[arkypita]

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.

[ElfyShort]

Thank you for clarifying some of the things for me.   «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.»   That’s exactly my point. The laser I am using is not lasing until S4, so there is no difference whether it is S0 or S3.   «A laser diode is a switching/pulsed instrument, 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.»   What you said is true, of course, however I have never mentioned my laser is diode based. For any other types of lasers it is important to preheat the cavity beforehand in order to reach the stable operating power and keep it on during the whole process if it is important to get a consistent result. Most of the lasers like Nd:YAG, CO2 or Carbon monoxide using a discharge lamps or an auxiliary seed laser in order to excite the cavity. Therefore drivers for such lasers are doing some custom stuff depends from that PWM signal it receives.  The laser I am utilizing turns that secondary seeding laser of on every S0 command, so the next carving line has delayed turning on dynamics and has lower power output in general (since that previously excited electron level that used to lase with established population inversion has now no electrons to create those photons we want so much).   Besides most of the materials people used to carve or engrave have certain damage threshold and processing them with low power (of couple of mW) has no visible effect, though it helps to keep the laser lasing.   Whatever my motivation is, a simple feature like a checkbox «using S-MIN to skip white areas instead of S0» would allow to still use this software in case your setup is equipped with some custom lasers which require some extra care/attention.   «A laser diode can be switched off by simply send a "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.»   I addition to that my laser is installed on a CNC machine which is turning that relay off as it receives S0, which has no influence on the laser and just making noise. For a heavy duty CNC I found it necessary to cut off the spindle current when it receives S0. A laser main power is not controlled by that relay therefore there is nothing to fix — it is just a setup attribute.  Such a checkbox will also solve this. Two birds with one stone. (It also could be a separate feature like "S_BLANK" which will be used instead of that S0 while crossing white sections. Reusing S-MIN is just easier to implement, i think).   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 (though I understand that it is important for you to know why it is useful)?   Sincerely, ElfyShort

[arkypita]

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.

[arkypita]

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.

[ElfyShort]

I did not mean to disrespect anyone, especially the person who has made such a nice peace of software. Furthermore I would not have spent so much time on this conversation if I wouldn't like the software and wouldn't want to share my user experience with a developer who can make it even better!   «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.»   This I wrote because I was losing hope in explaining that I do not need help in fixing my setup and just want to propose a feature. It was like I was asking one thing and get answer about smth I did not asked.   «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.»   This was a rhetorical question and a manner of speech. The country I am from it used very often.   Regarding why I cant Download and modify it is that I wrote a licence agreement under which the software is distributed.  The fist line forbids so.   Besides I am a java/C/python guy, don’t even know what kind of language has been used in this case.   At least You have heard me, and if the idea will be implemented in the next n months — that will be wonderful.   Thank you!   Sincerely, ElfyShort