Duet Support

[keyz182]

What would need to be done to add support for the Duet to LaserWeb? I'm willing to have a go, but not quite sure where to start.

[cprezzi]

There are two requirements.

The first is, that the lw.comm-server can detect the duet firmware. Does the duet firmware send a firmware recognition string on connect or can it be queried with a serial command?

The second is the way how the laser power is set with gcode. Laser capable firmwares should accept S values as params of G1-G4 commands. That is ideal for engraving. Other firmwares like marlin do need a separate gcode line for the laser power (like M4 S128), which need some time and therefore slows down engraving a lot. Which type of gcode does the Duet firmware accept?

[keyz182]

The first is, that the lw.comm-server can detect the duet firmware. Does the duet firmware send a firmware recognition string on connect or can it be queried with a serial command?

Yes, it does. Output (from OctoPrint) below.

Connecting to: /dev/ttyACM0
Changing monitoring state from 'Offline' to 'Opening serial port'
Connected to: Serial<id=0x6b46a210, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection
Changing monitoring state from 'Opening serial port' to 'Detecting baudrate'
Trying baudrate: 115200
Send: N0 M110 N0*125
Connection closed, closing down monitor
Recv: ok
Changing monitoring state from 'Detecting baudrate' to 'Operational'
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.01beta1(RTOS) ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2018-06-23b1
Recv: ok
Send: M21
Recv: SDHC card mounted in slot 0, capacity 3.98Gb
Recv: ok
Send: M105
Recv: ok
Send: M105
Recv: ok

Here's the documentation on the Laser Mode for Duet firmware

M452: Select Laser Printer Mode Parameters

• Pnnn Logical pin number used to control the laser
• Rnnn The value of the S parameter in M3 commands that corresponds to full laser power, default 255
• Fnnn The PWM frequency used to drive the laser

Example

• M452 P2 R255 F200 ; switch to laser mode using the heater 2 (E1 heater) output pins to control the laser

Switches to laser mode. This mode enables handling of a laser pin and makes sure that the laser is only activated during G1 moves if laser was enabled or E is increasing. G0 moves should never enable the laser. M3/M5 can be used to enable/disable the laser for moves. Logical pin numbers for the P parameter are as defined for the M42 and M208 commands. If a heater or fan output is used to control the laser, you must disable the corresponding heater (see M307) or fan (see M106) first.

[keyz182]

Following up, it appears Duet uses the S parameter on G1 for endstop checks, isn't present on G2/G3, and is used for time to wait in seconds in G4.

What does the S parameter do on other firmwares? Is it just setting the intensity (e.g. S0-255, or S0-1) or a simpler on off?

I could look at adding support for a similar parameter to the firmware (though it would have to be a different letter than S) if e.g. the "activate laser on E increasing" isn't good enough.

[keyz182]

It appears support for S parameter on G1 is coming in 2.0.2 of reprapfirmware, so that's that bit sorted. I'll take a look at what's needed in lw.comm-server.

[T3P3]

@keyz182, thanks for starting this conversation! I am one of the Duet creators, @FabCreator put me onto this topic. I am not familiar with Laserweb but its obvious a tool that a lot of people use for lasercutting/CNC and it would be very cool if it supported the Duet. For faster and more reliable operation it would be good if Laserweb supported a "send to Duet" option so the whole file could be stored and read from the on board SD card on the Duet.

@cprezzi feel free to drop me a line info@duet3d.com if having a Duet would help you with supporting it better.

[cprezzi]

LaserWeb does not yet support sending the file to the sd card of the controller, because we always wanted to be a "realtime" frontend and not another gcode sender. This is especially important on cnc milling and long vector lasercuts. In my opinion, the frontend should be able to pause/resume/stop the job immediately (no waiting for commands in the queue) and do feed and laser power changes in realtime, like we can do with Grbl.

Of course I'd like to support the Duet as one of the more advanced controllers. There are "just" two main requirements:

1. We need a way to detect the firmware. The M115 query/response seems ok for that.
2. For fast raser engraving, the PWM value should be in the G1-G3 command (like G1 X100 Y0 S100).

If the gcode "dialect" is close to grbl or smoothieware, it could be quick to implement. Having a Duet for testing would clearly speed up the process ;)

[T3P3]

So taking the second part first the latest beta of RepRapFirmware (RRF) running on the Duet implements the "S" switch for power when the firmware is in laser mode. We shall see how this goes as people test the beta.

A further advancement which we are considering, in order to reduce the gcode data rate for high speed rastering is to allow the "S" switch to be an array of a certain length, as an example

G1 X1 Y1 ;start at X1 Y1 G1 X2.6 S0.0:0.5:0.4:0.4:0.4:0.4:0.4:0.4:0.4:0.4:0.4:0.4:0.5:0.0

That would draw a 1.6mm line, with 16 evenly spaced intensity steps, effectively 10 intensity levels per mm. This would reduce the data rate required from the file by a factor of 16. 16 was chosen as a manageable number but it might be better to use a different number.

[cprezzi]

That sounds very promising. I always sugested to add a "line of pixels" command to reduce overhead for raster engraving.

[cprezzi]

Do you also adjust the laser pwm depending on x/y acceleration and deceleretion (like Grbl in M4 mode)?

[FabCreator]

@cprezzi drop me a mail at bonne@fabcreator.com and I will organise you a board. :)

[T3P3]

I checked and apparently the reduction in power based on acceleration is not yet implemented in this Beta but will be before the beta makes it into an actual release.

[cprezzi]

@FabCreator Thank you for the offer. Tony already told he will organize a v1.03 board for me :)

[FabCreator]

@cprezzi is there a way to send realtime commands even if the file is running direct? For long files USB is just not reliable enough so creating a send to would be a great addition to LW. I thought the main reason this was not explored further was because of smoothie unable to read and write reliably in this regard. (This was back in LW3 with peter)

Below are the threads i could find on the subject, might be helpful. https://github.com/LaserWeb/deprecated-LaserWeb3/issues/16 https://github.com/LaserWeb/deprecated-LaserWeb3/issues/138 https://github.com/LaserWeb/deprecated-LaserWeb3/issues/171 (The reason it was not added is lost in a deleted G+ post.)

[cprezzi]

@FabCreator It depends on the firmware, if "realstime" commands are accepted during SD job execution. I think RepRapFirmware has some realtime commands (like pause/resume) that can be used while a job is running. @T3P3: Is that correct (also via USB)?

We was also talking about connecting the Duet via ethernet (LAN/WLAN), exactly like the DuetWebControl is talking to the firmware.

I think it would not be enough to just add a "send2SD" function. What happens when the filename already exists? I think we would need to implement the whole SD support (dir, cd, store file, read file, delete file).

[T3P3]

@cprezzi yes some commands are not buffered to allow for faster pause/resume.

If you are accessing the Duet over HTTP then the commands to do the file handling are already in the API.

[Wingeddonkey]

Looking forward to watching and seeing the progress on this. Recently upgraded to a duet and am hopeful to see the support added very soon. (So I don’t have to leave two boards installed for laser and printing)

[cprezzi]

I have already finished the implementation of USB serial communication for Duet in lw.comm-server and merged it into the master branch. The SD functionality is also implemented into the server and the API was extended, only the frontend part is still missing.

[keyz182]

@cprezzi what's required for the frontend? I can have a look and try to implement what's needed, but may need some guidance.

[cprezzi]

@keyz182 The frontend needs an option to manage the SD card content (list folder, cd, upload or delete files). Like a mini file explorer.

[keyz182]

OK, and is there anything needed for direct USB usage (i.e. using it like other boards)?

[cprezzi]

No, the USB connecttion is handled by the NodeJS server (lw.comm-server) that is compiled into the exe. The client (frontend) has to use the server API on the websocket connection (as documented in https://github.com/LaserWeb/lw.comm-server/wiki/API-(for-client-communication).

You can find the current frontend for machine control in https://github.com/LaserWeb/LaserWeb4/blob/dev-es6/src/components/com.js. What would be nice is to add a "manage SD" button and popup dialog with a file explorer to navigate throug the sd card, be able to create/delete folders and upload/delete files.

[Wingeddonkey]

A quick question regarding the gcode. I know Smoothie and Grbl have minor differences in each other. And since moving from Smoothie to Duet I’ve found a lot of things are structurally different from the ground up.

Are there any gcode concerns between the types of firmware, or were these concerns covered in the original assumptions? (I know I’ve seen multiple discussions on design decisions and assumptions, are there any deal breakers to Duet?)(Beyond pre/post gcode additions that can be added to gcode in settings)

Bottom line, since the front end control hasn’t been implemented by anyone are there any concerns with saving the (smoothie) gcode manually and uploading via DWC and running from SD card? With a simple laser fill, I haven’t seen anything beyond G0/G1 commands, as long as Duet tracks the S parameter the same (I need to dive in and research) everything should work?

(Also is there a newer binary compiled for a windows install since June that includes your backend changes?)

[cprezzi]

@Wingeddonkey I think you should better ask on the RepRapFirmware forum for differencies in gcode details.

As far as I understand, the gcode interpretation in RepRapFirmware should be very close to Smoothieware, so saving the gcode manually and uploading to the SD card for execution should work.

The newest binary is always published on https://github.com/LaserWeb/LaserWeb4-Binaries/releases.