Best posts made by keyz182

@CCS86

As requested, I'm starting a new thread. Not sure if this is the correct section. If not, feel free to move it.

@deckingman was specifically asked by the Duet engineers to post here

For anyone watching this thread, and for those who have contributed, I just want to say that the Duet team and I have opened up the communication medium that we used at the very start (when Gen 3 was still at the pre-production stage), in order to work together to resolve these issues. That's nothing personal - just that these forums are maybe not the best way to post messages rapidly back and forth between us.

They have now opened up more direct channels.

Just talk to the Duet engineers directly and spare everyone else from your dog and pony show.

No-one is forcing you to click on this thread, so consider yourself spared.

@t3p3tony said in Guide for posting requests for help:

Please only reply to this post with other constructive things forum users should do before asking for help.

• Be civil

Hey, I've just uploaded my changes to the 305 Engineering Laser Gcode generator for Inkscape, that takes advantage of the recent Duet changes to set laser power in the G1 commands. My testing has given much quicker, and cleaner outputs.

https://github.com/keyz182/inkscape-laser-gcode/tree/duet
Make sure to grab the duet branch. It should happily live alongside the original plugin, rather than replace it.

That'll be it. Now that you say that, I seem to remember reading it a while ago, evidently that snippet of information failed to stay in my brain

Would it be a good idea to make T commands output a message to the console along the lines of "free/pre/post scripts not executed as axes are not homed"?

Hey, just sharing a script I put together to notify me on print completion.

It runs on a Pi (though should run on any *nix connected to the Duet via USB), and uses Twilio to send SMS, and AWS S3 to store images. Also needs mjpeg_streamer to grab the images (or some service that can return a screenshot on a HTTP GET).

The script is available here.

There's some issues currently - Error handling needs a little work, as it's very verbose. Had the printer off overnight, with the Pi on, and the serial port not found errors spammed the logs and filled up the root partition. Added time.sleep(10) for now to take the edge off. Also, for now, added logrotate size 512k and set it to rotate every 5 minutes.

Use this link to ensure AWS is configured.

Once configured, add M118 P1 S"###END###" to your slicers end g-code.

At some point, I'd like to look at M408 or similar to include some extra detail in the SMS.

@arhi don't do that. Don't belittle people because they don't fit into your neat little boxes.

The paper isn't even trying to "do science", it's suggesting a legal framework for protection of privacy in regards to watermarks. I have issues with the intro to the paper, if this was a paper I was reviewing, I'd be sending it back as "needs work" referencing un-cited sentences such as "tracking
technologies that underlie 3D printing". But the body of the paper seems (I've only skim read), reasonably thought out. I think it applies more broadly than 3D printing, as watermarks or tracking IDs can be and are placed on non 3D printed products, but it's a start.

I wrote up a quick bit of code last night/this morning to control WS281x LEDs from a PI running the Duet Software Platform.

It uses the RPI_WS281X under the hood, so it's limitations apply to pin choices. I'm defaulting to GPIO12 in PWM mode, as DSF uses the SPI pin.

Right now it's using the duration and file time left to calculate progress, as I couldn't find a progress variable in the object model in DuetAPI (not saying it's not there, just couldn't find it).

I have considered being able to reserve LEDs at the start/end for indicators of other things, but not sure what - any suggestions? e.g. heater x on, fan x on, fan x speed (e.g. red to green or brightness of blue), etc.

To use, grab the zip from the releases tab, extract to /opt/LEDProgress, and install the systemd service as stated in the readme.

Modify the command line args as appropriate in the service file before installation. Defaults are my setup, so Pin 12, 56 LEDs, 255 max brightness.

@nuramori Never mind, just received a V1.1. Unexpected, but welcome

https://github.com/keyz182/DuetMQTT

A very basic service for DSF that'll publish the object model to MQTT. Can be consumed then by e.g. Home Assistant, NodeRED, etc.

@carcamerarig https://github.com/keyz182/DuetLEDProgress

I wrote this for my needs. It's limited in functionality, basically progress, and a couple of status LEDs at the end of the strip. That said, if you can at all code, it should be trivial to modify to your own needs. Its got the code for interacting with DSF on the SBC, and code for driving the LEDs, all you need to do is add the glue/logic.

If you can't code, feel free to make a request for a new feature, but I can't promise I'll have time to implement any time soon I'm afraid.

I needed to convert an image to work on a 12864 menu, so wrote a small python CLI tool to do it.

https://pypi.org/project/bmptoduet/
https://github.com/keyz182/bmptoduet

Install with pip3 install bmptoduet or similar.

Run with bmptoduet sourceimage.bmp outputimage.img.

The source image must be 255x255 or smaller, and in a monochrome 1bit per pixel bitmap format.

@dc42 Great, that's what I went with, and it works

Thanks all for the help. I've got a bunch of cable management to do today, and once that's done, the real testing will begin. If the tests all work, I'll write it up and post it here for some vetting, and if it looks good, I (or someone) can put it up on the wifi

I have a suggestion for the M591 command. I did look at adding it myself, but having issues getting the firmware to build.

The suggestion is two-part:

• Add a parameter to set the filament name going through the sensor
• Add a parameter to append data to a CSV file, using the set name as the first col.

That way, we can add start and end GCode in our slicer start+end code per filament. Start code would have the settings for that filament with the name, end gcode would then add data to the CSV file. That way, data gets built up over time without thinking about it.

I think option 3 is by far the cleanest. If labelling is added too, it becomes even more clear, e.g. if you set the label of expansion board 1 to "MyAwesomeExpansion" and one of it's drives to "ZAxis", you get super easy to visually parse
M569 S1 PMyAwesomeExapnsion.ZAxis

@t3p3tony rearranged slightly now - https://gist.github.com/keyz182/34601ec4ba4a19c55a177d0d1738d5a3

I still haven't been able to fully test this yet, I ran out usable filament to print a cable chain mount (I have ABS, but needed to use the room today).

Hopefully I'll get things all tested tomorrow, and can augment the guide with some examples of using e.g. Inkscape to do both vector and raster.

@gloomyandy yup, the clip ons, and just the once.

Hey all!

For purely entertainment and learning purposes, I'm having a go at designing and making a Polar style 3D printer.

Here's the design so far - https://a360.co/2KovobS.

Are there any gotchas/pitfalls to watch out for when running a polar with a Duet 2?

Also, I'd like some general opinions on the design, and advice if available.

The horizontal axis uses an Openbuilds mini V Gantry plate, and both horizontal and vertical use V-slot wheels. My aim it to try to use stuff I already have, and while I have a few spare MGN12 rails, they're all 400mm, and I've not got the tools to cut them (my lowly hacksaw just slides around on the hardened steel ). So as I've got a few spare Vslot wheels, I'm going with them.

I'm not 100% sure on the Horizontal/Vertical coupler part - not sure if I should split it up into 3 parts: another mini V gantry plate for coupling/movement, a printed part for horiz movement, and another printed part for vertical to hold the Acme Nut.

The main base part seems "fine", but there's an itch that's bugging me, telling me it could be better, but not sure how.

No design for the extruder yet, but I'll likely keep it as a very simple bowden E3D V6 + either BLTouch, or a DC42 IR sensor that screws straight into the gantry plate.

@nurgelrot Check the table here - https://duet3d.dozuki.com/Wiki/Duet_3_Mini_5plus_Wiring#Section_Description_of_Connectors_and_indication_LEDs

Specifically 1x2 Jumper: Int_5V_Disable and Note 2 at the bottom. The diagram on the top of the page shows where it is.

Just had my order from JLCPCB of the mini PWM boards for driving Lasers.

tl;dr - A board to drive PWM laser modules from the Duet!

My first time getting a PCB fabbed and my first real SMD soldering! Somehow managed to nail the SMD soldering on the first try, so have 9 bare "practice" boards left

The projects is linked here on EasyEDA. It's based on Duex circuitry, and is designed to slot into the Duex expansion slot. It's a 74HCT02 based board, which will invert the PWM, and drive it from the high side, rather than the low side driven PWM on the Duet. It also has the same protection the Duex has in case the 3v3 rail is shorted to ground to shut off the PWM.

It's the same circuit described here. Which also describes how to utilise the board. It is of course open source, everything needed to make your own is on the EasyEDA link above

As you can see in the images below, it's pretty simple, 2 components and 3 connectors. And it works, drives my Laser happily!

The traces are a lot thinner than I'd expected, I think that's down to just not being familiar with the scale of things. I suspect they're more than enough for the 2.5W laser I'm running though. I'll probably redesign it with chunkier traces, though all the GND and PWR connections do are pass through for the sake of keeping connections in one place, so you could just skip connecting them through the board and just use the PWM output.

Anyone see any issues/potential problems with it? Or potential improvements (e.g. more PWMs - there's room on the chip to drive 2 more I believe).

I have the same setup, only difference is that I'm using my Duet 2 in SBC mode. We'll, it's not quite a duet anymore, but still close enough for the configs to be comparable.

I have a PT100 for the hotend which may not be what you have, so that may be a difference.

My accelerations and such are tuned right now for speed over quality. I'm printing lots of functional parts, so ringing is largely irrelevant, so I'd ignore that part of my config

; General preferences
M575 P1 S1 B57600
G90                                                     ; send absolute coordinates...
M83                                                     ; ...but relative extruder moves
M550 P"ThreeDee"                                        ; set printer name

M667 S1                                                 ; select CoreXY mode

; Drives
M569 P0 S1                                              ; physical drive 0 goes forwards
M569 P1 S1                                              ; physical drive 1 goes forwards
M569 P2 S1                                              ; physical drive 2 goes forwards
M569 P3 S1                                              ; physical drive 3 goes forwards
M584 X0 Y1 Z2 E3                                        ; set drive mapping
M350 X256 Y256 Z256 E256 I1                             ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z1600.00 E409.00 S16                  ; set steps per mm
M566 X2000.00 Y2000.00 Z300.00 E2000.00                 ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z360.00 E18000.00              ; set maximum speeds (mm/min)
M201 X5000.00 Y5000.00 Z25.00 E5000.00                  ; set accelerations (mm/s^2)
M906 X1600 Y1600 Z1600 E1100 I30                        ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                                 ; Set idle timeout

; Axis Limits
M208 X-10 Y0 Z0 S1                                      ; set axis minima
M208 X300 Y300 Z300 S0                                  ; set axis maxima

; Endstops
M574 X1 S1 P"xstop"                                     ; configure active-high endstop for low end on X via pin xstop
M574 Y1 S1 P"ystop"                                     ; configure active-high endstop for low end on Y via pin ystop
M574 Z1 S2                                              ; configure Z-probe endstop for low end on Z

; Z-Probe
M558 P9 C"^zprobe.in" H5 F120 T6000 A5                  ; set Z probe type to bltouch and the dive height + speeds
M950 S0 C"exp.heater3"                                  ; create servo pin 0 for BLTouch
G31 P500 X2 Y-21 Z3.00                                  ; set Z probe trigger value, offset and trigger height


; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4725 C7.06e-8 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                                   ; create bed heater output on bedheat and map it to sensor 0
M143 H0 S120                                            ; set temperature limit for heater 0 to 120C
M307 H0 B0 S1.00                                        ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0                                                 ; map heated bed to heater 0
M308 S1 P"spi.cs1" Y"rtd-max31865"                      ; configure sensor 1 as thermocouple via CS pin spi.cs1
M950 H1 C"e0heat" T1                                    ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S280                                            ; set temperature limit for heater 1 to 280C
M307 H1 B0 S1.00                                        ; disable bang-bang mode for heater  and set PWM limit

; Fans
M950 F0 C"fan0" Q75                                     ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 C"Tool Fan"                              ; set fan 0 name and value. Thermostatic control is turned off
M950 F1 C"fan1" Q75                                     ; create fan 1 on pin fan1 and set its frequency
M106 P1 S1 H1 T45 C"Hemera Fan"                         ; set fan 1 name and value. Thermostatic control is turned on
M950 F2 C"fan2" Q75                                     ; create fan 2 on pin fan2 and set its frequency
M106 P2 C"MCU Fan" S0.5 H-1                             ; set fan 2 name and value. Thermostatic control is turned off

; Tools
M563 P0 D0 H1 F0                                        ; define tool 0
G10 P0 X0 Y0 Z0                                         ; set tool 0 axis offsets
G10 P0 R0 S0                                            ; set initial tool 0 active and standby temperatures to 0C

; Custom settings
M572 D0 S0.01											; Pressure Advance
;M593 F60												; DAA
M207 S0.5 F5100 T5100 Z0.10                             ; Retraction Settings Distance 0.5mm, Speed 5100, de-retract 5100, zhop 0.1
M206 X0 Y0										     	; Offset
M557 X15:290 Y15:280 P7:7 								; Mesh Grid
T0
; Miscellaneous
M501                                                    ; load saved parameters from non-volatile memory

A lot of the BLTouch issues I've had in the past have been wiring related. I don't know why, but the pins like to wiggle out of the connector for me. Probably my sub par crimping .