Poor print quality with RRF3 - especially 3.2.2.

deckingman

As requested, I'm starting a new thread. Not sure if this is the correct section. If not, feel free to move it.

Background.

This machine has cost me around £2.5k and has been refined over the years. Back in 2017. using Duet 2 hardware and firmware, it was capable of producing parts to trade show and museum exhibit standards. Since changing to Duet 3 hardware and firmware in 2019, the machine has not been capable of producing any parts to those prior standards.

The machine has largely been idle since the "upgrade" to 3.2 which left me with extruders running backwards when first applying power, and "homing failed" messages. I "upgraded" to 3.2.2. when it became available and can confirm that the extruders no longer run backwards. I had already changed all my homing files as a work around for the homing failed messages and I have not changed them back, so cannot confirm if that is fixed (but it most likely is).

I can also confirm that the machine no longer suffers from the appalling low step pulse frequency which had (unknowingly) plagued me for so long.

Current issues.

The first print with firmware 3.2.2. seems that pressure advance is broken as I reported in another thread on 22nd Feb. I didn't take pictures at that time but with this print, the ends of the infill lines were raised and rough, and there was a significant gap between the infill and the perimeters. So much so that when I removed the aborted print, I had two parts - one was the outer shells, the second, completely separated was the infill section. I disabled pressure advance and the next print did not have any of those particular problems.
The second print (with pressure advance disabled) produced this, which is what one might expect to see as a first print from a complete novice using a cheap kit which cost less that two of my 6 extruders. There is so much wrong with it that it's hard to know where to start.

The machine settings are all the same as when this machine produced museum exhibit standard parts, as are slicer settings. In this case, the hot end is a simple, single input device - nothing exotic and it has produced half decent parts with firmware 3.1.1.

Filament was PLA - the same batch and brand that I've been using for years. The print faults are not consistent with this being a reel of filament that has degraded since I last used it.

Print temperature was 195 deg C - derived from regularly printing temperature towers and unchanged for years.

Retraction was 1mm - derived from printing retraction test parts. higher retraction with this particular hot end causes blockages in the heat break.

Part cooling was none for the first 3 layers, then 50% fan speed thereafter - derived from years of experience and testing with this part cooling solution.

Print speed was 80mm/sec but reduced to 50% (40mm/sec) for outer perimeters and top and bottom layers. Travel speed was 350mm/sec. All derived as above, from years of testing.

The only differences between the part pictured above and previous half decent prints is that pressure advance has been disabled (because the prints are even worse with it) and the firmware has been "upgraded" to 3.2.2. from 3.1.1.

Conjectural thoughts

Having slept on it, and thought long and hard, I have a gut feel that this is all related to a combination of using expansion boards and multiple axes. This isn't my area of expertise so I can only guess, but my suspicion is that something isn't synchronised somewhere. The biggest difference with this machine and others is that it has multiple gantries and that Duet gen 2 could cope with that without any problem, but Duet gen 3 cannot. That's just conjecture on my part - I have no evidence to back that up (other than the appalling bad print quality).

Some time back, I altered things so that the UV and AB gantries are no longer mapped to the XY axes but kept separate. I then use a post slicer python script to generate UV (and AB moves). This was working reasonably well with 3.1.1. firmware and I did a couple of YouTube videos about this new motion planning technique. Here is a link to it in action with RRF 3.1.1. https://www.youtube.com/watch?v=rOP9QYAlhZU&t=525s

Note that the print quality in that video with RRF 3.1.1. is half decent and does not exhibit any of the problems that are apparent in the above print using RRF 3.2.2.

So UV moves are no longer the same length as XY moves - maybe that's what has got screwed up with 3.2.2. ??

Or maybe it's just the way that axes are assigned to boards. XY and Z are on expansion board 3, the 6 extruders are on expansion boards 1 and 2, UVA and B are on the main board.

Planned tests.

I can dissable the AB load balancing gantry and remove all references to AB from the config files, macros, and the post processing script. Now that the 6 heavy extruders no longer replicate the hot XY hot end moves, the machine no longer rocks around with high speed moves, so it isn't necessary. But it's a lot of work to change all those files and scripts.
I can map UV to XY such that the two gantries are combined and the firmware doesn't have to synchronise UV moves to XY moves where those UV moves are shorter than the XY moves, Although then I'd have re-enable the AB gantry.
I can look at whatever other sensible suggestion arise from this post.
I can try 3.3. beta firmware if there is any likelihood that it will improve anything.
I can tear out the gen 3 hardware and revert back to gen 2.
I can give up completely.

droftarts

@deckingman can you post the Gcode files, both before and after your post-processor?

Is the first picture of the corner where the perimeter ends? Are the other corners the same?

To me, your pictures look like the extruder is continuing to extrude at the end of a line, or there is a lot of hysteresis. Are you sure the retraction is happening, and in the right direction? Can the motor cope with the retraction speed requested, or is it just skipping?

Suggestions:

A video catching the behaviour would help. If it could somehow show the motor movement at the same time, even better.
Reverting to 3.1.1 without changing anything, and printing same part with exact same settings, would be a useful comparison. This would show if there was a difference between 3.1.1 and 3.2.2 regarding retraction/extruder moves.

Of your suggestions, I’d go for number 2.

Ian

deckingman

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

@deckingman can you post the Gcode files, both before and after your post-processor?

Is the first picture of the corner where the perimeter ends? Are the other corners the same?

To me, your pictures look like the extruder is continuing to extrude at the end of a line, or there is a lot of hysteresis. Are you sure the retraction is happening, and in the right direction? Can the motor cope with the retraction speed requested, or is it just skipping?

Suggestions:

A video catching the behaviour would help. If it could somehow show the motor movement at the same time, even better.

Reverting to 3.1.1 without changing anything, and printing same part with exact same settings, would be a useful comparison. This would show if there was a difference between 3.1.1 and 3.2.2 regarding retraction/extruder moves.

Of your suggestions, I’d go for number 2.

Ian

I've an update coming soon but in the meantime, 3 of the 4 corners are the same (and bad), the 4th corner is halfway decent. All 4 corners have a reasonable section for the first 6mm or so, and for the last 4mm of the Z height. I don't understand why the verticals are curved.

Retraction was visibly OK as far as extruder behaviour is concerned.

Further update coming soon (and it will surprise you)........

droftarts

@deckingman I think the vertical curve is from corners warping up and pulling in. Except for the other issues, I’d usually attribute that to too hot heat bed, too hot extrusion, not enough cooling, over-extrusion, or a combination of those. I doubt it’s a XY positional error.

Ian

deckingman

OK so here is an update. I needed a collet chuck holder for my garage. I don't give a sh*t what it looks like as long as it's a functional part. So without changing anything at all, I set the printer going to make that part. I had cycled power over night and of course it's a different gcode file.

But, it's the exact same slicer settings and the exact same filament from the exact same reel, with the exact same machine configuration. Although not perfect, it's as if it was produced on a different machine to the previous print. Here are some pics

Like I said, it isn't perfect but it doesn't exhibit any signs of the bad behaviour that the previous print had. I could live with that and a small tweak here and there would fix those relatively minor imperfections.

But this the problem. I never know what the machine is going to do from one day to the next with the exact same settings.

JayJay

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

@deckingman I think the vertical curve is from corners warping up and pulling in. Except for the other issues, I’d usually attribute that to too hot heat bed, too hot extrusion, not enough cooling, over-extrusion, or a combination of those. I doubt it’s a XY positional error.

Ian

It is no wonder the OP is frustrated, people seem hell bent on looking to blame something else instead of facing the reality of the OP's Issue..

The OP is obviously NOT some inexperienced user fitting a Duet board to an Ender-3, so why treat him in that manner, that is condesending and an insult to his obviously considerable intelligence.

The common denominator is the firmware (and possibly the hardware) if previous settings which worked on RRF2/Duet-2 (or an earlier version of RRF3) no longer work on later RRF3/Duet-3 that means that the "newer" firmware (and possibly the hardware) is not the evolution it should be (the terrible initial step pulses on Gen-3 hardware prove that assertion to be correct) And if you are now openly blaming things such as incorrect cooling or incorrect temps and intimating that they now require to be changed to compensate for a firmware update, well that is proof that any firmware "update" has not been an evolution but a retrograde step.

dc42

@deckingman, thanks for starting this thread.

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

Note that the print quality in that video with RRF 3.1.1. is half decent and does not exhibit any of the problems that are apparent in the above print using RRF 3.2.2.

I would like to establish for certain whether this is a regression in firmware 3.2.x. Apart from the homing file changes to work around the original issue with using M109 in a homing file, have you made any other configuration file changes? In particular, I recall that you wanted to increase extruder microstepping. Did you do that with the switch to 3.2.2?

What I would like you to do is this:

Set up configuration files that work for both 3.1.1 and 3.2.2. If you have suitable RRF 3.1.1 config files, I think those should be suitable for RRF 3.2.2 as well. If you are starting from 3.2.2 then you will need to use the A parameter in M307 in place of the R parameter. They are related by G = C * R.
Pick one print that was poor using 3.2.2, and print that (or part of it) using 3.1.1 and using 3.2.2 with the exact same configuration files. That will tell us either that the issue is indeed a regression between 3.2.2, or that the poor print quality is because a configuration change (e.g. increased microstepping) has triggered an issue.
If the 3.2.2 print remains poor, change the main and expansion board firmware to 3.3beta1. This might resolve the issue (see the 3.3beta1 bug fixes listed at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC#reprapfirmware-33beta1), but even if it doesn't it will provide additional diagnostics. After homing but before printing, please run M122 for all 4 boards to clear the statistics. After printing, run M122 for all 4 boards again and post the results here.

deckingman

@dc42 Did you see the second post I made? It was timed just 7 minutes before you posted so you may have missed it. In summary, a second (but different) print with all the exact same settings and with the same filament exhibited hardly any of the issues with the previous print.

This is part of the problem - there is something seemingly random going on which leads to inconsistent and no-repeatable behaviour.

Ref your #1, I can confirm that the only change to config.g between firmwares 3.1.1. and 3.2.2. was the necessary change to M307. I did however, re-tune the heaters using the new algorithm.

But, the second print shown above would indicate that the problem is not related to hot end temperature (because that second print with the exact same settings does exhibit the same problems).

But for info, here is the relevant part of my config.g showing the only change that was made

;M307 H1 A387.2 C482.9 D2.9 S1.00 B0 V26.9; With filament loaded as of 05/06/2020
M307 H1 R1.094 C414.0:272.7 D7.21 S1.00 V26.9 B0 ; RRF 3.2 as of 08/01/2021

It should be obvious that the commented out M307 was with RRF 3.1.1.

Ref your #2 - I'll print that part again but still using RRF 3.2 because I have no idea if it will print OK this time or still be as bad as it was before. If it is just as bad, I'll revert to 3.1.1. and see what happens. Then move on to 3.3. if necessary.

EDIT. ..and I should have said that all micro-stepping remains at 16x with interpolation - including the extruders. Although I have established that I can now use 128x with a mixing hot end, I haven't made that change (mostly because this particular hot end is a simple, single input one).

droftarts

@JayJay @deckingman asked specifically about the walls. They ARE CLEARLY pulled in. To paraphrase, I said that “normally” it would be these things, “except” there is something else going on. I don’t see that as a condescending answer.

If you have a constructive observation, please do contribute. There’s been enough generalised rants recently, with little substance for the Duet3D team to actually address.

Ian

dc42

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

Did you see the second post I made? It was timed just 7 minutes before you posted so you may have missed it. In summary, a second (but different) print with all the exact same settings and with the same filament exhibited hardly any of the issues with the previous print.

Thanks, I've read that post now.

Ref your #2 - I'll print that part again but still using RRF 3.2 because I have no idea if it will print OK this time or still be as bad as it was before. If it is just as bad, I'll revert to 3.1.1. and see what happens. Then move on to 3.3. if necessary.

Yes please. Please keep an eye on the hot end temperature while it is printing with RRF2, because I agree with @droftarts observation that some of the problems in your photos look similar to issues caused by excess temperature or insufficient cooling.

JayJay

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

@JayJay @deckingman asked specifically about the walls. They ARE CLEARLY pulled in. To paraphrase, I said that “normally” it would be these things, “except” there is something else going on. I don’t see that as a condescending answer.

If you have a constructive observation, please do contribute. There’s been enough generalised rants recently, with little substance for the Duet3D team to actually address.

Ian

Oh the Irony, you are trying to intimate that pointing out facts of your post does not help over come the OP's issue.

One could assert that for you to say that those issues are "usually" caused by cooling and temp issues also do not contribute to overcoming the OP's Issue thus by your own assertion pointless.

My contribution was/is to try to assist you recognise that there is a mindset issue, a mindset issue that has led to the OP feeling frustrated to the point of him feeling like walking away from using the Duet. And your reply only proves my point of that mindset and the systemic failure to recognise it.

deckingman

Calm down everyone.

@droftarts For info, I did find this condescending and unhelpful- quote

Are you sure the retraction is happening, and in the right direction? Can the motor cope with the retraction speed requested, or is it just skipping?

I think you now me well enough to know that I'd have checked all the obvious stuff. But let's forget that and move on...........

droftarts

@deckingman sure, sorry, just trying to cover all the bases...

Ian

fcwilt

I recently had a part cooling problem that looked very much like the pictures of the poor quality print.

Is it possible there is a intermittent connection to the part cooling fan(s)?

That might explain the unpredictable nature of the print quality.

Frederick

deckingman

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

........................ Is it possible there is a intermittent connection to the part cooling fan(s)?

None that I can see or detect.

timcurtis67

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

Hi Ian,
In my opinion the logical first test is your choice #2

"I can map UV to XY such that the two gantries are combined and the firmware doesn't have to synchronise UV moves to XY moves where those UV moves are shorter than the XY moves, Although then I'd have re-enable the AB gantry."

Seems like it would take some work load off the system. I'm sure it can handle it but this would be a good way to confirm it.

And then work from there.

Personally I have withheld making the jump to 3 just from the complexity of it all. I feel it will be a great product after some time and I love the direction Duet is going with CANbus.

I need to build an extra printer so I can devote time to the upgrade. I just can't afford to have any printers down right now with debugging.

Cheers,
Tim

DocTrucker

Cooling fans and reaction times on a big mixing head are slow. Looking closely at the problem pictures the built quality on the larger surfaces looks spot on.

Ian, with your current settings what sort of distance does the machine travel while accelerating? Still running without pressure advance? Any idea how much distance would be added if you include the area that is effected by PA?

Does it appear to go bad before, after, or symetric around the trouble corners?

arhi

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

I can dissable the AB load balancing gantry and remove all references to AB from the config files, macros, and the post processing script. Now that the 6 heavy extruders no longer replicate the hot XY hot end moves, the machine no longer rocks around with high speed moves, so it isn't necessary. But it's a lot of work to change all those files and scripts.

IMHO having that as "optional" would be great, moving all that to a separate file that can be load or not might be a good idea in the long run so why not go with it sooner than later, not that you can print anything

Testing without these 2 axes will show if those 2 additional axes are making a problem. Not many ppl use a lot of axes with duet3d (looking at multi axis CNC machines I still don't see many of them use duet3d hw) so it is maybe not something that's properly tested. I doubt this will be a solution but as you might do it anyhow..

I can map UV to XY such that the two gantries are combined and the firmware doesn't have to synchronise UV moves to XY moves where those UV moves are shorter than the XY moves, Although then I'd have re-enable the AB gantry.

If I remember your writing, you stated that while AB gantry did eliminate the machine shaking it did not affect print quality so I assume you can map UV to XY and not reenable AB gantry. The machine will shake and dance a bit but it will not affect print quality. I believe for the test that is acceptable. This will remove 2 more axes from the story, with [1] that's 4 axes less... Again I doubt it will solve the problem but at this point who knows.

I can look at whatever other sensible suggestion arise from this post.

If firmware creator want to spend some time on this I'll bet they will need a bunch of tests with "exactly the same" everything except for a single simple change + logs for you to find a 2 test scenarios that produce good and bad piece and where theer's only one or two changes between them... It is hard to debug and require both you and firmware creator to spend a lot of time debugging and is going to be frustrating at first I'm sure.

I can try 3.3. beta firmware if there is any likelihood that it will improve anything.

From what I understand 3.3b has a lot more logging and for that alone I believe testing 3.3 is worth it.

I can tear out the gen 3 hardware and revert back to gen 2.

I can say that on a "regular" printer (dual extruder, cartesian, nothing special) on duet2 firmware is only getting better, I have seen no issues so far, def. no worse quality, but I doubt that's comparable to what you are doing.

I can give up completely.

please don't.

few questions

is this water cooling setup or air cooling setup
is this your design single input extruder or something commercial?

deckingman

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

Cooling fans and reaction times on a big mixing head are slow.

As per my previous posts, this is with small, single input hot end - not a large mixing hot end.

Looking closely at the problem pictures the built quality on the larger surfaces looks spot on.

That's true for the second print but not for the first print.

Ian, with your current settings what sort of distance does the machine travel while accelerating?

Well actually, the machine doesn't travel at all - it just sits in the same spot inside a booth in my garage.

On a slightly more serious note, if my maths serves me correctly, then with the acceleration set as it is to a modest 1000 mm/sec^2, it will take 0.08 seconds to accelerate from a starting velocity of zero to the print speed of 80mm/sec for inner perimeters and the distance travelled during that acceleration phase would be around 3.2mm. On the other hand, if jerk is applied than the initial velocity would be 15mm/sec (900mm/min) so the corresponding change in velocity would take 0.065 seconds and the distance would be 2.11 mm. But for the outer perimeters, the speed is 50% of the "normal" print speed so only 40mm/sec. In which case, the times and distances are reduced to 0.04 sec and 0.8mm without jerk and 0.025 sec and 0.3125 mm with jerk applied.

So in summary, the distance that the carriage moves during the acceleration phase of print moves is between 3.2 and 0.03 mm depending on whether it's an inner perimeter and infill, or if it's an outer perimeter and/or if it's the first move of a layer change or if "jerk" is applied.

Not sure how any of that is relevant.........

Still running without pressure advance? Any idea how much distance would be added if you include the area that is effected by PA?

Again, as per me previous post, pressure advance seems to be broken (or at least it was on an earlier print) so these two prints were done without.

Does it appear to go bad before, after, or symetric around the trouble corners?

Seems pretty symmetrical on the first print - corners look good on the second print. But as per previous post, 3 of the 4 corners are bad, the 4th corner is fair. Also, yet again can I refer you back to my earlier post stating that for the first and last n mm of Z travel the corners are fair to reasonable.

dc42

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

From what I understand 3.3b has a lot more logging and for that alone I believe testing 3.3 is worth it.

Yes, if the issues are anything to do with CAN messages being delayed or lost then 3.3beta will reveal it in the M122 logs.