Copper heat blocks for the Core One are turning out to be a bad idea
Switched over to copper heat blocks because, they are copper and not aluminum. Seems like the extra mass is creating issues with homing, Y axis calibration, input shaping and possibly the cause of my recent layer shifts. Also, they take a lot longer to reach the set temperature and this is also a cause for the heat block calibration test to fail. Switched back to aluminum and haven’t seen the Y-axis test fail and (so far) the layer shifts appear to be gone.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
Another thing to add, I've noticed the thumb screws have a tendency to loosen up more which obviously is a problem. It could be because of the extra mass. Not sure.
RE:
As a general rule, copper blocks are better than aluminum. Because of the higher mass they keep a constant temperature better than aluminum and they also endure high tempeatures without trouble ( if they're plated ). Obviously the hotend must be designed with a copper block in mind. As you noticed, if this isn't the case, there might be trouble ahead.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
They were advertised as being compatible with a Core One. I'm sure they would work fine in a MK4 where the extruder is only accelerating in the X direction.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
The copper block should pose no issues with the Core One. The 25 grams extra mass of copper vs aluminum is inconsequential compared to the mass of the rest of the extruder. As for two axis vs one being the issue; well, that's hilarious. Mass is mass, slinging it one direction is exactly the same as slinging it another. Unless of course we are approaching an event horizon perpendicular to one of the axis.
RE:
The copper block should pose no issues with the Core One. The 25 grams extra mass of copper vs aluminum is inconsequential compared to the mass of the rest of the extruder. As for two axis vs one being the issue; well, that's hilarious. Mass is mass, slinging it one direction is exactly the same as slinging it another. Unless of course we are approaching an event horizon perpendicular to one of the axis.
Have you tried it or are you just speculating and trying to sound authoritative? Basically if you don't have anything concrete to offer then please stay out of the conversation. Had you said: "I'm using copper blocks and I don't see the same issues" I would have taken that as a legitimate response.
They were causing problems such as Y axis calibration failures and layer shifts in the Y direction that went away when I switched back to aluminum and print the exact same g-code. I swap out for copper, print again and it's back. So how would you explain it then?
RE: Copper heat blocks for the Core One are turning out to be a bad idea
You've probably assembled something incorrectly in the Y axis. Something is already dragging and close to failing. Rod bearing not properly packed and lubricated is my guess.
RE:
Y axis has been fine since the beginning of the build 2.5 months ago and stopped being OK for 1 week (the period of time I was using those blocks) and now it is OK again. Gantry moves freely, there are no cable snags etc. I insert a copper block run calibration, it fails 5x. Insert aluminum block it passes 5x. Put copper block back it fails again. So based on these statistical samples, what conclusions would you make from it?
I just did a big print overnight with aluminum and no issues. The other thing about the copper blocks is it fails the heater test. However that can be explained away and ignored. Other than stable temp and the ability to run it hotter I really don't see any advantage over aluminum. And again, I have been actually using/testing them with a variety of filaments and nozzles and my conclusion is that they are not fit for purpose on my Core One.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
I'm using a copper block and I don't see the same issues. FWIW, I'm using them on an XL5T as well. Is there a particular item that reliably replicates the issue? I'm willing to run a print.
RE:
I'm using a copper block and I don't see the same issues. FWIW, I'm using them on an XL5T as well. Is there a particular item that reliably replicates the issue? I'm willing to run a print.
I had really decent prints from them with simple shapes and PETG until I switched to Nylon and started getting layer shifts but only in the Y direction. Because of the layer shifts I checked the Y axis calibration and it kept failing. IDK, maybe it's just me. But regardless it's good to know that others are using them and not having issues. Perhaps for me it's just an edge case. Regardless, I never had issues with aluminum so I'll just stick with that.
Anyway, thank you for the kind offer however this specific print is for my friend's business so unfortunately I can't give it out nor post an image.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
This brings up an older topic. If you over tighten the bearing holders, you can crush the bearing and cause excessive friction. Once crushed, you can try releasing some of the pressure, but too often once the bearing is damaged it needs to be replaced.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
Tried to edit nut times out, dang I hate this site.
Another issue is the Y rails may not be parallel: use a force gauge and (powered off) pull the extruder back to front and see if the reading changes or you see any sticky spots.
And, for your curiosity, you can tape a few quarters to the extruder to match the added cu vs al mass. If it is really mass affecting your cal, the issue should return. That said, functionally, 25 grams of mass requires milli-joules to accelerate to printing speeds. Your motors will never notice.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
I have been using a nickel plated copper heat block with a .4 Diamondback nozzle from day 1 with no discernible issues.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
Oh, one other question: did you perform a nozzle PID after installing the copper block? If not, excessive temp swings by the algorithm might cause printing issues with nylon and other filaments. Basically, the control loop is out of control when you change the timing of thermal rise between the heater and thermistor, and needs to be recalibrated.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
ps: Unless the Heater Test does the PID, looks like Prusa in their infinite wisdom moved a critical cal into Pronterface only ... lol
M303 - M303: Run PID tuning
PID relay autotune
Parameters:
S<temperature>: sets the target temperature. (default 150C / 70C)E: (-1 for the bed) (default 0)C: Minimum 3. Default 5.U: with a non-zero value will apply the result to current settings.
RE: Copper heat blocks for the Core One are turning out to be a bad idea
I actually weighed the stock aluminium heater block and the copper one before switching to copper, and it was 5.930g vs 19.908g so extra 14g of weight is almost nothing compared to the whole nextruder assembly. Heater test is passing and temperature looks stable during prints without significant overshoots, however I will try to retune the PID based on Tim's information.
RE:
I actually weighed the stock aluminium heater block and the copper one before switching to copper, and it was 5.930g vs 19.908g so extra 14g of weight is almost nothing compared to the whole nextruder assembly. Heater test is passing and temperature looks stable during prints without significant overshoots, however I will try to retune the PID based on Tim's information.
The only issue with retuning PID is that it doesn't store this in firmware and it will have to be injected as g-code. That said, the heater test failing was simply caused by accidentally having turned off the silicone sock setting.
Also, when I was using the blocks I didn't have any issues with overshoot or oscillations which means there is no reason to recalibrate PID.
I can't really explain this but then I did enough tests with Y axis calibration to at least allow me to infer that the copper block was this issue with the failures. Maybe it was triggering an edge case? I don't know. Suffice it to say for me, problems with Y axis layer shifts and calibration failures went away when I switched back to aluminum. It could be a coincidence but personally I don't think so.
I'm still on the alpha firmware so maybe there is a bug there? Who knows? Right now I can't back out to 6.3.4 firmware because when I do my Buddy3D camera gets hosed and I have no idea why yet. Doesn't make sense.
When the 6.4.0 is in RC maybe I'll give the copper blocks another go.
RE:
I'm on 6.4.0 alpha too, just decided to give PID autotuning a go and see if I could get better results. Unfortunately M500 command seems to do nothing and after restart you have defaults again, so as you mentioned the only way is to add it as a custom G-code.
Initially I ran M301 command to see the defaults right after clean restart and later after a print without injected g-code, results as follows:
M301 echo: p:14.00 i:1.00 d:100.00 ok
I thought maybe printer does automatic live tuning during the print but it seems to be not the case.
Then I ran a PID calibration cycle for the nozzle for 20 cycles:
M303 E0 S210 C20 ... PID Autotune finished! Put the last Kp, Ki and Kd constants from below into Configuration.h #define DEFAULT_Kp 28.60 #define DEFAULT_Ki 2.93 #define DEFAULT_Kd 69.79
so it's quite different to defaults with aluminum heater block, after unsuccessful playing with M500 I ended up adding P/I/D into my custom g-code
M301 P28.60 I2.93 D69.79
Nozzle now heats up noticeably/significantly faster to the target temperature and stays stable, so I guess copper block modders might consider tuning their nozzle PIDs ))
RE:
That is certainly easier (injecting g-code) than doing what it suggested by compiling your own custom firmware. Would be nice though if Prusa added a selection option in the firmware for the heatblock type. Maybe create a pull request for this.