If you remove the nut does the leadscrew wiggle on top during rotation? If it does then that is likely the reason for z banding. Leadscrew nuts are almost never a problem nor is their clearance because they are just used for pushing up and down. After a lot of experiments I've concluded that most of info on the topic of z-banding is simply wrong and now I have a fix that works for my printers every time.

So I had these problems appearing semi randomly (because I often disassemble the printer) until I realized that due to the coupling there is sometimes a bit of wiggle which is caused by screws that tighten coupler to the leadscrew and to the motor shaft (different diameters of the leadcrew and the motor shaft don't help here). This was actually discussed on this forum so you can look up these discussions. Screws should however not affect the coupler you use as much since it clamps, however that coupler is not really built to keep the leadcrew perfectly centered and in my tests it had biggest eccentricity compared to three other types of couplers (its called elastomeric coupling after all). With rigid couplers the procedure I use now is to mess with tightening the coupler until there is no wiggle on top then just add the nut afterwards. The nuts I use are very cheap ones with huge clearance and they work just fine.

You can already notice that constraining the leadcrew is related to the couplers and over-constraining is a problem only when you use rigid coupling at the bottom that is not centered, however the coupler you use requires constraining the leadscrew preferably from both sides (you want a straight leadscrew). Just check the design of CNC machines and you will notice how these couplers are used. Note that ballscrew does not magically solve this problem but because it should have almost no play with well constrained bed it will force relatively precise movement in z axis (for 3d printer at least) even when it eccentric but its definitely a waste of money considering other solutions.

If you don't want to mess much with z axis design you can always get stepper motors with integrated leadscrews which will make the whole problem disappear. Paradoxically the price of these motors from aliexpress will almost match the price of motor + coupler + leadscrew.

The problem is definitely more visible with 2mm lead. Additionally you want to isolate all other variable i.e. do a print without heated bed, turn off bed leveling compensation, turn off z hop, have bed rails aligned and squared and so on. When solving this printing cubes close to all leadscrews plus one at the center of the build plate helps to find out which one the screws is the worst offender.

Good luck!

@Zhang-Jianyu thanks for the remainder that duet switches negative side, I always forget that... There is a small potential difference between the earth and V- (V- is not grounded) so I thought to mention it albeit it should not matter.

@Phaedrux the graph looks like this at 20:20 there is a bump in temperature by 10 degrees and you can see the first oscillation. Note the graph is with very slow test print, with faster printing it gets much worse but anyhow its hard to see those small oscillations of this scale.

I doubt that config is relevant but I know you like to check them so I'm attaching it. config.g

@dc42 They are indeed consistent however they are wrong. Increasing dead time helps but it doesnt solve it. The new algorithm is much better at estimating the dead time as you said in the other thread. Nice thing is that dead time estimation works so much better that my bed PTC heaters are more stable (I raised previous dead time myself to 13):

M307 H0 A150 C1076 D13 S1.00 V0 B0
M307 H0 R0.187 C1024.9 D13.97 S1.00 V0 B0

C * R ~= 190 but I lowered the A myself previosly and I dont remember what was the estimation of old algo but I think it was around 250. Bed temperature still oscillates around in delta of 0.5 degrees which is quite bad for 8mm thick alu bed.

Speaking of T there is a typo in gcode wiki M303 T0 ; tune the primary heater of tool 0 (RRF 3.2beta3.2 and later) lacks S parameter.

What about MCU temp fluctuations and slightly inaccurate voltage readings?
I recently started to learn how to use the oscilloscope and now I wonder how to probe the system that switches ground?

Point taken

The fact that there are so many opinions is what makes it hard to find the right answer... I spent a while looking for the right sources for this and generally duet forum and reprap forum so far have the highest quality imho.

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

@gtj0 https://www.youtube.com/watch?v=ZXsQAXx_ao0

@achrn heater with a bit bigger radius would allow for wires from it to emerge directly upwards and you could pack the wire at the back of the heatsink so no problem with airflow. If you look at a lot of hotend installations you will notice that they are bent immediately upwards (or even worse sideways) but luckily the wires are flexible however its still a reliable way to kill the heater if you often mess with the hotend. Actually I think that even v6 hotend install instructions had a warning about that but don't remember clearly... Another thing that I had problems with, is that during catastrophic failures (hits) hotend heater wires would get hit which would be much harder if they were upwards.

@zapta said in New hot end system from E3D?:

PTC elements are used in most hot glue guns, eliminating the need for active control system. As a result, they take much longer than needed to heat because the power reduction starts to take affect very early. Here, they are targeting higher temperatures and have active control system so may have a PTC with a much higher infliction temperature.

During my testing of PTC heated bed I found out that it is not true that it heats up slower and I tested just a few typed of PTC heaters. The heating curves can be very different from PTC to PTC and I hope E3D produces repeatable PTC heaters. I wanted one for my hotend for a long time.

Semirelater to heater, does anyone know why aren't they putting cables upwards but sideways? So that bend of a cable would happen away from the heater which seems like a no brainer to me...

Thanks for the reply! Some of these are not completely clear to me.

@dc42 said in Duet with embedded "SBC":

Here are some reasons

1. Does anyone make a processor with A-cores, M-cores, and CAN_FD?

Not sure if CAN_FD is present in mentioned combo but I thought there are specialized IC's for CAN_FD?

2. It's most unlikely that we could compete with the cost of a Raspberry Pi + existing Duet. We don't have the advantages of scale that Raspberry Pi does.

Not sure how RPi can compete with pricing here since you would not have additional RPi cost but only the cost of Duet? Duet would likely have to be a bit more expensive due to using more expensive processor, though the currently one is definitely not cheap.

3. We would have to maintain our own Linux build.

I still have old Duet 2 without SBC so my understanding might be a bit off here but aren't you already maintaining your own linux build? Additionally base yocto and/or buildroot images are often provided by manufacturers.

4. We would have to provide technical support for all the functions that the SBC provides.

That's a tough one although considering how much issues you had with SBC communication maybe it would not be so bad. Just a thought.

5. Some users prefer to use a different SBC, such as Jetson Nano.

Definitely a downside although linux to linux communication is not so hard so people could easily add more computers if they wish to do so.

6. We would need to manufacture separate Duets for those who don't want the SBC functionality.

Maybe its misunderstanding here but I would not think that separate duet boards are necessary because duet would in that case effectively be SBC and maybe a stripped down version of linux could be made for those who absolutely would not want any applications.

Why duet hasn't taken the route of using processor that has both A-cores + M-cores to get rid of external SBC? Likely you have considered this approach so I'm curious of technical aspects that make this solution worse in comparison to M-cores only + SBC. Thanks

Count me in when you go for the second run

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

Do think I should line the floor as well?

Not sure how you missed the floor, space is after all flat.

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

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

I always find it hilarious when frequent forum members ask you to check some basic thing knowing well how crazy you are with your machine.

Cmon now. He's wise and skillful, but not omnipotent. Even the best among us have been caught out by the simple things. Thorough troubleshooting shouldn't be taken as a slight.

It is true that sometimes simple solutions hide in plain sight but he is debugging tricky firmware issue for a while so it is very unlikely that he didn't check obvious stuff. Additionally even after he debugs the temperature stuff he gets bunch of posts to debug temperature stuff. Reading some posts that he got over time I can understand why is he so frustrated.

@deckingman sometimes electronics works better when it heats up a bit, you know like good ol' machines (this is btw not a joke)

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

@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"

What about cosmic ray radiation

I always find it hilarious when frequent forum members ask you to check some basic thing knowing well how crazy you are with your machine.

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.

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