Poor print quality with RRF3 - especially 3.2.2.

deckingman

The chuck holder is about 143mm (x) x 60mm (y) by about 50mm (z). The case is is about 72m (x) x 58mm(y) x 31mm (z).

akstrfn

@deckingman the pictures are quite small, is that forum software doing somethis or you are putting small pictures?

Once I had a part cooling fan cable that was getting loose during some moves as luck would have it and my problem seemed similar to yours (already mentioned in the thread). This was difficult to figure without sitting down and watching the print as it goes and notice intermittent fan speed changes. However looking closer (as much as possible with small pictures) I don't think that cooling is the issue here because my parts would be more smooth in deformation in the middle, so printing lines were definitely not visible in the middle of shrink area (although this was ABS maybe PLA is different?). Its an easy check so maybe check few wires.

As a data point moving from RRFv2 to RRFv3 was weird with various glitches but I've always attributed random stuff to the fact that I once reverse wired the board (while solving jumpy voltage readings in my board). But I don't want to complain much since I don't contribute any code to RRF and dc should take some vacations.

dc42

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

The only difference between these two prints is that the first was printed yesterday and the second was printed today. Go figure..........
I can only assume that firmware is a fan of The Boomtown Rats and doesn't like Mondays.

Thanks for repeating that print.

I think the print on the left shows signs of high or fluctuating temperature, or usual temperature but insufficient cooling. The only ways that I think firmware could cause that are:

Assuming that the print cooling fan is connected to one of the expansion boards, then I guess it's possible that the fan failed to turn on at the end of the first layer, if that is where you turn it on. If the slicer never changes the fan speed again, that would leave it with the fan off for the whole print.
If the firmware used the wrong thermistor parameters then the temperature could be too high
If the firmware somehow set the wrong temperature then it could be too high

Of these, I think the first one is just about plausible, but the other two are extremely improbable.

As others have suggested, it's also possible that a loose wire or stuck fan caused the print cooling fan not to be running through that print. Do you run the print cooling fan at less than full power? If so, do you have a suitable full-power blip configured to ensure that it starts reliably? If your printer is in the garage and it was especially cold when you started the first print, then it's possible that a longer full-speed blip might have been needed to start it.

In theory a poor thermistor connection could also cause the temperature to read lower than it actually is. However, poor thermistor connections usually cause obvious fast temperature reading fluctuations, and often heater faults; so I think we can discount that.

BTW today I have been working with another user with 6HC and 3HC boards, and identified and fixed a CAN communication issue that was occurring with a sample print he provided. I don't think the main print quality issues visible on your first print are caused by the same issue, however it's possible that this issue could be affecting the fine detail of your print. That thread is at https://forum.duet3d.com/topic/21710/3-3b1can-timeout-resets-itself/14. If you try printing using 3.3beta1 then the M122 diagnostics will show whether that issue affects your prints.

jens55

Just as an FYI, I have had multiple occasions where fan speed changed because of friction on the bearing due to poor quality / cheap fan/ age. You can't see those changes but sometimes you can hear them.
I am not saying that this has anything to do with what you are experiencing, just saying that if cooling can cause these issues then it might be worthwhile changing the fan to see if the inconsistent behaviour changes.

In my experience the RPM of the fan can stay the same for long periods and then suddenly drop substantially before resuming normal speed. Sometimes speed goes all over the place.

Luke'sLaboratory

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

t

For What its worth - I've experienced similar things related to pressure advance. Similarily, stuff didn't overlap when i was very used to it working. Spooky.

I too have also had the same issues with step pulses, missing steps, etc using expansion boards, etc. I totally believe that you're experienced and have troubleshot stuff (and know what you're doing). Prints are iffy for weird reasons. Settings that work sometimes don't work. Weirdest thing i struggled with was constant jamming. 3.3beta fixed that. no other changes.

That being said - I spent an entire weekend diagnosing an intermittent issue with a CAN toolboard (not RRF, was actually for klipper) that involved trying several expensive new can adapters, network settings, re-crimping connectors, everything but the root cause - the wire had fatigue failed and was occasionally connecting long enough to start a print until eventually losing connection. Sometimes it may be the simple things.

Real suggestion: Are you using an SBC? If so - try going standalone. Spooky things happen with SBCs.

deckingman

I'll repeat that print again today and stand and watch it the whole time. I didn't notice anything unusual on the temperature graph - it was a nice straight line without any temperature excursions.
I'm not convinced that it's part cooling fan related. I often print parts without any cooling at all and I've never seen that sort of behaviour on corners. But there are two 30mm blower fans, one either side and they are audible, so it'll be easy enough to tell if they misbehave.
I've noticed something else strange too, but I'll start a new thread about that.

deckingman

@akstrfn The pictures have been resized to 500 pixels wide from their original 4000 odd. That's just because there is a forum limit on the file size which can be directly uploaded. I can upload the originals to my Google drive and provide a link if necessary. But the comparison between good and bad prints is like night and day, even at 500 pixels wide.

akstrfn

@deckingman its not about two obvious differences which are almost useless for any conclusion because one is a disaster and the other one is not. I've uploaded much bigger picture to this forum before so no need to make them so small (besides pixels there is also compression).

When debugging multithreading problems, which can be classified as random by the outside observer, you need to heavily focus on the bad case if you can catch it and you did catch it. So the reason why I commented the close ups is because printing lines would be more visible which could help us understand if duet gives wrong commands or you have a possible cooling problem. I wrote an explanation about it in my post but you are quite upset and skipped it apparently.

Next considering that on straight lines you seems to have good results you can eliminate whole host of issues e.g. mechanical ones but it can also point out that duet has issue with multiple small movements. If I'd have to debug this problem in RRF I'd start with sync between extruder and the other motors when cornering. What you can do without coding is to make an object with a lot of corners, few round areas and maybe throw in few long walls in it. Another thing that you can do when debugging wires that act weirdly it to print objects all around the build plate e.g. 9 objects or 12 equally spaced with max distances between them so that you cover all possible wire movements.

But I will mention again that from your pictures (small and compressed ones) it does not seem like cooling simply because your corner areas look like you have uneven layer lines on the corners i.e. one layer looks like its over another layer and also it seems that the problem hits at different heights at random. But I will mention again that this might be just my lack of experience with PLA which maybe degenerates just like whats on your pictures. ABS and PETG 99% does not look like that when overheated (it can actually look very nice).

I can understand the frustration when people tell you that there is no problem "because it works on my machine" which is very common for forums, but most people here are not saying so and believe that there is a real problem with RRF so please relax a bit.

jmshep

I have experienced very similar problems that came out of the blue. I had updated to 3.2 but I had not printed anything with high sides and sharp corners immediately after the upgrade and apart from adhesion issues and warping that sometimes happens anyway, I did not suspect the upgrade to 3.2 and nothing else had changed. I did wonder if the new PID tuning had something to do with it but like Deckingman, my temperature graphs were normal
After trying adjustment to all the usual suspects for this type of thing, I noticed that my part cooling nozzle, that had worked ok on similar prints for some considerable time, was not perhaps covering the corner as well as it should. Along with small tweaks to temperatures etc and a new cooling nozzle (with the same fan) everything came into place.
I was amazed how such minor changes had such a marked effect. I have printed with much wider variations of parameters in the past without serious problems.
I cannot speculate on why this happened and I just hope that my printer has not become over sensitive to minor variations for some reason! I watch with interest in the hope that there is a plausible explanation. I feel a 'downgrade' coming on.
DSCF7522.JPG

deckingman

@akstrfn I do get warning message that the file size is too big when trying to directly upload the originals.

I'm not upset ( well nor more than I have been over the past 19 months). Given what I've been through in all that time since "upgrading" to Gen3, I thought was being quite restrained.

Anyway, I've uploaded the originals to my Google drive. 15 files at circa 4Mb each which has taken me over more storage limit so I've had to pay for more.

Here is a link - hope you appreciate it https://drive.google.com/drive/folders/156BoxMJmqfhzyY04uJoM2z74NdlWg0Kn?usp=sharing

EDIT. I forgot that I used "Shadow/Highlight recovery" in paint.net to enhance the images before re-sizing them. So the originals might look a little dark (but you can play around with them to your hearts content).

JoergS5

This post is deleted!

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.

TEMPS RESIZED.jpg

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