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
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
@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.
-
@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.
-
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...........
-
@deckingman sure, sorry, just trying to cover all the bases...
Ian
-
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
-
@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.
-
@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 -
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?
Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!
-
@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?
-
@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.
-
@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.
-
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
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.
-
Could I also respectfully ask those trying to help, to read the previous posts. Repeatedly answering the same questions is more than a little tiresome.
-
what is the size difference between the 2 parts printed ? i can estimate the size of the chuck holder but have no reference for the second "bad" print .
you mention using post processing script to generate uv moves , can this script alter xy moves somehow (is that a secret script) ?
did you try printing without post processing ?do you use anything variable in the slicer (layer height , extrusion , infill etc) ?
if it was a print without any post process / pressure advance /variable slicing i would say that you have extrusion problem at particular feed rates . your "bad" print has some good corners .
-
Update.
I've printed the exact same part as before, with the exact same settings and with the exact same firmware (3.2.2.).
Here are some pics of both parts........
OK, the one on the rights isn't perfect but it's "acceptable". I'd say it needs a tad more retraction but that's entirely consistent with my having disabled pressure advance.
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.
-
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).
-
@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.
-
@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.
-
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.
