So; this is what I did to prove to myself that I could. Maybe for my CV, I had fun and learned a lot doing this. Enjoy, or ignore, as you wish.

PrintEye is a minimalist information panel for Duet boards; it plugs into the DanelDue UART port, taking power from there and sending M408 S0 once a second, and otherwise waiting for a reply and updating the display based on their contents.

It consists of a ATMega328P on a simple standalone board, linked to 2x 0.96' I2C OLED displays, a LED, a Button, and two mosfet level converters for the serial connection to the 3.3v UART on the Duet board.

The Primary connector for the Board doubles as a FTDI programming port, allowing me to update and debug without yanking the CPU out of it's socket. There is no reason why the current cable could not be adapted to the spiffy new 5-pin IO connector of the Duet3 and then that port configured as a UART. Afik the D3 does not have a dedicated panelDue port,

The displays I used have hard-set identical I2C addresses, to avoid using a multiplexer I create two separate software I2C interfaces, one per display, this works surprisingly well. The U8x8 Arduino library handles all the heavy lifting on the display side.

Most of my effort went into the software, which:

• Follows printer status; can turn displays off when printer is in psu-off mode. (configurable)
• Heartbeat/Status LED; brightness configurable.
• Pause/Resume button; configurable on/off and hold-down time.
• Bed plus selected tool heater set and actual temps are reported; as are 'off' and 'fail' states.
• Screen brightness, timeouts, etc are all configurable.

Processing the M408 response Json proved a challenge with minimal memory; I ended up using the Jsmn library. Once I had this running I realised I could leverage this to provide config control too.

The Project exists as two repos on GitHub: Software and Hardware. Both have TL;DR readme's. The Hardware repo has the full KiCad project, and Gerber files.

I have also written this up as a formal project on Hackaday, with archives, gallery and a better summary but lacking very detailed instructions, I assume you know which end of a soldering iron to pick up etc..

My plan for the V2 of this drops the displays in flavor of a LED dot-matrix (16x2) and four servos plus these; for a mad plan to put a delta printer into a 70's era Tardis console. Possibly.

This is Sunflower; I guess she's just a hobby printer but I've had a lot of fun getting her to this state. She prints art and big brackets with a big nozzle really well.

Highlights:

• 280mm x 630mm (at centre; more like 520mm at full radius), magnetically attached PEI bed but can quick swap to glass.
• Built from a HE3D K280 Chinese kit; The hardware is just fine, functional aliexpress stuff. Good bed heater and PSU but the rest of the electronics less impressive. I ordered a DuetWiFi the same day I ordered the kit.
• My own E3dv6 mount and modular easy access (click together) fan system.
• My own simple adjustable slider brackets and clamps.
• Spot the endstop switch? - it's done by encapsulated reedswitches and bar magnets in the slider brackets. No visible wiring and is very repeatable! Once calibrated I can reliably home, even when paused.
• PrintEye status panel; temperature, status, info. Also mine.
• DC42 IR sensor (she's also had a PPiezo unit at times)
• Quite a bit of 'fluff' to finish her; 9mm belts, 0.9 steppers, lights. The (supplied) 16A 24v PSU is under the bed with additional fan ducting, the Duet has a mcu fan + duct underneath the board.
• Purple. Lots of Purple. I like purple.

Everything useful I that designed, and the other designs I use, are collected here: https://www.thingiverse.com/Nanocube/collections/sunflower-a-k280

@yaman said in Add laser for duet2 wifi:

SO I have to make this PCB board ?

You can do, yes. Though possibly with less whitespace around it.
It's an idealised circuit, but it provides a clean 5v PWM signal to the laser, which is good and has an interlock to stop the laser blipping full power during powerup.

is it possible to use heater 6 PWM

I dont know much about the expansion board. If it is a 5V signal then yes!
But if it is a 24v heater output, no.
Edit; looks good, thanks @T3P3Tony

The issue here is that common laser modules set their PWM line to 5V and expect the controller to then pull that to 0v for the off part of the PWM cycle. This 5V is enough to damage the Duet if you put it directly on a controller pin. You need some sort of buffer between the two.

In the circuit above this is done by the 74HCT020, which is a 5V logic chip, but will trigger with the 3v3 signal from the duet too. It's also fast and transmits a clean signal.

There are quite a few options, you can possibly get a circuit like the one above from aliexpress etc already. Though it's not a complex one to build if you know how. Another great option is an optoisolator. But you lose the 'blip' protection.

I'd suggest more research, try searching on more general topics like 'how do I control a 5V pwm laser module with a 3v3 controller', etc.

A 'hidden' advantage of the circuit above is that, unlike many transistor/mosfet pwm drives which have internal capacitance, the 74HC chip produces a very clean signal. for the laser. And this is an advantage for lasers like ours.
edit: Another great reason to use the expansion card solution..

• once you have it working, try a fairly low PWM frequency (like 100 Hz. low) and 50% PWM cycle (power), this is when the 15/8W modules are 'pulse' cutting, you can do this continuously and get good results so long as your feedrate is slow (or you get a row of dots). There are a bunch of videos about this on youtube and elsewhere too, part of the secret is a clean PWM signal. I get good results, it's much more powerful at this sort of engraving than my 5W unit is at 100%.

@vwegert said in CNC: Tool Offsets, Coordinate Systems, Confusion:

I understand that a lot of stuff is possible, but what is the setup I should be working towards if I want to be able to get my CNC to process programs generated by Fusion 360? My machine homes to the back right top corner of its working area, so towards the X/Y/Z positive endstops, is that correct - or rather, is that sensible?

https://www.autodesk.com/products/fusion-360/blog/cnc-coordinate-system-made-easy/
Has a good (if long) discussion on the whole topic. Remember that not everything there is applicable to the current Duet CNC implementation.

My machine co-ordinate system matches the homing motion; eg top right and back (like yours), this is a very traditional home position; in most machines this is when then worktable is most accessible, it's quite sensible in that regard.

I do this at home on my 1612; all three axes are always negative for machine co-ordinates, the machine works entirely in the third quadrant.

But this is just the machine co-ordinates; and these are never used for CNC operations. Once you have the piece mounted you jog to it's origin point and set the workspace origin there. This is what your gcode will treat as it's origin.

Look at G10 and G53 through G92 in the gcode manual, Especially G54. There are quite a few prior discussions here too.

The only real golden rule is that the Z axis should home upwards, and the homing cycle must home Z before any other axes move. This is practical, driving the tool down or sideways into the workpiece is usually catastrophic.

@Eumldeuml said in How can a calibrated extrusion produce overextruion-ish prints?:

Can someone tell me why that is the case?

Tricky, you'll probably get six different answers, all of them possibly correct.

I saw similar things om my machine as I explored 0.6 and 0.8 Nozzles, I solved some of them after reading this and spending a few hrs printing cats with different line widths and layer heights, I was surprised at how big a difference small changes made.

The problem is that this combines with other stuff too; So; here is my 'hit list';

• beds that move (even if not visible to you) with Z height or temperature cycles also wreck walls and layers like that.
• overstuffed first layers; I dont think you have this; but it forces every subsequent layer to be a little bit overstuffed too, a bad first layer can ripple up through the rest of the print., especially if you are overextruding a bit anyway.
• Slicing; You dont mention which slicer you use, but with so many parameters to tweak and forget it can be a good idea to start with a very plain 'vanilla' profile for your printer and re-do the slicer settings from scratch based on experience.
• Filament; has bitten me hard. Very small filament diameter changes are over-represented in extrusion changes (it's that pesky πR squared business), without proper filament sensors (which do exist for the Duet) you have to trust suppliers to be consistent.

It's on a spring steel plate, with a 'Whole Bunch' (tm) of high-temp supermagnets under the aluminium heatbed. Works very well and I can pop things off it almost trivially.

However, very large footprint objects can warp the spring steel off the bed and end up with the model rocking or dancing about. So I have a system to use the original glass bed instead when needed.

• the clamps you see are part of that (edge grip) and also hold the heatbed down against some springs (which in turn allow the bed to give a bit ifwhen the head crashes
• I like this arrangement, it gives good results. But lacks enough surface hardness to let me use a PPiezo Orion with the PEI bed (though it worked OK on glass.)
• Magnetic flux over the printbed is awesome! I can feel it dragging my watch down sometimes. Most people have a 'warning HOT!' sticker, but I also need to follow Prusa's example and put a 'Warning, high flux' one there.

1. When you tested with the bed sensor; what happens when you switch it back; does the bed now show the correct temp again?
2. As JoergS5 says; to help you we need to see the type of both sensors; and to know if they are both thermistors, etc.
3. Are the M305 P0 & M305 P1 settings from your config the same? Please share these here.

With thermistors a reading of 2000 normally means a disconnected sensor; open circuit.

I once saw something identical (but with the bed sensor).

• In my case it was a RTFM confusion; I was plugging the thermistor into a fan circuit, not into the bed sensor.. This destroyed the sensor; I got through a couple of them before finding my face with my palm.

@yaman said in Add laser for duet2 wifi:

I like to buy circuit then make one

I can appreciate that

I found everywhere I look this things
1- PWM Laser Power Output Regulator/Frequency&Duty Adjustable

This is not what you want. It is a standalone controller for when you are using the laser on a bench etc. It creates the PWM/ttl signal itself. The specs say it has a serial control (but I don't see that in the pictures) which could make it useful for some cnc stuff. But not for the Duet; serial control is nowhere near fast enough for our use.

2-EleksMaker PWM To TTL Transition Module

This looks more like it! so long as it can be driven from a 3.3v input. The eleksmaker controller is 5v, but this adaptor might be fine with 3.3v too. If so, it looks like exactly what you want.

• its late here, I'll try and find time to look at this properly (find the circuit or something) before Monday.
• in the meantime here is a thread that may prove educational about this module:
  https://github.com/openfab-lab/toolsDocs/issues/13

My laser is PWM and TTL

That is also good to know, it means the 'PWM pin should be properly driven both high and low (TTL PWM) for best results. Non TTL PWM only pulls the pin low, it has to be pulled back high by a resistor and for this reason can be a little bit less precise in timing; I've seen this discussed to death in CNC forums.
This explains things nicely too.

so any suggestions ?

If you have money to burn, order one of those modules so that it is on the way.. I'm pretty sure it is a good plan but wont be held responsible if not.

PS: Nederlands?

nicolasdb created this issue in openfab-lab/toolsDocs

open laser module TTL vs PWM #13

@Phaedrux
In that picture the bed is upside down.. Aluminum is non-ferrous, it does affect the field strength but not very much, those magnets project through 3mm of aluminum with enough force that I have to be careful not to pinch my fingertips when I'm taking the plate on/off.

@Tarasque_1024 said in Duet 2 Wifi - Bed no longer heating:

How do I check that?

As @dc42 and @3ddevil correctly say, the fact the LED comes on (you say that in the OP) actually means the mosfet should be good.

Next step is to switch your multi-meter into resistance (continuity) mode and check each individual wire between the bed terminals. Eg from the +bed screw terminal to the + solder connection at the other end of the wire, same for the - wire.
If they conduct (zero resistance) this is good.
Next check the whole bed resistance; disconnect the bed wires from the terminals on the board and measure the resistance between them. It should be near zero; the heatbed has a resistance of one or two ohms, depending on capacity.

• Try to do this with the bed and board in their normal place, wires can twist and internal breaks sometimes only happen when the wire is in one position, when you move it the wire strands touch inside the sheath again and it suddenly looks good again, until later.
• You must disconnect from the screw terminals first because the bed led and diode(d4) will always show a false 'good' reading if the wires are connected to the board!

==================

I'm going to post the image I'd hacked up earlier, if you or anybody else needs to check the mosfet it can serve as a handy reference:

And here is the schematic of this bit of the system to add some context and because I really should have checked it earlier:

Finally; the spec sheet for the mosfet is here:
http://www.icbase.com/File/PDF/IFT/IFT03781303.pdf

Apologies in advance; this is a strange error and at first I thought I was imagining it. So I want to post it here before raising a GitHub issue since I'm curious to see if anyone else can reproduce. Especially other Duet2 owners.

I've got a Duet 2 WiFi/Ethernet board that I upgraded to 3.4.x recently, it is connected to a Raspberry Pi via USB, the Pi runs a fully updated Bullseye release.

The board's input buffer appears to be initialised improperly following a reboot, and can contain junk.

• If the first USB serial input is sent after the WiFi connects then a fragment of the WiFi connection message is pre-pended to the input, causing an error in response to the first command sent (see example below)

My initial reaction was that it must be some super-quirky effect from my PrintEye, but this persists even once I had the PrintEye physically unplugged and all it's config commented out.

Currently my config initialises the USB serial port with the default:
M575 P0 S2

Here is a log to show what I mean, sorry it is a bit long but I wanted to put the m122 outputs in full here.

I connect via miniterm from the attached Pi to the Duet2 immediately after rebooting it and before WiFi has been established:

(env) owen@transmog:~/miniterm $ pyserial-miniterm --echo --eol CR /dev/ttyACM0
--- Miniterm on /dev/ttyACM0  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
<pause while wifi completes connecting>
WiFi module is connected to access point TINKERBEL, IP address 10.0.0.30

I then send 'm122', and get back debug info as expected:

m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.2rc1 (2022-07-06 16:21:02) running on Duet WiFi 1.02 or later
Board ID: <snip>
Used output buffers: 1 of 26 (2 max)
=== RTOS ===
Static ram: 23860
Dynamic ram: 74592 of which 0 recycled
Never used RAM 13628, free system stack 193 words
Tasks: NETWORK(ready,8.9%,267) HEAT(notifyWait,0.0%,339) Move(notifyWait,0.0%,363) MAIN(running,84.3%,454) IDLE(ready,6.8%,30), total 100.0%
Owned mutexes: WiFi(NETWORK) USB(MAIN)
=== Platform ===
Last reset 00:00:13 ago, cause: software
Last software reset at 2022-08-13 13:21, reason: User, GCodes spinning, available RAM 13628, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 36.0, current 37.4, max 37.6
Supply voltage: min 2.1, current 2.6, max 2.6, under voltage events: 0, over voltage events: 0, power good: no
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: ok, SG min n/a
Driver 1: ok, SG min n/a
Driver 2: ok, SG min n/a
Driver 3: ok, SG min n/a
Driver 4: ok, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 1970-01-01 00:00:00
Cache data hit count 597476626
Slowest loop: 10.05ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.9ms, write time 3.9ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "m122" in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Network ===
Slowest loop: 16.40ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 0 of 8
- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address 60:01:94:33:8b:8c
WiFi Vcc 3.40, reset reason Power up
WiFi flash size 4194304, free heap 26240
WiFi IP address 10.0.0.30
WiFi signal strength -47dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
ok

I now send m199 to reset/reboot the board (causing miniterm to exit as the USB is dropped):

m999
T0:32.3 /0.0 B:27.5 /0.0
(miniterm) Exception in thread rx:
(miniterm) --- exit ---

I now wait for the led's to show me the Wifi has reconnected (eg I wait till after the 'WiFi Module is Connected..' message has been sent).

Then I restart miniterm, send m122 and get an error.

(env) owen@transmog:~/miniterm $ pyserial-miniterm --echo --eol CR /dev/ttyACM0
--- Miniterm on /dev/ttyACM0  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
m122
Error: Bad command: WiFi module is com122
ok

Note the error message: 'Error: Bad command: WiFi module is com122'

• So the input the firmware received is 'WiFi module is co' (the first 17 characters of the WiFi Connected message) concatenated with the command I sent: 'm122'.
• I looks to me as if the input buffer initialisation is incorrect or incomplete; and the default input buffer gets allocated somewhere that already has a fragment of another buffer in it.

This is a one-off error that follows the reset; subsequent commands are processed as expected.

m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.2rc1 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2022-07-06 16:21:12
ok

The Pi is a Model3 B+ running Bullseye and fully updated:

(env) owen@transmog:~/miniterm $ python -m pip list pyserial
pyserial      3.5
(env) owen@transmog:~/miniterm $ uname -a
Linux transmog 5.15.56-v7+ #1575 SMP Fri Jul 22 20:28:11 BST 2022 armv7l GNU/Linux

Can anybody reproduce this? It's pretty minor but has caused me some issues due to my setup.

• I realise that this could also be something Pi specific, so I am curious to see if it also happens to people using other connection solutions.

tl;dr
I noticed this when I connected the board to a default-configured octoprint installation; by default octoprint sends a m122 to detect firmware, but also always responds to any error with a m199. This resuts in a sort of 'connect loop' where you attempt to connect from OctoPrint, it sends m122, sees the error and reboots the board, then waits for the user to re-try the connection. Putting you in a loop as the error repeats with a reboot on every connect attempt.

I have re-configured Octoprint to not be so aggressive with the m199 when it encounters errors to work-around this. I use DWC for most operations anyway, but find OctoPrint handy for actual printing (especially it's time-lapse abilities).

Hi to all my fellow CNC and Laser nerds in the audience!

If you have experience of using LaserWeb4 with a Duet controller I'd dearly love to know more about your experience, good or bad.

• If you have been successful, I'd love to see your config!
• If you gave up on it, I understand ;-), I'd love to know why.

No need for huge long answers, but a bit of rationale would be appreciated, 'it sucked' wont really help me improve it.

I'm trying to devote unemployment and lockdown to, burying myself in learning JS and React the hard way, via LaserWeb, fIxing bugs that annoyed me, UI tweaks and even adding simple features.

• A TL;DR summary of what I have done so far
• Online demo! Working; you can save gcode to a file.

As part of what I have done I am improving the Predefined Machines database, I have added a 'Generic RRF' profile, but I want to add a 'Duet based machines' one too. Since I do not actually have a duet powered CNC I thought I'd ask here.

If you want to share a config, the most useful way is to go to Settings->Tools and hit the Save Settings button on the first line. The .json file that produces is exactly what I want.
Note: It might contain internal IP addresses and names, if that is an issue you can edit out the lines for comServerIP and connectIP in the file with any text editor.

@TP The ones I used were linked above.
https://www.conrad.nl/p/standexmeder-electronics-4003004010-permanente-magneet-staaf-alnico-grenstemperatuur-max-400-c-1205896

A year and a half later and everything is still working perfectly, Repeatability is obviously excellent since the machine always holds calibration perfectly; often for weeks across dozens of homing and print cycles after a single calibration on duet powerup.

If you mean the time-of-flight sensor modules you can find online then their accuracy is far, far below what is needed for levelling etc. It's 'a few mm' in ideal circumstances, 'a few cm' in most realities.

(Edit: re-reading your question, I'm not sure you are talking about the same thing here, but i'd written this anyway so I'll let it stand, the working principles are the same.)

They are, however, really cool sensors in lots of ways. I've built a 'lidar alike' system based on one, it works quite well, if slowly.
https://github.com/easytarget/esp32-cjmcu-531-demo

Good background to the way they work:
https://www.st.com/content/dam/technology-tour-2017/session-1_track-4_time-of-flight-technology.pdf

Because these devices are essentially a small ccd array of individual (single photon) sensors they also support detecting motion across their field of view, as well as the distance. A common use for them is in gesture based (non contact) UI's, and this is where I see them having an application for printer and cnc controllers

@wilriker
I cant speak for ustreamer but mjpeg-streamer provides a http stream on http://<ip:port>/?action=stream and can accept multiple connections. I regularly have it streaming on my desktop and media-pc simultaneously without issues or any noticeable load on the Pi.

OctoPrint's inbuilt timelapse system, (or octolapse , if you love needless complexity) requests snapshots via http://<ip:port>/?action=snapshot, there is no detectable pause on the streams when this is invoked.

Conventionally: To get a timelapse you use a script to capture frames at set intervals/events, timestamp them if desired and save them. Once the capture is complete you stitch them together using ffmpeg.

However.. when I want a timelapse on my CNC I start a screen session (nohup shell) on it's attendant Pi and run this:

pi@laserweb:~ $ ffmpeg -r 600 -i http://localhost:8080/?action=stream  -vf "drawtext=fontcolor=white:fontsize=16:box=1:boxcolor=black@0.3:x=(w-text_w-10):y=(h-text_h-5):expansion=strftime::text='CNC \:\ %H\:%M\:%S'" -r 20 lapse.`date +%Y%m%d%H%M%S`.avi

Which tricks ffmpeginto thinking that my 30fps stream is really a 600fps stream, and the asks it to timestamp that and convert to a 20fps framerate.
The end result is a 20x speedup video with timestamp, but the quality is noticeably lower than the capture/assemble method. And the Pi3 is devoting 32->40% of it's CPU to ffmpeg while it is running. Not recommended as a permanent solution, it's a classic quick'n'dirty one liner.

The 12v fan will probably turn, very slow, at 5v.
I'm more worried that you say they do not run at all if you set the fan jumper to Vin. This means that either 1) there is a fault on your board (you can use a multi-meter to carefully check the jumper voltage is 12v when set to Vin) or 2) some other wiring problem, but I am not sure what could cause that behaviour.

It's probably time to ask which Duet board and Firmware combo are you using? Have you read the Wiki page on fan config.
And can you please share your config file (the bit with the M106 fan config commands)

To ask the obvious; they are 'normal' 12V fans yes? Individually wired to their header on the board?
When set to 5V do they turn on and off as expected? (eg Coldend only when the heatblock heats up, part coolers only when commanded via UI/gcode)?

@juanmena
You might want to read this thread: https://forum.duet3d.com/topic/12150/laser-gcode-s-sticky-after-g0-question, there is some discussion of how to configure LightBurn with Duet/RRF Firmware. The bad news is that there is no built in 'compatibility' for the Duet in LightBurn.

Currently I use LaserWeb; (but I control a Grbl CNC, not Duet, so cannot give a config).
https://github.com/LaserWeb/LaserWeb4

LaserWeb is very good at preparing raster and dither images from bitmaps and jpeg's etc. And at cutting and filling svg (vector) images. But it has no image editing tools beyond resizing and rotating them. So I often use Pinta or InkScape to prepare the source material first.

LaserWeb can run as a standalone application on your laptop/pc to generate Gcode and optionally control/stream to the firmware via USB or telnet if desired. Look for the windows 'electron' build.But I use it it on a Raspberry PI in web client/server mode to give myself a webUI.

Since you can configure all headers etc with laserweb it is much easier than LightBurn to configure for a Duet. The inbuilt RRF profile is a good start.

Thanks for thinking of the PrintEye guys, sorry for not being very active here, busy elsewhere (eg linkedIn, sigh).
I have, however, done a 2.0 release of the code, adding more smart functions to the button including reset/emergency stop and OctoPrint(*) pause/resume, I've even got progress indication (sort of) going via a hacked OctoPrint plugin but need to finish and publish that.

(*) Yeah, OctoPrint, sorry. I have my little foibles.

@bearer
Feeling curious I checked, and the expansion board indeed gives a 5V pwm line for Heaters 6 and 7.

@otaku521 The wiring hookup looks good. And I cant see anythng amiss in the config. But the behaviour you describe sounds very much like the laser module is not accepting the PWM properly; Does it have a 'analog/ttl' switch/jumper anywhere? Do you have access to a scope or PWM aware multimeter to verify the signal level and duty cycle on the line itself?