Posted in a separate comment for clarity.

Some time ago, I used to run my home automation system on Raspberry Pi. Then, after that, I ran my home audio on Raspberry Pis. They did work pretty well but were more prone to corruption than I'd like.

The beauty of an embedded board like the Duet 2 is that powering it down and back up meant that it was still going to come back up fine.

My experience with Raspberry Pis were that they are a full OS and don't particularly love being shut down without going through a clean shutdown. Something that a device with an off-switch isn't all that great for. Perhaps my early experiences with Raspberry Pis reflect a fear about dirty shutdown corruption that isn't a reality any more. Do I have any reason to be concerned on this or are my fears several years out of date?

Defining U in config.g before then combining worked for me. Thanks for the help!

Here are some videos highlighting the issue:

Duet Power off free-fall:
https://youtu.be/WCvHGXi6jxs

Duet Power On Free-Fall
https://youtu.be/7uG-6czPOVY

Duet Bed Stall crash
https://youtu.be/QH9c-w1Nbgg

@dc42 The information that the macros revert to previous mode was key.

I just added an extra M83 in my slicer start script after my macro call and removed all the superfluous M83s that I had added to the startcode. That does mean an M83 followed by an M83 but it seems to work.

If you need I can do some extra testing but, for now I seem to be working fine.

Thanks!

@dc42 said in Duet Maestro Freefall:

M569 P2 D2

Also, thank you everyone for the help. You've helped a whole community of users who were struggling with this issue!

@phaedrux I take that back. I'm still getting no data received.

(Deleted M122 results)

False alarm. My ground wire pin wasn't seated in the Molex connector on the sensor side and, apparently, worked long enough for me to prepare for a print.

@phaedrux I finally had a chance to get back to this and my problem was that the signal and voltage wires were shorted. Those tool board connectors are too darned small!

Thanks for the help!

@phaedrux I'm 99.9% certain the wire is OK. I used silicone wires for this and they insulation is made of butter. The internal wire isn't exposed, though.

Would I be wrong in assuming that the sensor would not blink red/green if it isn't communicating through that yellow wire?

I have a magnetic filament sensor which, TBH, I really haven't been using because even though it's mounted an inch above my Hemera and usually reports 90s% to 100s%, it would always fail out on prints with small movements.

I've upgraded my printer to 3.4, fixed my steps/mm on the extruder, and am hopeful that it will work reliably now.

Recent print result from directly connected to Duet:

Duet3D rotating magnet filament monitor v3 on pin (io2.in,i2c0.clk), enabled, sensitivity 26.14mm/rev, allow 5% to 250%, check printing moves every 3.0mm, version 3, mag 128 agc 93, measured sensitivity 26.22mm/rev, min 97% max 104% over 1106.5mm

I just installed a toolboard and have everything working except that the sensor returns "No Data Received". I get blinking green red when not moving and blinking green when moving but no data.

Toolboard filament monitor config line. Note the wide monitoring range because I don't trust a tight range... if I could get this working.

M591 D0 P3 C"121.io1.in" S0 R5:200 L24.6 E3.0 A0

I've quadruple checked my wiring for connections. The pins appear to be secure and well connected and I would presume the red/green flashing wouldn't happen if communication wasn't occurring??

I'd love to get my umbilical between the printer and print head down to just power and CAN but this is blocking me from making that transition. Am I doing something dumb?

@dc42 The information that the macros revert to previous mode was key.

I just added an extra M83 in my slicer start script after my macro call and removed all the superfluous M83s that I had added to the startcode. That does mean an M83 followed by an M83 but it seems to work.

If you need I can do some extra testing but, for now I seem to be working fine.

Thanks!

This person had the same problem I do but I'm unclear what the resolution to their problem was:

https://forum.duet3d.com/topic/22464/m83-problem/4

OK, I tried searching and didn't see anyone else having this problem.

I have a Duet 3 (MB6HC) w/SBC running version 3.3.

When I slice in Cura 4.12.1 in relative extrusion mode, it sets the extrusion to absolute (this is by design), does the startup code, then sets it back to relative. Theoretically, this should be fine. Especially since I set M83 immediately in my startup script (and twice more for good measure). Sometimes this works and prints fine, sometimes the system never exits absolute mode and the printer doesn't extrude anything because all the extruder movements are relative. However, commenting out the M82 line in the gcode file makes everything work fine.

The code from the slicer that doesn't work

T0
M190 S80
M104 S245
M109 S245
M82 ;absolute extrusion mode
M98 P"Cura_Startcode.g"
M83 ;relative extrusion mode
G1 F1500 E-1
;LAYER_COUNT:36

my Cura_Startcode.g

M83 ;Need to set relative extrusion mode. Override Cura set to absolute.
G1 X0.0 Y0.0 Z1.0 F2000.0 ; prepare to prime
G92 E0 ; reset extrusion distance
G1 Z0.2 F1000.0
G1 X60.0 E9.0  F1000.0 ; priming
G1 X125.0 E12.5  F1000.0 ; priming
G1 Z0.5 F1000.0
M83
G92 E0 ; reset extrusion distance
M83

Just commenting out line 5 in the first code block above seems to make everything work fine.

Am I doing something dumb or have I found some obscure bug?

Defining U in config.g before then combining worked for me. Thanks for the help!

@phaedrux There's no reason to treat this like a Promega. I've gutted it, changed the Z drive system to dual lead screws, the rails, the carriage, the board, the bed...

@dc42 @Phaedrux OK, I can certainly modify my config to create the U axis and then combine them. The posted wiki page doesn't say to do that so I missed the obvious!