Poor print quality with RRF3 - especially 3.2.2.

[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:

1. A video catching the behaviour would help. If it could somehow show the motor movement at the same time, even better.
2. 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:

1. A video catching the behaviour would help. If it could somehow show the motor movement at the same time, even better.
2. 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:

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

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

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

[deckingman]

For info, the hot end for these latest tests is an unmodified, "off the shelf" liquid cooled offering, fitted with a E3D 0.5mm standard brass nozzle, and E3D standard thermistor cartridge. The heater is either 30 or 40 watt - can't remember which off hand. The only concession is that I've made my own aluminium liquid cooling adaptors which have a 3mm ID bore, rather than using standard PTFE Bowden tubing with a 2mm bore. This greatly improves the coolant flow (3mm bore tubes have more than double the cross sectional area of 2mm bore). It's this one

https://www.amazon.co.uk/Printer-Water-Cooled-Bowden-fed-Temperature-Printing/dp/B07LB2JBFY/ref=sxts_sxwds-bia-wc-rsf-ajax1_0?cv_ct_cx=3d+printer+hotend&dchild=1&keywords=3d+printer+hot+end&pd_rd_i=B07LB2JBFY&pd_rd_r=2d8cbba6-4d79-49c3-962f-1fef0062a90d&pd_rd_w=vsVTN&pd_rd_wg=0WAzn&pf_rd_p=1aabc85c-55ad-45c0-9ed5-d72cba593538&pf_rd_r=BCPPCSQ8A3CK182Q601B&psc=1&qid=1614712444&sr=1-1-6bc49e3f-9798-4557-aecc-11e86e72dff6

I've printed temperature towers and retraction test parts to determine the best settings to use with this hot end. I've also tuned the PID parameters using the latest algorithm, with and without the part cooling fans.

In a nutshell, I've done all the basic stuff and if there was a problem with this hot end I would expect those problems to be consistent and not variable form one day to the next.