OMTech K40+ SH-G 3020 + Cohesion3D Mini: Laser won't fire under Smoothieware control (PSU: ZYE MYJG50W)

Brian6 · August 22, 2026, 4:25pm

Software: LightBurn, device profile set to Smoothieware. Controller: Cohesion3D Mini, converted from the stock OMTech GD32F303-based mainboard. Machine: OMTech K40+ SH-G 3020. PSU: ZYE Laser MYJG50W (AC 110V/220V).

Motion (X/Y, endstops, homing) is fully working through LightBurn - this post is only about the laser refusing to fire.

What’s confirmed working

Cohesion3D Mini fully installed and functioning: motors, endstops (X-MIN/Y-MIN), and homing all correct.
PSU’s physical Test Fire button reliably fires the laser - confirmed via ammeter (17mA) - so the PSU, tube, and HV stage are healthy.
Cohesion3D’s P2.4 output is proven live: continuity-tested from the “K40 PWM Output” 3-pin connector back to the P2.4 MOSFET4 header, and the pin’s voltage measurably changes on command.

PSU terminal layout (6-pin block)

Silkscreen reads, left to right: G1 / P / L / G / IN / 5V

What’s been tried

IN alone, PWM driven from Smoothieware’s laser_module (P2.4), power level set via laser_module_maximum_power 0.8. No reaction on the PSU’s “Laser Signal” panel indicator, 0.0mA.
L + G, driven via Smoothieware’s switch module (M3/M5, active-low). Panel’s “Laser Signal” indicator DOES light correctly and toggles reliably with M3/M5 - but ammeter stays at 0.0mA regardless.
Direct bare-wire jumper, L to G (Cohesion3D fully disconnected) - same result: Laser Signal indicator lights, but 0.0mA on the ammeter. This strongly suggests the panel’s “Laser Signal” indicator only reflects “something detected on L,” not genuine firing - it lit under every test today, including ones that produced zero current.
P + G1, both via a direct bare-wire jumper and via Smoothieware - no reaction at all (not even the Laser Signal indicator).
Checked the machine’s physical laser-current potentiometer, which connects to the PSU’s IN terminal via a small panel PCB (has its own chip/circuitry, not a simple 3-wire pot) over an RJ45-style cable. Confirmed:
- RJ45 cable tests fully continuous end to end.
- Turning the main panel dial produces no measurable voltage change on IN at the PSU end.
Found a second, small red button directly on the panel PCB (near the RJ45 connector) that DOES reliably fire the laser at low but real power (confirmed via ammeter, non-zero mA). Measured IN’s voltage during this: idle 4.26V, pressed 0.68V - a real, working reference for what a “firing” IN signal looks like on this PSU.
Wired a second Cohesion3D output (P2.5, via the FET1 screw terminal’s “-” position) to IN, alongside L (already working per indicator). Tried both inverted and non-inverted PWM, various S-values (S1, S0.3) - Laser Signal indicator lights, but ammeter stays at 0.0mA throughout, and IN itself reads a flat 0V regardless of S-value when measured with a basic multimeter (likely just reading the PWM average, not able to characterize the actual waveform).

Current working theory

The panel’s small button (point 6 above) proves the PSU CAN be triggered externally and produces real current at a specific IN voltage/waveform. But we haven’t been able to replicate that exact signal from Smoothieware - a basic multimeter can’t fully characterize what that panel button’s chip is actually outputting on IN (could be a specific analog level, a particular PWM frequency/duty cycle, or a short data pulse rather than simple PWM).

Questions

Has anyone connected a Cohesion3D Mini (or similar Smoothieware board) to this exact PSU (ZYE MYJG50W) or a similar OMTech K40+ SH-G panel/PSU combo?
Is there a known correct combination of pins/signals for reliable external firing on this PSU - specifically, what should Smoothieware output on IN (voltage level, PWM frequency) to replicate what the panel’s own button/chip produces?
Could the panel’s chip-based pot/button assembly be sending something more complex than simple PWM on IN?

Happy to provide additional photos, my Smoothieware config, or run further tests. Thanks in advance for any insight.

jkwilborn · August 22, 2026, 6:43pm

The laser power supply (lps) requires two control lines. The pwm is usually wired to the IN terminal. There is an L terminal, which is laser enable, it must go low to enable the lps must be held low if the you want it to lase.

This is my 60W, I don’t have a control knob. This became of interest but it was resolved that it only changes the IN voltage. If you’re worried about it, leave it unplug. It only reduces the current control voltage, can’t make it any higher.

The IN terminal is the lps current adjustment and needs to be ttl compatible or 0 to 5V swing in voltage. This can be either a pwm or analog control. The actual pwm is converted internally to a DC voltage to control current. It doesn’t matter what the period of the pwm is, as long as it’s not too slow to causes pulses in the tubes output.

Many of the 32 bit controllers have 3.3V systems and there needs to be a conversion to convert it to 5V for the pwm.

I know my DSC32 isn’t really directly compatible with these supplies as the grbl controllers are generally for led diodes and don’t even create the laser enable signal. These seem to be handled by a laser enable front panel switch to enable the laser. I put my DLC32 board in mine for a short period, but it to work, it was a learning experience, but wasn’t really worth the effort.

It then uses the pwm to turn it off and on.

Suggest you find us a schematic link to your board and how it’s supposed to interface to that supply. I did a quick check but most of the time, they are difficult to locate.

Just a setup wiring wise of your control board with the new lps would be great.

Of the things you checked, you missed the L, P inputs. L is laser enable and P is water protect.

I have a hard time reading what you say because I have no idea of it’s schematic, so device reference are difficult for me to handle.

There are lots of people here with the ability to help. If you have any issues or problems, sing out.

Good luck.

Brian6 · August 23, 2026, 7:45am

Thanks Jack, this is really helpful context - especially the note about 3.3V vs 5V TTL levels, since that’s something I hadn’t considered and may be exactly my issue.

**Wiring setup (my board is the Cohesion3D Mini, not the LaserBoard):**

- **L**: wired to the Mini’s “K40 PWM Output” connector (board’s own label; center pin is P2.4). Driven via Smoothieware’s switch module (M3/M5, active-low). Confirmed via direct bare-wire jumper test that L->G on the PSU does complete some circuit (Laser Signal LED lights) but produces 0mA on its own.

- **P**: tried directly jumpered to G1 (water protect line per your note) - no reaction on the panel at all, LED or otherwise.

- **IN**: tried both from the Mini’s generic FET1 (P2.5) screw terminal and from P2.4 via PWM (laser_module, various S-values) - Laser Signal LED lights (via L), but 0mA throughout, and IN itself measures flat regardless of S-value on a basic multimeter.

**What I haven’t tried yet, and suspect may be the actual issue given your point about 3.3V logic**: the LPC1769 on the Mini is a 3.3V part. I’ve been driving IN from generic FET screw terminals (P2.4/P2.5), which I believe output unshifted 3.3V logic, not a true 5V swing. The board also has a separate, dedicated “K40 PWM” 3-pin header (Sig/5V/Gnd) that I originally had L wired to before moving L elsewhere - I haven’t yet tested whether THAT specific header includes any level-shifting circuitry that the generic FET pins lack.

Does anyone know if the Cohesion3D Mini’s dedicated K40 PWM header does any 3.3V->5V conversion, or is it just a direct breakout of the raw GPIO pin like the FET terminals? If it’s level-shifted, that would explain everything - I’ve never actually tested IN through that specific header while L is simultaneously held low elsewhere.

Also worth noting: the machine has a small daughterboard behind the front panel dial that appears to be a DAC (has its own chip, not a simple 3-wire pot) feeding IN via an RJ45-style cable. Turning the dial produces no measurable change on IN, but a small red test button on that same daughterboard does fire the laser at low real power (confirmed via ammeter). I haven’t been able to identify the chip on that board yet - if it rings a bell for anyone who’s dealt with OMTech’s K40+ SH-G panels specifically, I’d be glad to hear it.

Appreciate the help - will report back once I’ve tested the dedicated PWM header properly.

jkwilborn · August 23, 2026, 4:46pm

I found your board, but can’t find a schematic to it. Can you post the schematic link and also a link to the configuration you’re using?

Co2 tubes are linear devices, unlike led and RF metal tubes. A laser other than a glass tube laser generally runs at whatever you ask it to for however long. You can set it to run at 50% forever.

An led or RF machine follows the PWM as far as turning off/on. If you want 50% with an led or RF laser, it’s driven by a 50% pwm signal. It’s on as long as it’s off.

What they do with the K40 types is to set the tubes highest current through the console. The treat it like a diode or RF laser.

Personally, I think it wrong to have an analog device that’s turning it off/on to get the amount of laser you want.

You indicate this by your attachment of PWM to L. If you’re going to use this method, wire it to H, which is the inverted L input. If you don’t you’re power will be upside down, unless the board you have can change that.

What I did on mine was wire the L to a front panel switch and the pwm to the IN terminal. There should be no PWM generated when it’s not lasing. I can enable it for the whole run without issues and I’m still controlling it’s current. You are not controlling the current they way you think.

Meters show an RMS value. If you hook up a 5V meter at 100% pwm, it will read 5V, however, change it to 50% pwm, it will read 2.5V and you know that’s not the correct voltage. Even though the signal has a 5V range.

If you have a mA meter, you will read on it, whatever RMS current is. So even set to 50% it will read 50% of the current duration. Setting it to 50%, does not set the laser to 50% power, every time it lases, it does so at 100% power, even though it reads 50% power. Like an RF or diode laser.

Hope this makes sense?

I’m tired and will probably retire to bed soon, Gave up on finding a schematic for this board.

If you can post a schematic and a good photo of the boards connections, it will make more sense to me and others.

You can use the L terminal, like I did and run it to the laser enable on the console. The problem with this is you can’t really pulse it unless the controller can do that.

Good luck, be back in a bit.

Brian6 · August 23, 2026, 6:31pm

Thanks Jack, this makes sense and is really useful background on how the CO2 tubes actually respond to PWM vs LED/RF.

One clarification on my setup though: my G-code sequence already does hold L low for the whole job, not toggled per move - M3 is sent once at the start (arms L low via Smoothieware’s switch module), then a series of G1 moves happen (which is when Smoothieware’s native laser_module PWMs IN), then M5 once at the end (releases L). So structurally this should already match what you’re describing - L isn’t pulsing per-move, it’s held low for the whole span between M3 and M5.

Re: H vs L - my board’s terminal block only has G1/P/L/G/IN/5V, no H option, so that’s not available on this unit.

Your point about the mA meter showing RMS/duty-cycle current is really helpful context. That’s actually what makes my 0.0mA reading odd - even at a partial PWM duty cycle (I tried S0.3, ~30%) with L confirmed low, I’d expect to see SOME current if everything were wired correctly, not a flat zero. That reinforces something I raised in my first post: my board (Cohesion3D Mini, LPC1769, 3.3V logic) may not be outputting a strong enough voltage swing on IN - I’ve only tested from generic FET screw terminals so far, not the board’s dedicated “K40 PWM” header, which I suspect (but haven’t confirmed) may include level-shifting to a true 5V swing. That’s the one variable I haven’t isolated yet.

I don’t have a formal schematic (Cohesion3D’s site is down for me), but I do have a detailed unofficial pinout diagram that matches my board’s actual silkscreen, and my current config.txt.

Appreciate you sticking with this - will report back once I’ve tested the dedicated PWM header with L and IN both live together.

config_K40_cohesion3d_marked-up_16.txt (26.9 KB)

ednisley · August 23, 2026, 7:47pm

Until the tube fires, there’s no tube current.

That means the power supply is seeing (at most) 3.3/5 of the intended PWM voltage, so 30% translates into 20%, which may not be enough to fire the tube.

Given it’s a K40-ish machine, using that header seems prudent.

jkwilborn · August 23, 2026, 7:50pm

I see that on the board layout. However you earlier you posted. Did you change that?

What makes you think it’s actually lasing? I doubt it’s lasing at all. These usually draw a few ma when starting to lase. I think it’s more ‘likely’ that you’ve got your signals crossed over somewhere.

The P, L pulled to ground and IN terminal needs to have a dc (pwm) current control signal, before it will lase. If you don’t have all of these together, it won’t lase.

The tube should glow a pinkish color when it’s lasing. You will see current, if it’s lasing along with the color.

Although moot at this point, the H input is on the lps. If you drive the laser with pwm it’s usually right side up, meaning a 30% pwm upside inverted is a 70% pwm.

From your configuration file, this, area in red, makes me wonder what exactly they mean.

If you can find a schematic, I’d love to peruse it.

If you have any more questions, sing out.

jkwilborn · August 23, 2026, 7:52pm

don’t follow you here, there should be no current until it conducts. There is a starting current, but he should see that.

There are two…

ednisley · August 23, 2026, 9:19pm

I tried an experiment:

Set manual pulse to Continue
Set power to 7%
Press-and-hold Pulse button
- Tube does not fire (as expected)
- Meter shows 0.0 mA
Set power to 9%
Press-and-hold
- Tube fires (as expected)
- Meter shows 2.0 mA

So in the K40 case, if whatever analog voltage the 3.3 V PWM signal demodulates into isn’t high enough to fire the tube, then the meter will show 0 mA. The tube is probably conducting a few microamps, but not enough to trigger lasing breakdown.

Trying a higher PWM value might produce interesting results, although the interaction between PWM frequency, power supply demodulation filter behavior, and voltage levels remains unknown.

jkwilborn · August 23, 2026, 9:49pm

I think it’s 200hz, my dsp is 20khz, I’d target it to 1kHz we know that works, then is shouldn’t matter.

ednisley · August 23, 2026, 9:57pm

I meant the power percentage, not the frequency: a higher power percentage than 30% might suffice to fire the tube.

I’d lay long odds the power supply PWM demodulation filter has the same 200-ish Hz corner frequency as the one I measured.

jkwilborn · August 24, 2026, 5:53am

Wouldn’t be a bad idea to try.

Brian6 · August 24, 2026, 3:49pm

Thanks both - lots of useful detail here, let me try to address everything.

**Jack - re: the highlighted config section and “did you change L wiring”**

That’s `laser_module_pin 2.5!` - the `!` inverts P2.5, which is the pin I was using for IN (not L - L is still separately configured via the switch module, unchanged, still on P2.4/the K40 PWM Output connector). I added the inversion because a separate test (a small button on the machine’s panel PCB) showed IN reads ~4.26V idle and ~0.68V when that button fires the laser at low power - so I inverted P2.5 to try to replicate that “low = more power” behaviour on IN, same logic as L’s active-low enable.

So to be clear on current state: **L hasn’t changed** - still P2.4, still confirmed toggling correctly via M3/M5. What’s changed is I added a *second* signal on P2.5 for IN, tested alongside L, rather than L alone.

**Jack - re: P + L + IN needing to be together**

Good catch, and I don’t think I’ve actually tested this combination yet. I tried P alone (no reaction), and I’ve tried L+IN together, but never P+L+IN simultaneously. I’ll wire P permanently to G1 (water protect satisfied) as a baseline and re-test with L+IN active on top of that.

**Jack - re: tube glow**

Will watch for that specifically on the next test - hadn’t been checking for that visually, just the ammeter.

**Ed - re: the threshold experiment**

This is really useful - a real threshold rather than a linear response makes a lot of sense of my results. Here’s the wrinkle though: when I tried `S1` (100%, max commanded power) with the P2.5 inversion in place, IN measured a **flat, static 0V** on my meter - which is already lower than the panel button’s confirmed-working 0.68V “firing” reading. If a static 0V (more extreme low than what the button achieves) still produced 0.0mA, I’m not sure “try higher power” alone will get me there, since I’d already have achieved a more extreme low-voltage condition than the one that’s proven to work.

Unless a static/constant 0V behaves differently to the PSU’s demodulation filter than a genuine PWM signal averaging near 0V? I don’t have a scope to check whether my “S1 inverted” setting is actually producing a real PWM waveform averaging to ~0V, versus just latching the pin permanently low (which might read as 0V on a meter but not be a valid PWM signal the demodulation filter can process the same way).

**Plan for next test**: P wired to G1 (permanent), L via switch module (M3/M5, confirmed working), IN via laser_module on P2.5 - but this time I’ll try a range of power values (not just S1) while watching the ammeter AND the tube for the pinkish glow, and double check inversion polarity carefully given Jack’s point about a 30% inverted becoming a 70% - want to make sure I’m not accidentally testing the wrong end of the range.

Still no luck finding a formal schematic - Cohesion3D’s site remains down for me. Diagrams and config posted above are the best I’ve got. Will report back with results.

ednisley · August 24, 2026, 4:43pm

From what I’ve measured on a Ruida KT332N (a completely different controller), 99% produces exactly what it says on the tin: a PWM signal (the cyan trace) high 99% of the time:

However, a meter would probably show that as very close to 5 V, where a 1% difference = 50 mV from the actual power supply voltage (i.e. not an exact 5.000 V) might be vanishing small.

Conversely, a 0% output really is low all the time.

An inverted output would show essentially 0 V for the 99% output: brief upward pulses that might not move the needle (or display) far enough from 0.0 to be noticeable. That would also depend on the output terminal’s pullup resistor (or high-side transistor) is connected to, thus the 3.3 V vs. 5 V discussion.

The power supply requires something near 5 V for full output current, so if the controller isn’t producing 5 V at 100% output (with either L held low or H held high), then that’s the problem right there.

Also: we’re assuming a solid connection among the various G terminals, so the controller / power supply / frame all reference the same “ground” = common point. If that’s not the case, make it so.

parsec · August 24, 2026, 4:59pm

Have you read the following thread?

Some info that may help.

jkwilborn · August 25, 2026, 4:51pm

When it lases, the actual %power is 5V/ 0.68v - 7.3x percent. Not enough to get the tube to lase. If you get everything correct, it likely still won’t lase if the IN voltage drops, that’s how it knows what percentage you’re asking for, the voltage on it IN terminal…wherever you get it.

The laser state sholdn’t affect the IN voltage as it’s in IN voltage that controls the lps. AS far as I know there is not real current drawn into the IN pin, so it’s voltage doesn’t vary on my system.

You need to find out what’s causing this.

I don’t know the relationship between the laser firing and m3/m5.

That isn’t going to work either. We’re here to help, so don’t feel tread on …

If you would just slow down a bit and listen to how this works, it’d probably be working by now. It’s clear you don’t understand how the lps it triggered, and what else is needed for it to work properly.

If P (water protect) AND L (Laser enable) are both pulled low, then it will lase at whatever the IN voltage is. If you tie the IN to ground, that tells it to lase at 0% power. You can see how that works out.

The problem with they way you’re handling is not really logical. I don’t know that controller, don’t know how it works or care enough to dig into it’s operation. It’s not that I don’t want to know, but I don’t have time, that’s all.

My point is you need to start at one end with something working. I see a semblance here of a working machine, just not an understanding enough to handle 3 lines.

If you want to test it, pick up a couple resistors or an external variable power supply and put 2.5V on IN. This sets the input voltage to 50% of it’s range. That should be safe for your tube.

Pulling L and P low should cause it to lase at 50% power.

Maximum power on a grbl board uses two values that must be the same at the controller end to make this useful. Both the software and the device needs to know how to compute this.

Sure you do, you have a voltmeter, correct? If you set the output to 70% pwm and check it with your voltmeter, it will be 70% of 5V or 3.5V or it will be 30% of 5V for 1.5V. They don’t sell millions of multi-meters a year for no reason.

I know you got this, just learn it as you go along.. sorry no leaning by osmosis here.

Let us know how it’s going.

Good luck.

Brian6 · August 25, 2026, 7:40pm

Update: confirmed the `!` inversion fix was actually live on the board when I tested (checked the config on the SD card directly to be sure - `laser_module_pin` reads `2.5`, no `!`, and `switch.laserfire.output_pin` reads `2.4`, no `!`).

Jack - to answer your question on M3/M5: these are standard G-code commands (M3 = “laser/spindle on”, M5 = “off”). In my config, I’ve mapped them via Smoothieware’s `switch` module to directly toggle a GPIO pin (P2.4, wired to L) - M3 pulls that pin low, M5 releases it high. So M3/M5 in my setup are purely acting as a manual on/off switch for L, nothing more sophisticated than that.

With that corrected config in place: L alone (IN left disconnected) - Laser Signal indicator lights correctly via M3/M5, as before. As soon as I reconnected IN (via the FET1/P2.5 screw terminal, now correctly un-inverted), the Laser Signal indicator **stopped** lighting at all, even with L still being pulled low via M3.

So right now: L alone → indicator lights (still no real current, as always). L + IN together (even correctly polarized) → nothing at all, not even the indicator.

Jack - taking your point about P needing to be permanently low alongside L, not just tested once: I haven’t been holding P low continuously during any of this, so that’s likely still a missing piece regardless of what’s going on with IN.

Plan for next session, following your suggestion:

1. Wire P permanently to G1 (leave it connected, not just a temporary jumper).

2. Keep L as-is on the switch module (P2.4, confirmed toggling).

3. For IN, skip Smoothieware’s PWM for this test and use a simple two-resistor divider from the PSU’s own 5V terminal to G, tapping ~2.5V at the midpoint into IN - removing the controller from the IN side entirely to test whether P+L+IN fundamentally works before troubleshooting how to generate the right signal from the board.

Will report back with results once I’ve got P permanently grounded and the resistor divider wired in.

jkwilborn · August 25, 2026, 7:57pm

Without a schematic I have no clue what fet anything really is, so that part I don’t follow. I don’t remember a lot of gcode as I never use it if I can help it. Follow the m3/m5 commands.

I don’t like to call anything incorrectly wired to be called permanently. The L and P inputs are critical to it operating properly. You need to pull both L and P low. P is water protection and when you get this working, you need to wire P to your pressure sensor. If this ever goes high it will stop lasing. If L ever goes high it will stop lasing.

If that controller has a way to stop on a fault, you could use that. The Ruida has an input for both door protect and water protect. The advantage is if you use the P terminal wired a switch for water and it goes high, it will stop lasing. The controller doesn’t know it’s stop lasing, so job recovery is much more difficult. On my OMTech machine, P is wired to ground because my chiller tells the Ruida there is a problem and the Ruida stops everything.

Let us know what you find out.

Good luck.

Brian6 · August 28, 2026, 11:42am

Good progress to report - got real firing for the first time. With P grounded, L held low via M3 (switch module on P2.4), and IN driven via a simple fixed resistor divider (~2.5V, no Smoothieware PWM involved) - ran a proper LightBurn job and it actually cut/marked the paper. Ammeter showed ~0.4mA.

New issue though: it started marking before reaching the intended target - specifically, a diagonal line appeared connecting to the corner of the rectangle, suggesting it fired during the initial G0 travel move into position, not just during the intended G1 cutting moves.

Looking at the G-code LightBurn generated:

```

G00 G17 G40 G21 G54

G90

M3

M106

G0 X143Y29 ← travel move into position

; Layer C00

G1 Y29.824 S1 F500 ← intended first cutting line

```

M3 (arming L low) happens right at the top, before the G0 travel move - and since switch.laserfire holds L low continuously from M3 to M5 (no per-move toggling), L was already low during that G0 travel. If IN wasn’t cleanly at 0V during that same travel move (residual voltage, or the demodulation circuit not dropping instantly), that would explain marking during travel rather than just during the intended G1 line.

Jack - this seems relevant to your point that both L and P need to be low together for lasing - it appears that’s sufficient on its own, independent of G0 vs G1, which means IN’s actual voltage during non-cutting moves matters a lot more than I’d assumed. I’m going to test IN’s voltage during a plain G0-only jog (no M3 sent at all) to see if it’s genuinely clean at 0V or has some residual voltage between commands.

Will report back with that result.

wxw1888 · August 31, 2026, 7:17am

Maybe your external ammeter has the water protection signal turned off. Without the water protection signal on, you can’t control the machine to emit light via LightburnMaybe your external ammeter has the water protection signal turned off. Without the water protection signal on, you can’t control the machine to emit light via Lightburn