Specific working mode for CO2 laser on parameter $32!

[Deltaplc]

Good morning
Sorry to bother you....
I don't know if I've discovered hot water.....but I certainly think I've thought of(and tested) a valid solution to solve the problem!
I will try to explain myself with some examples, to help you better understand the problem that occurs when engraving images.
I have a home-made CO2 laser derived from a K40.

Example of engraving a photo in any mode (Stucki, Jarvis, dithering, etc.) except grayscale.

K40 operation "original configuration":
Fragment of a hypothetical gcode:
G1 X2.5F6000 off laser
G1 X0.1 on laser
G1 X20.5 off laser
G1 X0.1 on laser
G1 X2.5 off laser
G1 .....
The potentiometer (manual analog) supplies a constant voltage to the IN pin (pwm) and the board turns the laser beam on and off via the L (enable) pin.
Example of this configuration:
The sniper has his eye on the scope, always aimed at the target, and he only has to pull the trigger to shoot!
Result:
The IN pin is always at the desired voltage and already keeps the power supply "capacitors charged", it just needs to fire!

Custom laser with any board and firmware derived from grbl and with lightburn or lasergrbl software etc...:
Fragment of a hypothetical gcode:
M4
M3
G1 X2.5F6000 S0
G1 X0.1 S200
G1 X20.5 S0
G1 X0.1 S200
G1 X2.5 S0
G1 .....
The voltage on the IN(pwm) pin, varies from zero to S200, and the L(enable) pin, turns the laser beam on and off, following the strategy that depends on the M3/M4.

Example of this configuration:
The sniper must re-center his eye in the crosshairs every time he has to shoot and then pull the trigger!
Result:
The IN pin does NOT have a constant voltage, but varies between zero volts and S200,
the power supply "capacitors are not constantly charged" and when it fires it is not ready to immediately parry at the desired power!
General problem:
Loss of much detail when using dithering, Jarvis or similar methods at high speeds!

My thoughts Changes to be made to the firmware:
On the solution to this problem:

1. $32= 0 = CNC; 1= Laser ; 2= ​​Lathe ; 3=Laser_Co2
2. SPINDLE_ENABLE_PIN = Behavior unchanged, behaves as it does now.
3. SPINDLE_PWM_PIN = M3/M4 S.....= S1 / S1000 pwm regulation, does NOT consider the S0 parameter for pwm regulation.
4. M3 / M4 = Turns off with M5 or M2 command. (Now, if $34 is greater than 1, M3 does not turn off if M5 or M2 command is given!)
5. $34 = Possibility to vary the value from an M(....)S(...) command. In order to adjust and refine the resolution.

Result (already tested):

• The voltage on the IN(pwm) pin remains constant, because it does NOT consider the S 0 value as a power variation! If $34 is
  slightly higher than the desired power, it improves further!
• The laser beam will still turn on and off, using the enable pin (L pin) which will keep the same current working strategy.
• When using the M5 or M2 commands, the laser beam is switched off and made safe!
• It is also possible to refine all this using the function supported by the $34 command, extending the possibility of varying its parameters with M(....)(S....) commands.

I have already tested this type of configuration manually and using the $34 parameter...
The difference in the result on the finished product is truly abysmal!
At the moment it seems to me that no one has a custom configuration for the control of co2 lasers!
In my opinion it is fundamental since the behavior of the laser beam ignition is profoundly different from that of diode lasers!
I hope you can make these changes, because it will bring huge benefits to those who use grblHal to control their custom co2 laser!

I am available if you need to do tests or for anything about it!
Thank you in advance.
Regards

[Deltaplc]

Attached are 2 images engraved with the same parameters (speed 340mm/s power 7.6%).
Number 1 is with the current operating strategies. Number 2 is with the simulation of the operating strategy that I would like you to bring to the firmware! Currently, if I wanted to have a result similar to image 2, the only solution would be to raise the power a lot! But the result would still be terrible and not even comparable!

[Deltaplc]

Hi
I wanted to add another option....
There is a function in ligtburn "use G0 movements for overscan" that could affect the pwm output, since in laser mode M3/M4 do not work with G0 movements!!!
It is likely that if you decide to make the changes I asked you will have to take this into account!
I send you a fragment of gcode in question:
G0 X110.626Y89.399
M3
; Layer C00
G91
G0 X8.333
G1 X0.1F20000S80
G1 X0.1S0
G1 X0.2S80
G1 X0.1S0
G1 X0.1S80
G1 X0.1S0
.......
G1 X0.1S80
G1 X0.1S0
G1 X0.1S80
G1 X0.1S0
G1 X0.1S80
G1 X0.1S0
G1 X0.1S80
G0 X8.334
G0 Y-0.1
G0 X-8.334
G1 X-1
G1 X-0.1S0
G1 X-0.2S80
G1 X-0.1S0
G1 X-0.2S80
G1 X-0.1S0
G1 X-0.3S80
G1 X-0.1S0

[terjeio]

Do you have a DC or RF excited tube? And at what kind of resolution (DPI) at 340 mm/s?

If I understand your proposal you want laser on/off to be controlled by distance in G1 mode, kind of like PPI mode. If less/equal to some distance then turn laser on else turn it off?

[Deltaplc]

Hai un tubo eccitato DC o RF? E a che tipo di risoluzione (DPI) a 340 mm/s?

Hello
It's the classic glass tube with its original k40 power supply....

I did those tests at 254dpi
The picture is small....it was just to show you the difference!

[Deltaplc]

Se ho capito bene la tua proposta, vuoi che l'accensione/spegnimento del laser sia controllato dalla distanza in modalità G1, un po' come la modalità PPI . Se è inferiore/uguale a una certa distanza, allora accendi il laser, altrimenti spegnilo?

No no, it was just an addition to the main request! That is fundamental!
I just didn't know if using G0 could be harmful to achieve the CO2 laser mode as I proposed to you!

[terjeio]

You want S0 to turn off the laser while keeping the PWM output as-is?
If so it seems I have implemented the spindle code incorrectly and a simple else will correct it. That is with RPM controls spindle enable signal enabled in the settings:

Which driver are you using?

[Deltaplc]

Good morning
At the moment I'm using an Arduino Due.(SAM3X8E)
But I'm also testing a board with esp32.....

[Deltaplc]

Vuoi che S0 spenga il laser mantenendo l'uscita PWM così com'è?

Yes exactly, you should only deactivate the enable output, without modifying the PWM!

Se è così, sembra che abbia implementato il codice del mandrino in modo errato e un semplice elselo correggerà. Questo con il segnale di abilitazione del mandrino dei controlli RPM abilitato nelle impostazioni:

I tried to see if one of these options would work for me, but at the moment none of them do what I need.
There are these options: 0-1-3-5-7 ? There are no others, right?

[terjeio]

$9=3 or $9=7 is what you need - $7, And $32=0 for now. I have modified the Web Builder code so you have to flash a fresh version, if you build locally you have to change a function.
FYI M5 will currently not turn the PWM off - more changes has to be made for that.

[Deltaplc]

I cloned:
git clone --recurse-submodules https://github.com/grblHAL/SAM3X8E.git

I compiled and downloaded successfully with arduino ide...
I tried with $32=0 and $9 = 3 or $9=7...... But none of them do what I need! The pwm does not stay stable at the same level when the enable output changes to on/off.....

$7,
I don't have the $7 parameter!?
Am I doing something wrong?

[terjeio]

git clone --recurse-submodules https://github.com/grblHAL/SAM3X8E.git

I have updated the Web Builder, not github. Replace this function in driver.c if compiling locally:

static void spindleSetSpeed (spindle_ptrs_t *spindle, uint_fast16_t pwm_value)
{
#ifdef SPINDLE_PWM_CHANNEL
    if (pwm_value == spindle->context.pwm->off_value) {
        pwmEnabled = false;
        if(spindle->context.pwm->settings->flags.enable_rpm_controlled) {
            if(spindle->context.pwm->flags.cloned)
                spindle_dir(false);
            else
                spindle_off();
        } else if(spindle->context.pwm->flags.always_on) {
            if(PWM->PWM_SR & (1 << SPINDLE_PWM_CHANNEL))
                PWM->PWM_CH_NUM[SPINDLE_PWM_CHANNEL].PWM_CDTYUPD = spindle->context.pwm->off_value;
            else {
                PWM->PWM_CH_NUM[SPINDLE_PWM_CHANNEL].PWM_CDTY = spindle->context.pwm->off_value;
                REG_PWM_ENA = (1 << SPINDLE_PWM_CHANNEL);
            }
        } else
            REG_PWM_DIS = (1 << SPINDLE_PWM_CHANNEL);
    } else {
        if(PWM->PWM_SR & (1 << SPINDLE_PWM_CHANNEL))
            PWM->PWM_CH_NUM[SPINDLE_PWM_CHANNEL].PWM_CDTYUPD = pwm_value;
        else {
            if(spindle->context.pwm->flags.cloned)
                spindle_dir(true);
            else
                spindle_on();
            pwmEnabled = true;
            PWM->PWM_CH_NUM[SPINDLE_PWM_CHANNEL].PWM_CDTY = pwm_value;
            REG_PWM_ENA = (1 << SPINDLE_PWM_CHANNEL);
        }
    }
#else
    if (pwm_value == spindle->context.pwm->off_value) {
        pwmEnabled = false;
        if(spindle->context.pwm->settings->flags.enable_rpm_controlled) {
            if(spindle->context.pwm->flags.cloned)
                spindle_dir(false);
            else
                spindle_off();
        } else if(spindle->context.pwm->flags.always_on) {
            SPINDLE_PWM_TIMER.TC_RA = spindle->context.pwm->period - spindle->context.pwm->off_value;
            SPINDLE_PWM_TIMER.TC_CMR &= ~TC_CMR_CPCSTOP;
            SPINDLE_PWM_TIMER.TC_CCR = TC_CCR_CLKEN|TC_CCR_SWTRG;
        } else
            SPINDLE_PWM_TIMER.TC_CMR |= TC_CMR_CPCSTOP; // Ensure output is low, by setting timer to stop at TCC match
    } else {
        SPINDLE_PWM_TIMER.TC_RA = spindle->context.pwm->period == pwm_value ? 1 : spindle->context.pwm->period - pwm_value;
        if(!pwmEnabled) {
            if(spindle->context.pwm->flags.cloned)
                spindle_dir(true);
            else
                spindle_on();
            pwmEnabled = true;
            SPINDLE_PWM_TIMER.TC_CMR &= ~TC_CMR_CPCSTOP;
            SPINDLE_PWM_TIMER.TC_CCR = TC_CCR_CLKEN|TC_CCR_SWTRG;
        }
    }
#endif
}

I'll update github if this works as intended - after changing all the other drivers to match. And likely with further changes.

And please post comments in english, if not I will respond in burmese or something like that when I can be bothered...

[Deltaplc]

And please post comments in english, if not I will respond in burmese or something like that when I can be bothered...

Sorry!!! In my hurry I forgot to translate it!!
Now I'll try and let you know!

[Deltaplc]

I have done some field tests with my engraver.....
With:
$32=0
$9=3 / $9=7 (Nothing seems to change between the two configurations 3 or 7)
The machine keeps the pwm constant and works with the enable pin on/off as I would like!!! But the machine goes very slow and if it receives G0 commands it does not turn off the laser.

With:
$32=1
$9=3 / $9=7 (Nothing seems to change between the two configurations 3 or 7)
The machine keeps the pwm constant and works with the enable pin on/off as I would like!!! It seems to work fine with the image engraving speeds as before. And it also works fine with G0 commands by turning off the enable pin.
Even with the LB_CLUSTERS mode enabled everything seems ok.

With the new change, in any case, the $34 parameter does NOT work anymore!! Changing its value does NOT make any changes!!
As you said, the M5 command does not turn off the PWM at the end of the processing.

So, with $32=1 and $9=3 it seems to have worked!
If you can get the $34 function to work as well, that would be awesome....

[terjeio]

Replace driver.c with this version, with luck it may work:

driver.zip

There is a function in ligtburn "use G0 movements for overscan"

Overscan should be G1S0 motion with the same feedrate as engraving to ensure the PWM output does not change on the G0/G1 transition when laser mode is enabled. And the overscan distance should be large enough to let the PWM output to go to the programmed rate (at the end of acceleration).

With the new change, in any case, the $34 parameter does NOT work anymore!!

Perhaps the attached version does, if not how do you expect it should work?

[Deltaplc]

Hi
I tried to do some tests, but unfortunately I don't see any changes in the functioning, it seems to work as with the previous modification.
The $34 parameter seems NOT to work!!
Tomorrow morning I'll do more in-depth tests and let you know in more detail!!
Thank you for your support!