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?

@oliof said in Weird extrusion issue:

@LeonMF These artefacts look like Bang-Bang induced bed displacement artefacts. I guess you are using an SSR with an AC bed. If its not a zero crossing SSR, get a better SSR, and try to reduce the SSR frequency (I had luck with 1Hz in the past, but it depends on your SSR).

I'm embarrassed to admit that I defaulted to bang-bang after my last printer caused problems. I never considered it an issue as I wasn't aware that bed stability of a degree or two would be that much of a big deal. I PID tuned this printer and do not have flickering lights. It also seems to have solved my problems.

Ignore the first layer, I was a bit far away.

I have more testing to do but the preliminary results here look good.

Thank you!

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

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

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

@oliof said in Weird extrusion issue:

@LeonMF These artefacts look like Bang-Bang induced bed displacement artefacts. I guess you are using an SSR with an AC bed. If its not a zero crossing SSR, get a better SSR, and try to reduce the SSR frequency (I had luck with 1Hz in the past, but it depends on your SSR).

I'm embarrassed to admit that I defaulted to bang-bang after my last printer caused problems. I never considered it an issue as I wasn't aware that bed stability of a degree or two would be that much of a big deal. I PID tuned this printer and do not have flickering lights. It also seems to have solved my problems.

Ignore the first layer, I was a bit far away.

I have more testing to do but the preliminary results here look good.

Thank you!

@droftarts said in Weird extrusion issue:

@LeonMF In the first image, the wobble on the edge is very consistent, and has a period of 10 layers. What was the layer height, and what is the pitch of your leadscrews? I'd guess that one is a problem with the stepping distance of the Z motors, and you should try and use layer heights that are whole numbers of Z motor steps. Hopefully the Z leadscrews are metric, not inch!

The second one is also quite consistent (when you zoom in on the picture), and looks to have 7 or 8 layers in each period. What layer height was that done at?

Maybe post your config.g for good measure.

Ian

The leadscrews are T8x2 leasdcrews with POM antibacklash nuts. I don't have the config.g here with me at work but I'm running 0.2 layer heights, which is an integer multiple of steps.

One thing I need to do is some testing with different sized models and see what the impact is. I've not been deliberate about that but it should highlight the extrusion considerations vs z-wobble.

@oliof said in Weird extrusion issue:

just to get the obvious out of the way: Did you PID tune your bed?

I'm using Bang-bang because I've had problems with flickering lights in the past with PID. I'm open to trying it if there's a chance it could do something.

@mrehorstdmd said in Weird extrusion issue:

@LeonMF It looks like both the extruders you mentioned are dual drive type.
Have you seen this: https://youtu.be/32dTLRNIYmw?si=d5yZB3FCSG-k59EY ?

I'm at work so can't watch the video in detail but there's a good chance it's related to this. I'm not sure there's much I can do about it given the closed nature of the E3D components.

I've been chasing a weird issue for awhile now... actually, probably since I built my Railcore 2 right after the Duet 3 was released.

Setup:

• Railcore II ZLT
• Duet 3 w/SBC
• Revo Roto w/ toolboard and custom aluminum mount

Previously, I had a Hemera and then converted that to a Hemera Revo.

I've completely rebuilt the Z axis system with better Z rods, kinematic bed mount, and oldham couplers, and I'm 99.43% positive that the Z axis is not my issue.

My next stop is to reach out to E3D if nobody here knows what's going on!

The problem has existed across two different extruders (Hemera and Revo Roto) and both direct and CAN toolboard based extruder drivers! The actual steps/mm at 16x microstepping is 90% of factory for the Revo Roto (2414 actual vs 2682 factory). When I was running the Hemera, the published 381 vs 409 steps/mm was about 93% (though I could have been calibrated to PLA at 1.0 extrusion explaining the difference).

I know that various factors affect extrusion flow rate for different materials but that's usually small single digit percentages. For the most part, this is all fine, i just calibrated the extrusion to match what I'm seeing but there appears to be a very, very, very subtle extrusion change every few layers where it under extrudes an almost imperceptible bit and it is driving me mad. Nothing I do changes the result unless I dramatically underextrude. I've even tried changing the stepper mode based on the youtube video from Thomas Sanlanderer.

I suspect the difference between published and actual steps/mm is the key here but it doesn't make sense and I'm at a loss!

As you can see, part size/geometry does seem to have an impact. The second photo looks much, much worse than it actually is. I photographed it for maximum impact but you can barely see or feel the ridges in real life.

Any help, including being told to "go talk to E3D" is welcome! Thanks!

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