$32=1 and laser still fires between cuts

[RenanSP (Renan)]

Hi! After updating from 1.4.03 to 1.4.04, coincidentally (or not), a problem I never had before appeared. It’s the classic “laser not turning off between cuts” but with a twist: as I just triple checked, I still have “$32=1”, as I always had.
I tried to no avail:

• Setting “$32” it to 0 and back to 1
• Reverting to version 1.4.03
• Restarting PC and cutter

It doesn’t always happen, though. For a file with just two engraved lines, I managed to trigger it at will by changing the “Number of Passes”, as shown in the image. With a single pass, the problem manifests itself. With two passes, the engraving is done correctly.

Does someone have a clue what I should try? Thanks!

[berainlb (PY)]

The upgrade is unlikely to have had anything to do with the issue. Downgrading and having the same issue is fairly conclusive proof of that.

Here’s what I would suggest checking:

1. Make sure that S Value Max in Edit Device Settings is in fact 1000. This shouldn’t cause the issue at hand in either case but good to validate.
2. Check the g-code to confirm that LightBurn isn’t command the laser on during the traversal move. Upload here if you’re not sure how to do this.
3. I suspect a hardware failure. Likely laser module but could also be the controller. Check voltage on PWM pin of controller during traversal moves. You should get 0V there. If so, failure is likely in laser module.

[RenanSP (Renan)]

Great insights. Thanks, Berainlb!

1. S-Value is 1000 both in Lightburn settings and in the cutter controller, as shown in the image below.

2. Could you help me interpret the G-code shown in the image below?
3. I will test that very soon!

[berainlb (PY)]

@RenanSP

• Could you help me interpret the G-code shown in the image below?

G-code looks fine. The relevant lines are the ones with the S values. You’re asking for 80% power. The traversal line that’s getting burned is G0 X0Y-3.726. The G0 makes it a rapid move. It should not burn as long as you’re in laser mode and using M4.

This rules out a LightBurn issue.

Looks like this will be a hardware issue…

[RenanSP (Renan)]

3. The whole cutting process takes only 200 ms from start to end, and the PWM signal entering the laser module was entirely captured in the scan below. At no moment was the duty cycle 0%, as it should be during the single transversal/rapid move between the two engraved lines. The PWM signal being emitted from the controller caused the inadequate cut. But what caused the inadequate signal created by the controller? Could my GRBL controller have the wrong settings saved, or is it a hardware problem?

By the way, as my cutter runs on GRBL 1.5D (according to LaserGRBL) I use the default “GRBL” controller inside LigthBurn, which allows for M4 (dynamic power). When I zoom in on the captured signal (figure below), I can see the duty cycle developing to higher values as the laser head accelerates.

[MikeyH (Mike Hembrey)]

Nice DSO images. Was that the input or output at the laser module controller board. That is the tiny one typically on the top of the laser module. The input scan will tell if it is the CNC controller telling the laser board to fire, or the board is firing on its own.

[RenanSP (Renan)]

I probed the INPUT of the laser module controller board. That is, the long yellow wire between the big controller board and the tiny laser board. As I interpret it, the laser is firing because it’s being told to by the controller. The controller is receiving a rapid movement command (G0) on the G-code, yet it is sending pulse signals during said movement.
Is there any GRBL setting that could mess with those things?

[Dskall (D Kallenberger)]

@RenanSP

GRBL 1.5D

Never heard of that version.

[RenanSP (Renan)]

Neither did I. And the plot thickens.

[MikeyH (Mike Hembrey)]

@RenanSP

Is there any GRBL setting that could mess with those things?

Only $31, which should be zero.

@RenanSP

As I interpret it, the laser is firing because it’s being told to

I concur.

@Dskall

Never heard of that version.

Any chance the manufacturer did that to mark their own version?

[RenanSP (Renan)]

@MikeyH

Only $31, which should be zero.

$31 is zero. Checked, rewrote, rechecked, and retested.

@MikeyH

Any chance the manufacturer did that to mark their own version?

I am inclined to believe so.

New things I tried:

• Using M3
  Activating “constant power” mode on LigthBurn indeed makes the PWM duty cycle constant at approximately 80%, but the controller still does not turn it off during rapid movements (G0).

• Experimenting with G-code.
  I managed to trigger the problem with a single command. The sad part is that it is an important one (G1).
  

  

Guys, I believe there is something very wrong with my controller. Be it software or hardware, it is probably beyond my expertise, and I would do better getting in touch with their support. Right?

[MikeyH (Mike Hembrey)]

You have pretty much made it obvious it is the controller board. Warranty, I hope!

[berainlb (PY)]

@RenanSP

I can see the duty cycle developing to higher values as the laser head accelerates.

That’s good to see it actually working.

@RenanSP

3. The PWM signal being emitted from the controller caused the inadequate cut. But what caused the inadequate signal created by the controller? Could my GRBL controller have the wrong settings saved, or is it a hardware problem?

This i most likely a hardware fault. But it could also be a corrupt firmware. You may want to try reflashing the firmware to see if that resolves the issue.

@RenanSP

I managed to trigger the problem with a single command. The sad part is that it is an important one (G1)

Sounds like to me that once the command is sent it triggers this state and can’t bring the signal back down. Perhaps a failed pull-down resistor.

[RenanSP (Renan)]

@berainlb

This i most likely a hardware fault. But it could also be a corrupt firmware. You may want to try reflashing the firmware to see if that resolves the issue.

@berainlb

Sounds like to me that once the command is sent it triggers this state and can’t bring the signal back down. Perhaps a failed pull-down resistor.

Both are great suggestion. I will investigate them.

[RenanSP (Renan)]

For easier capture, I made all movements shorter (0.5mm instead of 3mm) and increased power to 100% to get rid of the PWM.
I still can’t point out the origin of the problem, but I suspect that through software I can patch it: adding a “S0” command (zero power) before a “G0” (transversal move) fixes the engraving during rapid movements.

I wrote a script to patch my G-codes while I search for the problem. What a weird problem!

[gilaraujo (Gil Araújo)]

This might be some electronic “noise” on the Laser driver itself.
From what you showing the motherboard/Controller is doing what its being asked to do.
But remember the laser head has electronics too: depending on the components used the response time of the laser driver might be sub optimal

what you could do here is try the reverse test… Make sure the rapid movement is longer and see if after a longer time (as long as practical) the laser does turn off completely.
Might need to do some Gcode editing magic to get this done right

I am not an electronics engineer, but I have seen some crazy stuff. A wrong component, a wrong cap selection and you get this weird behavior.

Of course, if you had access to a different laser head you could drive with same controller would be the best of tests.

[berainlb (PY)]

@RenanSP

I still can’t point out the origin of the problem, but I suspect that through software I can patch it: adding a “S0” command (zero power) before a “G0” (transversal move) fixes the engraving during rapid movements.

If the controller is able to cut-off power with an S0 then it could very well be a firmware fault. Worth exploring.

[Dskall (D Kallenberger)]

I would reflash firmware.

[RenanSP (Renan)]

Final Chapter:

• My g-code-patcher script performed fine throughout the entire day.
• As suggested by berainlb and Dskall, I reflashed the firmware with the latest available version, but the problem continued.
• As suggested by berainlb and gilaraujo, I searched for defective components, but found none. Instead, I noticed that the board layout was simple, the traces were easy to follow, and that it was based on the microcontroller ESP32. So I mapped the GPIOs to a configuration file for a new compatible firmware, FluidNC, and the problem was gone!

I may never know the cause of the problem, but we found a definitive solution.
Thanks everyone!

I’m sure better tuning can be achieved, but I will leave below my current FluidNC configuration file for anyone with a Zbaitu 20W M81-VF20 laser cutter having problems with laser activating during transversal movements in spite of having $32=1.

name: Zbaitu 20W M81-VF20
board: ESP32 Controller
meta: config_renan
start:
  must_home: false
  deactivate_parking: false
axes:
  shared_stepper_disable_pin: gpio.12
  shared_stepper_reset_pin: NO_PIN
  x:
    steps_per_mm: 80
    max_rate_mm_per_min: 8100
    acceleration_mm_per_sec2: 700
    max_travel_mm: 713
    soft_limits: true
    homing:
      cycle: 1
      positive_direction: false
      mpos_mm: 0
      seek_mm_per_min: 1200
      feed_mm_per_min: 50
    motor0:
      limit_all_pin: NO_PIN
      limit_neg_pin: gpio.13:pu:low
      limit_pos_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 2
      stepstick:
        step_pin: gpio.14
        direction_pin: gpio.27
        disable_pin: NO_PIN
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: NO_PIN
  y:
    steps_per_mm: 80
    max_rate_mm_per_min: 8100
    acceleration_mm_per_sec2: 700
    max_travel_mm: 437
    soft_limits: true
    homing:
      cycle: 1
      positive_direction: false
      mpos_mm: 0
      seek_mm_per_min: 1200
      feed_mm_per_min: 50
    motor0:
      limit_all_pin: NO_PIN
      limit_neg_pin: gpio.39:low
      limit_pos_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 1
      stepstick:
        step_pin: gpio.26
        direction_pin: gpio.25:low
        disable_pin: NO_PIN
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: NO_PIN
    motor1:
      limit_all_pin: NO_PIN
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 1
      stepstick:
        step_pin: gpio.33
        direction_pin: gpio.32
        disable_pin: NO_PIN
        ms1_pin: NO_PIN
        ms2_pin: NO_PIN
        ms3_pin: NO_PIN
stepping:
  engine: RMT
  idle_ms: 255
  pulse_us: 3
  dir_delay_us: 1
  disable_delay_us: 0
spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18
sdcard:
  card_detect_pin: NO_PIN
  cs_pin: gpio.5
Laser:
  output_pin: gpio.17
  disable_with_s0: false
  s0_with_disable: true
  speed_map: 0=0% 1=1.2% 250=27% 500=51% 750=76% 1000=100%
  enable_pin: NO_PIN
  pwm_hz: 1000

PS: For future-proofing, do not simply copy and paste these parameters. Instead, use it as a reference to answer the configuration assistant interface that will create your “config.yaml” using the most recent layout.

[berainlb (PY)]

Nice work.

Although I’m struggling to understand the fix. If this used to work before, then started failing, and reflashing the firmware didn’t fix the issue but flashing a new firmware from FluidNC entirely did fix the issue then I have to think that either the original reflash didn’t work correctly or the new firmware is masking the real issue. Or possibly FluidNC has different tolerance levels configured for how it works.

I’m wondering if the flashable storage is actually damaged at a particular location and FluidNC isn’t using that area for PWM control…

In any case, glad you got it working again but I’d advise looking out for other gremlins that might pop up.