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.

Hi all; this is something I have been working on to power my PrintEYE replacement but it took on a life of it's own and I'd like to get it out of my system.. so here goes.

serialOM.py is a self-contained python class that connects to the OM on a RRF device via USB or UART, and provides a local copy of the OM that can be periodically updated.

https://github.com/easytarget/serialOM

The readme there does a proper TL;DR but the highlights are:

• Python3/microPython cross-compatible with both PySerial and the mpy UART support
• Keys to be fetched can be specified on a per-mode basis and the 'seqs' key is used to only do verbose fetches when needed.
• Controller reboots and mode changes are handled appropriately. soft failures (timeouts) are tolerated and detectable. Hard (comms port) errors trigger a custom exception.
• more.. see readme.

Basic use can be as simple as:

from serialOM import serialOM
from serial import Serial

rrf = Serial('/dev/ttyACM0',57600)
OM  = serialOM(rrf, {'FFF':[],'CNC':[],'Laser':[]}, quiet=True)
print('state: ' + OM.model['state']['status']
     + ', up: ' + str(OM.model['state']['upTime']) + 's')

There is an associated printPy program that implements a robust logging / console info loop. It reconnects as USB ports change etc. and logs human-readable print/CNC/Laser status, value and progress data to the console and an optional file.

I consider the CPython side of this 'done' (unless bugs.. quite likely because I'm no Pythonista), it runs well from a Pi3 with a USB connection to my Duet2 WiFi.

There is a work in progress microPython version of this loop; printMPy which can do the same console output, but also has RGB 'mood/activity' light control and button/status controls being implemented.

Both of the print*Py loops use a separate output class. currently the same 'TXT' demo works on both. This is a template for my in-progress I2C output class can be run in a thread to allow screen animations independent of the serial comms.

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%.

I have created PR489 for this with my changes.

Disclaimer; I'm not a native Dutch speaker and have never worked in a workshop here, so I may have missed things, used wrong terms or made other mistakes.. Still, it should be better than before

@brampie if you have a GitHub account you can comment on the PR (if @chrishamm wants to hold the PR for a few days to gather comments).

@T3P3Tony said in PrintEye; simple information panel for Duet boards.:

@EasyTarget I saw from your signature that you had a plan for PrintEye for when M408 is deprecated and removed?

I do indeed; but was avoiding necro-posting here until I had something to show..

TL;DR

The original PrintEYE code probably could be modified for M409 use; but it would be fiddly; directly targeting the keys needed and avoiding fetching full keysets. It's quite do-able but I want to move on.

• The ATmega328 is the limiting factor; it's really low on RAM and once you have displays etc also running the JSON decoding became a 'mare, eventually I had to cobble together a 'inline' json decoder from various libs I found neglected elsewhere. Plus I was crippled in choices of fonts due to ROM space, and had to forget using a framebuffer (ram) and directly draw the screen.
• It was good fun and satisfying to do, but not again...

After I finished the original I started on 'PrintESP' with a similar plan, but a WemosD1 mini in the same case. And the code ported to take advantage of all the extra resources.

• Did you know that 99% of D1 mini clones cripple the UART with a pulldown resistor? I didnt.. That, cranky SoftSerial implementations and covid stopped progress.

What did happen during Lockdown was that I learned Python.. eventually coming up with 'SBCeye' (unoriginal naming is my superpower):
https://github.com/easytarget/SBCEye

To cut to the chase; I've been working on 'PrintPy', smaller and snazzier, micropython powered with 2 cores and a framebuffer! But still 2x OLED's and one button.
https://github.com/easytarget/PrintPy2040

If curious take a look at the Python/Tools folder, the script there currently runs well, is data-driven and flexible, and prints a once-per-interval status line from the OM. It's very in-development so ymmv.

The popular and well-supported GRBL firmware(s) implement an alternative form of 'laser mode' using the otherwise redundant M4 'reverse spindle' gcode.
With this enabled they scale the laser power during (and only during) cut movements as a factor of the actual movement speed vs desired cut rate.

This is not really aimed at laser cutting; it's intended for those of us doing engraving activities; it prevents overburning artifacts during acceleration and corners; and protects the workpiece during travel moves.

So; I'd like to suggest that Duet implements a 2nd 'laser mode' that follows the behaviour of grbl1.1f+ in using M4 and pwm scaling.

• It's a valuable mode that produces real improvements to work quality, and is totally the sort of thing an advanced motion control system should provide.
• It brings instant compatibility with gcode produced by all the common free and hobby oriented engraving tools.

Note:
I had a search and saw this but cant find anything 'formal' here discussing this, so I thought I'd lob it at the Wishlist. I'm kinda hoping the answer is 'yawn; on the way; just wait for RRF3 to flesh out', but here goes anyway.

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.

@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.

The flip side of this on Thingieverse: https://www.thingiverse.com/search?q=low+poly

And my extreme take on it:
https://www.thingiverse.com/thing:2964528

Sometimes I like the effect of low poly counts, but mostly it's a pita, as @deckingman says; it can be hard to get rid of them at big sizes. I do the occasional 250+mm diameter vases on my delta and need to look out for this, another area where Octoprint's gcode viewer comes in handy for seeing 'what you will axctually get' vs the preview in the slicer.

@oliof said in Time to depreciate Thingieverse due to Stratasys:

(in 2024, Stratasys owns less of UltiMaker and thingiverse than two years ago.

Hence the 'part owned', I get that it's a complicated relationship and I do know about the recent acquisitions.

I actually considered the fact that UltiMaker properly funded Thingieverse again to be good, and started uploading there again after a couple of years when the site was so broken uploading was not worth the hassle.

But.. UltiMaker are still part owned by Stratasys, and therefore Stratasys derives benefit from the community. I think it appropriate to think again about who I provide traffic to.

You need to read the Toms hardware article for the detals of this pathetic IP land-grab; but the long and short of it is that Stratasys are trying to enforce, among other things, a patent for using a heated bed in 3d-printing. I wish I was joking..

https://www.tomshardware.com/3d-printing/3d-printer-maker-bambu-lab-faces-patent-infringement-lawsuits-that-could-threaten-hobbyist-3d-printing-in-general

Thingieverse is owned by UltiMaker, in turn part owned by Stratasys. One way to show our collective displeasure is to pull designs from there and go to cults, prusa etc. since they are less toxic to the community.

This is my plan, anyway.

There is, of course, a vigorous discussion to be had over this. What might concern Duet3d in particular are the following claims:
US9168698B2 - Three-dimensional printer with force detection
US10556381B2 - Three-dimensional printer with force detection

@dc42 Thank You, I'd hoped it was a trivial fix of this sort.
I have also added a 'do not check firmware' init() option to serialOM since it's a bit redundant in some situations.

As the title implies, if I run M115 while my board is in 'simulating' mode, the command prompt returns immediately with ok instead of the expected data.

RRF 3.5.2 on Duet2 WiFi

<connected via pyserial-miniterm -q>:
----------------
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2024-06-11 17:13:43
ok
M37 P"0:/gcodes/bailer.gcode"
Simulating print of file 0:/gcodes/bailer.gcode
ok
M115
ok
M115
ok
File 0:/gcodes/bailer.gcode will print in 0h 57m plus heating time
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2024-06-11 17:13:43
ok

I cannot see any other modes where this fails to respond, eg it works when processing a job. It just seems to be simulating that kills it. RRF 2.4.6 behaves in the same way.

Is this intentional? it caused some confusion since serialOM uses m115 to detect that it is connected during init().

edit: I checked docs and did a forum and google search and cannot find anything related there

@airscapes
apopos to nothing.. I've been doing this for some parts with good success (I manually pause the machine at the appropriate moment.. small parts..)

I have found it helps to pre-warm these metal washers on the printbed, before dropping in with tweezers while hot. Seems to help once the next layer goes down on top of it, if cold they can lift and snag the nozzle.

Related; I've been connecting to my Duet@ Wifi over USB and serial a lot recently; but also over telnet (all while working on SerialOM, which actually started out as a telnet client).

I have seen similar behaviour on all serial connection types, after a restart random chars appear in the input buffer of the duet. I have seen this on uart, USB-Serial and telnet connections, but is is very ephemeral and random. SerialOM actually has code in it's startup that sends a couple of \n's and ignores the response at startup; I added this specifically to address this issue.

I have a 'gut feel' that something is wonky with the input and output buffer initialisation at startup. Possibly the internal MCU UART registers themselves not being properly reset and cleaned during resets? This is a guess on my part, based on observed behaviour, reality may differ substantially.

This is an example from last Tuesday; I'm connecting to my D2wifi via USB serial from a Pi3 using pyserial-miniterm.

--- Miniterm on /dev/ttyACM0  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
g time
File 0:/gcodes/bailer.gcode will print in 0h 56m plus hea
Error: Bad command: WiFi module is ce
ok

Context: This is a connection to the board via USB serial immediately after it was rebooted.
Before the reboot I had just finished simulating a print via the Web interface.
As you can see the Input buffer on the Duet appears to have text in it that was actually written to all serial devices before the restart when the simulation finished.
The Duet2 is still running 2.4.6, but I have seen this with earlier releases too

A quick note that I just published a small update as release: v1.2.0

This removes the need to have a the separate compatLib.py library present; all the cross-python handling is now done in serialOM.py itself. Nothing else is changed.

I have created PR489 for this with my changes.

Disclaimer; I'm not a native Dutch speaker and have never worked in a workshop here, so I may have missed things, used wrong terms or made other mistakes.. Still, it should be better than before

@brampie if you have a GitHub account you can comment on the PR (if @chrishamm wants to hold the PR for a few days to gather comments).

Humm,

'close' is 'dichtbij', which means 'nearby', not 'shut'. It's all a bit 'auto translated'..

The translation matrix is nice and easy to understand here

It's 'kings day' in Holland today, I'm wearing orange and just off for a beer in Amsterdam. I'll see if I'm feeling sober and patriotic enough to submit a patch later.

@Arminas
You definitely should ground the hotend on a 3d printer, the effect of pushing plastic through tubes and nozzles will cause static buildup and possibly sparks.

But do not ground it directly, instead use a high value resistor (100K / 1M) to bond it. This will safely deal with the static, but helps to protect the printer against accidental shorts (frayed wires and case defects) between thermistor or heater leads and the hotend.

I'm sure I saw this advised here long ago, but couldn't dig up a reference.