Poor print quality with RRF3 - especially 3.2.2.

[akstrfn]

Thanks this is much easier to examine visually. I would not expect your machine to have z banding problem but z axis certainly looks broken on all prints. Some prints look like they are of different height so maybe the issue that dc linked is related i.e. CAN bus issue? Most definitely it does not look like heat problem to me.

[JayJay]

I dont think it's a Filament Temp issue as it would manifest itself across the board when that isn't happening. if you look at the picture below that shows a temp related issue, the part on the left is at the wrong temp (too hot) and part on the right is at the correct temp.

[deckingman]

@JoergS5 said in Poor print quality with RRF3 - especially 3.2.2.:

@deckingman when comparing the two parts, the inner corner in the back on the right part is not ok also (S2700005), though not as serious. I think Duet 3 emphasises an effect which is also there in Duet 2. One reason I can think of is that Duet 3 uses more segments (because it has more power) and a calculation error or mismatch between movement and extruding becomes more visible. In some kinematics one can change segmentation (length and time of segments), maybe changing it is worth a try. (M669 T and S parameters)

None of the inner corners are what I would call good. But I think that's just a retraction issue due to my having disabled pressure advance and not increased the retraction amount to compensate. If you had the real part in your hands, rather than the pictures, I think you'd probably agree.

[deckingman]

Another day, another shite print. So apparently it's not that the firmware doesn't like Mondays.....

I printed the exact same part again, still with the same reel of filament and still with the exact same settings. This time I stood and observed the print for most of the time (about 80%). I can confirm that the part cooling fans appeared to be running throughout - both visually and audibly. I can also confirm that there were no temperature excursions other than about a 1.5 deg C drop when the fans first started, which very soon recovered.

The print is bad. No quite as bad as Monday's print but still pretty awful and much worse that Tuesdays print. Apart from some of the other defects, it looks like there is also a retraction problem - yet the extruder looked like it was behaving as I'd expect - but it's difficult to estimate if the amount of retraction is 1mm as configured just by observing the extruder gear. Aside from that, one of the corners is bad, one is fair and the other two are "acceptable" . There are also random zits, curvature on verticals, and strange patterns here and there.

So maybe something goes amiss if the name of the day has an "n" in it. That would explain why Monday and Wednesday produce bad prints but Tuesday is fine.

I've uploaded the pics to another folder on my google drive. I annotated them to highlight the most obvious problems, and I used shadow/highlight recovery because the lighting isn't too good but they are otherwise untouched.

But then just for the hell of it, I disconnected the part cooling fans and did another print, just to see how bad it could be if there was no part cooling. The resultant print is as good, if not better than Tuesday's print! Not perfect but night and day different to the first print of the day.

So Tuesday's print with fans, and the second print of the day without fans are almost identical and "acceptable" quality. Not perfect but I suspect that a bit more retraction or re-enabling pressure advance (if that would work) would sort out those issue.

Monday's print and the first print of the day (both with fans) are bad, although I would judge that Mondays' print is the worse of the two. Go figure.....

Because I never like to connect or disconnect anything while the boards are "live", I did turn off the power when I disconnected the fans. And of course, I had to re-home the printer. So there was a power cycle and re-homing involved between the bad and acceptable prints.

So it would appear that my earlier theory about there being in "n" in the day name is wrong - there must be some other reason...........

Here is a link to the folder with the pics. https://drive.google.com/drive/folders/1XmFXYBGnj3rXJRLg1muSNBd18AbP2ZDl?usp=sharing

The bad print pics are titled "Shite1 - 7". The better print pictures are entitled "NoFan1-4" (for obvious reasons). There is also 1 picture showing all 4 parts in case anyone thinks I'm making this all up.

So I think we can rule out the problem being related to over temperature due to intermittent part cooling. Other than that, I have no comment to make because I know that my judgement has been impaired by events of the last 19 months since changing to Duet 3.

What next?

[pkos]

I've been following your posts for a while now and I will freely admit, I do not remember everything that was said in them, but I just started wondering - if this is a test done on a simple hotend - would it make any sense if any of us got your gcode files and tried to print these objects on our printers provided they run Duet 3 6HC and at least one 3HC? Just to increase the testing device pool to see what else we can see?

I am not sure how the removal of your counterweight system would impact this here.

If it does make sense, I would be happy to take that gcode for a spin on my 6HC+3HC combo in a Voron 2.4 (where 6HC handles the movement, 3HC handles the extruder and hotend/part cooling).

[alankilian]

This is a HUGE discovery!

I don't know much about the many-board DUET3 ecosystem, but I'll give some uninformed advice anyway.

I've read that there are power-on timing (something) going on with some of the boards in the Duet3 ecosystem.

Having written firmware for about 40 years, I'm going to guess (and it's ONLY a guess) that:

• Something in one board or another isn't initialized on power-up
• Order of starting of RTOS tasks is unpredictable.
• Exactly how the several boards discover and talk to each other is not predictable.

Resulting in different internal states "somewhere" that is greatly affecting printer settings.

Now, how to tell? I'm not sure.

If @dc42 had a "secret" way to dump RAM from the boards, you could power-on and dump RAM several times and see where the differences are.

Or if there were a way to dump a lot of settings, you could also do that several times.

If I were the developer on this project, I would be jumping for joy that you have a reproducible failure/success test now.

If I were a user of this, I'd be not so happy to be "the one" with the exciting probelm.

[deckingman]

@alankilian As I said, I know that my judgement has been impaired by 19 months of firmware issues, so I couldn't possible comment.

[alankilian]

How are you with electrical engineering?

I'm thinking about your endstops.

You've got a REALLY stiff pullup from +5V (EXT-IN) to an I/O pin on the processor running at 3.3 Volts.

The LED will drag that down to about 3 Volts.

I'm wondering out loud if when you power-cycle, if the 5Volt supply is keeping the processor somewhat alive by powering up through the I/O static protection diodes.

I'm also wondering if these two problems (Homing not working and printing changing after power-cycle) are somehow related through this resistor.

I'm just hoping to help free-thinkers get new ideas on what's going on.

I'll dig a little through schematics and see what I can find.

If you feel like experimenting (I know. You've been asked WAY WAY too many times to experiment) maybe remove that resistor/LED and turn on the built-in pullup to see if at least your homing is fixed.

[deckingman]

@pkos I can make the gcode available if it's generally considered as being a worthwhile exercise. Parts are sliced completely normally. The magic with the UV (extruder gantry) and the AB (load balancing gantry) is done post slicer by adding UV and AB moves to the ends of the XY moves. But this is a non-destructive process which creates a new gcode file - the original remains intact. So I could share that file.

I do however use a 0.5mm nozzle which is less common than the 0.4mm nozzle that others use. I could also share the stl file.

But due to the seemingly random print to print variability, I'm not sure if would help. Let's see what other people think.

Thanks for the offer............

[deckingman]

@alankilian I think it will be best if we keep these two issues separated into their respective threads.

But ref the pull up resistor value - that's as advised by the man himself - dc42. He told me how to wire it and what value resistor to use. I guess as he helped design the board, and he writes the firmware, he should know

[jens55]

Going through your last set of pictures, it seems to me that the corners are lifting a bit. This would explain some of the sketchy bits in the first 10 to 20 layers in the corners.
Obviously it doesn't explain anything about the higher up shite

WTH is up with the random zits ????

If it wasn't such a big effort, I would suggest a nozzle cam and recording the entire print. It would certainly reveal the zits issue but I am not sure if it would be helpful with the other problems.

[deckingman]

@jens55 said in Poor print quality with RRF3 - especially 3.2.2.:

Going through your last set of pictures, it seems to me that the corners are lifting a bit. This would explain some of the sketchy bits in the first 10 to 20 layers in the corners.
Obviously it doesn't explain anything about the higher up shite

The corner lifting thing might have just been due to me knocking the parts off the build plate before they had cooled. I certainly didn't notice anything untoward happening during the print. The first layer looked fine as it was going down. Dunno....

WTH is up with the random zits ????

No idea. There are no random zits when it it's printing well - only when everything else to do with the print is going pear shaped (almost literally).

If it wasn't such a big effort, I would suggest a nozzle cam and recording the entire print. It would certainly reveal the zits issue but I am not sure if it would be helpful with the other problems.

Sods law would dictate that if I fitted a camera, I'd never see those random zits again.

Besides, these days, with only my (diminishing) pension income, I don't have any spare cash to splash.

[gloomyandy]

Hmm interesting but very frustrating.

I wonder if there is any correlation with bad prints and room temperature? It's been pretty cold here (in the UK) the last few days and I know my workshop space is much colder first thing and will get warmer as the day goes on. Does the temperature vary much where your printer is?

[Phaedrux]

@gloomyandy said in Poor print quality with RRF3 - especially 3.2.2.:

Does the temperature vary much where your printer is?

Maybe, but I think he has it fairly well enclosed, so I suspect should be quite stable.

[arhi]

@deckingman said in Poor print quality with RRF3 - especially 3.2.2.:

No idea. There are no random zits when it it's printing well - only when everything else to do with the print is going pear shaped (almost literally).

My experience tells that every time you have a zit on a "decent printer" you had a hiccup ... either at least one of the motors "forgot" to turn or at least one of the motor drivers didn't receive the step pulse... in most cases, the whole firmware "freezes" for some milliseconds and zit happens. Maybe printing tight curves and cylinders would make the problem more prominent?

not something easily observed without high fps video..

Now, this issue with random behavior reminds me of a situation with RapMan some 10 years ago, right around mid-January printed started acting weird, crashing head into sides, trying to move at some weird speeds, and all kinds of crappy behaviors .. It started happening to a bunch of ppl at the same time without any changes... I finally measured some kilovolts on the nozzle and we solved the problem by attaching wet towels to the printer to increase humidity so that static electricity drops to acceptable levels... I don't think this has anything to do with your machine but since ideas are not pouring.. did you check if your nozzle is properly grounded?

[Phaedrux]

@deckingman were you able to capture a M122 (B1, etc) before and after the good and bad prints?

[deckingman]

@Phaedrux said in Poor print quality with RRF3 - especially 3.2.2.:

@deckingman were you able to capture a M122 (B1, etc) before and after the good and bad prints?

Nope. Do you think would help? TBH, I have more than enough of these little cases (they are for a Dig-Uno ESPbased addressable LED controller) that I'm reluctant to waste any more filament (and time, and energy) unless I have a good reason to do so.

[Phaedrux]

@deckingman I won't ask you to waste the filament on more testing, but if you do any more prints, yes, getting a diagnostic report before and after would potentially be helpful. Particularly if you try the 3.3 beta. Otherwise we're just looking at photos of good or bad prints and speculating.

Thanks for your efforts in troubleshooting. I don't think anyone should be dismissing any problem reports, regardless of how "niche" the printer may be. The Duet excels at reaching into as many niches as possible. A big part of the appeal is the versatility afterall.

The Duet3 and Canbus and the SBC are all very new to the ecosystem and all provide challenges and inconveniences to the early adopters, but we're trying to improve things and achieve the reliability users expect. Unfortunately it wasn't a seamless out of the gate experience, and unfortunately it's taking time to get right. But issues are being found and addressed and limitations are being removed. And that wouldn't be possible without people like you pushing the envelope, finding the gaps, reporting the problems, and working through it so things can be improved.

We do appreciate the time and effort you've put in then and now.

[deckingman]

@gloomyandy said in Poor print quality with RRF3 - especially 3.2.2.:

Hmm interesting but very frustrating.

I wonder if there is any correlation with bad prints and room temperature? It's been pretty cold here (in the UK) the last few days and I know my workshop space is much colder first thing and will get warmer as the day goes on. Does the temperature vary much where your printer is?

Ahh, now it's funny you should say that. The printer sits inside dust proof booth inside my garage. The garage is integral to the house, and is fitted with an insulated panel door (one of the best investments I ever made). there is also a small radiator connected to the house heating system and a freezer which helps to keep the place warm.

As it happens, as part of my ongoing home automation project (well I have to pass the time in lockdown somehow), I've made and fitted an ESP based garage door controller. As the ESP device had a few spare pins, I fitted a DHT22 sensor in the box as well, because why not?

So, I happen to have a record of the garage temperature (and humidity) over the last 24 hours. Now the sensor is up high, close to the garage door motor so it reads about 4 or 5 degrees higher than at "printer height".

But here is a snip from the ambient conditions tab of the Home Assistant dashboard on my PC.

The garage temperature and humidity are the purple lines. Min temp was 20.2, max was 26.7 but you can knock 4 or 5 degrees off that for the reasons given above. On the other hand, the printer sits inside a dust proof "booth" (about the size of double wardrobe) so the ambient inside there is little higher. Humidity is fairly constant (min 30, max 36).

So I can categorically say (and prove) that there were no wild excursions of ambient temperature or humidity.

I'll bet you didn't expect that sort of answer did you?

I'll also wager that some smart ar*s is going to say "what about barometric pressure"

[droftarts]

@deckingman what about barometric... oh, never mind.

Ian