Posts made by nhfoley

Almost accomplished this with the new RRF 3.4 multi-pin heater syntax! But held back on the upgrade to stay on production FW. Nonetheless, meatspace wiring of the two heaters in parallel is now correctly holding a temp +/-.02C, which is the noise floor of my sensor reading, anyway. With the other thermistor still wired in place, I can see that there is a roughly consistent 1C difference on the non-control side. Not perfect, but much better than what I was seeing before.

Yes, I may do that, but keep the second sensor wired & reporting to DWC for monitoring purposes.

So I'm encountering a problem when attempting this strategy: because there is so much heat transfer between the two heater zones, the M303 algorithm is failing, because it can never complete a cooling cycle - the "passive" heater in this scenario is shedding enough heat to keep the actively autotuning heater from dropping far enough during the cooling cycle to proceed to the next phase of the algorithm.

Any thoughts on how to avoid, apart from manually triggering the passive heater to be off at just the right time during the autotune algo?

The best performance I have so far has been to autotune one heater by itself, roughly double the gain value, and then copy those parameters to both heater models. This works OK, but is still oscillating around the target temp enough that I suspect its influencing print quality. How can I improve further?

Thanks for this - was wrapping my head around how to best solve this problem with a Mosquito Magnum+ with two heaters and sensors. Clever solution.

@dc42 Seems like this is less of a fringe concept than I feared. I will push forward. Thanks for the industry-leading control system, as always!

Hey -

I'd like to build a "CoreXYUV" machine: two independent CoreXY gantries which share the XY plane. I have the mechanical and electrical design resolved, now making sure I can set it up in firmware.

Reading through the steps of this article on setting up a Cartesian IDEX machine, it seems like I could just follow these instructions while adding a few extra V commands where needed?

Has anyone done this and/or does anyone foresee reasons that it won't work?

Thanks!

@Phaedrux Yes, thank you. Will follow along there eagerly.

Actually, going to refine that prior post: It seems like, if I send a fully-formed M307 command, like:

M307 H1 A100 C800 D100 S1 V24.5 B0

I can program a higher dead time.

@sozkan

I greatly appreciate this thread as I'm trying to autotune a similar bed (very large aluminum plate with a 1.5KW heater).

It seems like I get a "Bad Model Parameters" in the M307 command whenever the D value goes above 70.

Since I have an (intentionally) somewhat underpowered heater, my dead time is probably right around there or a bit higher. This means I am not able to use the autotune on my heated bed, as it's still expecting more temperature rise than the heater produces. My approach now is to guestimate the model manually and then hopefully tweak it by hand once I can see how it's holding a temperature.

In general, it seems worthwhile to add a parameter to the autotune function which scales its expectations based on a user-input "guess" of how long the whole heatup process should take. I think this would correct a lot of the frustrations around autotuning I've had or seen others experience before.

@Phaedrux said in Horizontal banding defect, non-kinematic. Need some help!:

Are you not able to control the bed heating loop via the Duet so you can PID tune it?

I have the parts for that in hand, but was holding out with the hope that I could use the off-the-shelf controller for a few months and learn firsthand whether something more sophisticated (like a system with independently controlled quadrants & super well isolated AC) was the better path. Seems like I at least need something of a middle ground to start.

Ugh, solved. The primitive bang-bang controller of the AC heated bed system was causing enough temperature oscillation to generate slow-moving thermal expansion waves that caused this time-dependent layer variation. I'd initially dismissed this as the cause because the temperature variation didn't seem high enough to explain things, but since there are two independent AC zones running bang-bang, the two cycles were probably going in and out of phase with each other to double the amplitude. I ran one of the same prints after unplugging the at-temperature heated bed, and the finish is basically flawless. Time to build a more sophisticated controller for the heated bed...

Hey All -

Long time happy Duet3D user, first time poster here. I need some help with the finishing calibration of a large-format 3D printer build I've been working on. I'm having some pretty severe horizontal banding, and I've run out of ideas on how to resolve it.

First, some context: Hardware is a Duet 3 on a roughly 1m cube belt-driven CoreXY layout printer, with AC heated bed, E3D Hemera + Volcano hotend running direct drive. Printing PLA.

Second, what I've tried:

• My immediate thought with horizontal banding is Z stage imperfections, especially since this is a very large, very heavy (150lbs?) bed. However, after reviewing every known mechanical and electrical aspect of the bed, I wasn't able to show any meaningful impact to the banding - and, critically, I discovered when doing test printing that the banding got better/worse as the size of the test print changed smaller/larger. When I was printing large (in XY) test objects, I had intense, high frequency (in Z) banding, and small (in XY) test objects, I had moderate, low frequency (in Z) banding. This indicated to me that it was not likely tied to the Z stage mechanism but something else in the system that was linked either to filament consumption or a time-dependent factor.

• Then, my thinking went to extrusion variation. I checked every possible source for filament thickness variation or filament friction, as well as all of the electrical settings around my extruder and hotend, but was, again, unable to see a direct influence on the horizontal banding. However, while doing these tests, I discovered that the banding was not related to filament consumption rate, but it was correlated with layer time - objects & regions with faster layer times showed less horizontal banding.

Finally, where things stand now, and a picture: If I run the exact same test print gcode file, but use DWC to change the speed factor from 50% to 100% to 150%, I get drastically different amounts of horizontal banding in the print - where, somewhat unexpectedly - the faster prints exhibit far less banding. Attached below is a photo of the same print run three times back-to-back. The top one is 50%, middle is 100% (roughly 50mm/s print speed) and the bottom one is 150%.

https://photos.app.goo.gl/HUCjTLtbtLopSzaK6

Any ideas on what might be causing this? It seems like there is some sort of time-dependent layer thickness or flow rate variation in my system.