The right most print doesn't look as good as the leftmost one. The differences between these two parts (first and last) is a similar issue to the photos of the blue part that the original poster posted. The middle two parts don't have the right lighting to decide what's what.
Best I can do right now. Can provide better photos tomorrow.
have you had time to make a better picture?
I'm really curious to know what results of your blind test are going to be.
Not yet, will do later.
Hi guys,
I've had this problem with my reprap, and it had to do with Z axis : it wasn't correctly carried, so Z axis pushed and pulled the extruder slightly, with the exact Z sscrew shape of the axis on the final model. It looks like the same problem here, you shoule check if the shape of your model matches the shape of your Z axis, and maybe you need to check your machine (i dont know the ultimaker design, so that's the best i can tell...)
Hi guys,
I've had this problem with my reprap, and it had to do with Z axis : it wasn't correctly carried, so Z axis pushed and pulled the extruder slightly, with the exact Z sscrew shape of the axis on the final model. It looks like the same problem here, you shoule check if the shape of your model matches the shape of your Z axis, and maybe you need to check your machine (i dont know the ultimaker design, so that's the best i can tell...)
Thx for tip.
But I'm printing a lot lately on the older firmware (14.03) and not once i had the bad surface quality that like the 14.07 firmware produces.
I just did another factory reset, then flashed latest firmware (14.09)
for me the problem is still there.
to test it this time i made a print on 14.03 than flashed 14.09 and print that same .gcode file with the exact same settings and conditions.
Can someone plz try the same and tell me if you are having the same experience?
.gcode file: https://dl.dropboxusercontent.com/u/22756276/test%20print%20v2.gcode%C2%A0(same%20as%20used%20before%20in%20this%20topic)
Edit:
I made an error in naming the firmware that gave the good result. (14.07 changed to 14.03)
Just a hunch, could you give the firmware of Cura 14.10_RC5 a spin?
http://software.ultimaker.com/Cura_closed_beta/
I changed a few things in there, including the temperature measurement&control stability. Maybe you are experiencing a temperature fluctuation (which I see happening in some machines at the office at well, but is quite rare, and this newer firmware fixes it for the machines in the office)
Hey, Daid
Thx for you reaction.
This weekend I will test cura 14.10_RC5 to see if it helps me with this problem.
I'll post te results here afterwards.
So i have tried the cura 14.10_RC5 firmware. (before i did a factory reset and changes no settings but the print temp)
In the picture you can see that it did not solve my problem.
I really like to use the new and improved features in newer firmware versions.
But for now in going back to firmware 14.03 :(
If someone is willing to do the same test, to see if this problem only occurs on my machine or not, I would be helped alot.
.gcode file: https://dl.dropboxusercontent.com/u/22756276/test%20print%20v2.gcode
Yesterday my brother and I spend the whole day figuring out how to compare the changes made in firmware on github, compiling them and localizing which change causes my problem.
After flashing a lot of firmwares (and printing a lot of those test pieces) we found the commit that causes the problem:
The date of this commit is: Apr 18, 2014
Committed by Daid
Change text: Fix compiling with PIDTEMPBED disabled.
Number: f1ec4aa9ad500ce98c206ea0fb8aab05e49ebce7
Link: https://github.com/Ultimaker/Ultimaker2Marlin/commit/f1ec4aa9ad500ce98c206ea0fb8aab05e49ebce7
Although we don't really know what this change does, we managed to recompile firmware 14.09 with the change rolled back. Now the surface quality with our recompiled 14.09 firmware is the same as with firmware 14.03.
In file Marlin/Configuration.h we changed line number 218 back to the previous state, defining PIDTEMPBED which enables PID on the bed according to the comment. I'm not sure what this means exactly, so any insight on this would be helpful.
The section of code which we changed:
Marlin/Configuration.h:208-220
// Bed Temperature Control
// Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis
//
// Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder.
// If your PID_dT above is the default, and correct for your hardware/configuration, that means 7.689Hz,
// which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating.
// This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater.
// If your configuration is significantly different than this and you don't understand the issues involved, you probably
// shouldn't use bed PID until someone else verifies your hardware works.
// If this is enabled, find your own PID constants below.
#define PIDTEMPBED //<<Uncommented line 218 again.
//
//#define BED_LIMIT_SWITCHING
Hey undeviljur
Are you aware that you and your brother made my day!?!
I'm fighting for quite some time with a very similar issue: http://umforum.ultimaker.com/index.php?/topic/6907-horizontal-banding-on-um2/
After having read your post above, I immediately switched the PID mode of the heated bed on again on my UM2. And this is the result:
On the left is a print done previously in bed bangbang mode. On the right is a print done today in bed PID mode (after running the PID autotune feature for the bed).
Obviously I mainly had the same issue. There are a few banding lines left but that's on a level I can live with it.
@undeviljur: Unfortunately I can only give one like to your post. You would deserve at least 10. Thanks a lot!
@Daid: Has the disabling of the PID mode for the bed be done accidentally or was there a physical reason for it?
I did a test today to print with different firmware versions using the gcode provided by undeviljur. I asked two persons to order the quality of the prints. I compiled 14.03 and the dev version with and without PIDTEMPBED defined and also used firmware 14.09 provided with Cura. These were just one off prints but the result was in accordance with previous results.
Pretty much both person said 14.03 print was the best one followed by dev with PIDTEMPBED defined.
I think some problem arise when not using PIDTEMPBED, but I can't believe it has something to do with the bed temp. If this is a real effect we're observing maybe it has something to do with scheduling. But that is just pure speculation at this point.
@Daid: Has the disabling of the PID mode for the bed be done accidentally or was there a physical reason for it?
It's intentional. Using PID on the bed causes a lot of EMF, which in turn causes issues with FCC and CE certification.
It should be easy to test if it's a scheduling issue. By adjusting this:
#define DEFAULT_bedKp 124.55
#define DEFAULT_bedKi 23.46
#define DEFAULT_bedKd 165.29
To:
#define DEFAULT_bedKp 10000.0
#define DEFAULT_bedKi 0.0
#define DEFAULT_bedKd 0.0
You should get effectively the same result as the PID disabled for the bed. But then with the PID code running as well. (Does need a reset of the machine settings)
It's intentional. Using PID on the bed causes a lot of EMF, which in turn causes issues with FCC and CE certification.
It should be easy to test if it's a scheduling issue. By adjusting this:
#define DEFAULT_bedKp 124.55
#define DEFAULT_bedKi 23.46
#define DEFAULT_bedKd 165.29
To:
#define DEFAULT_bedKp 10000.0
#define DEFAULT_bedKi 0.0
#define DEFAULT_bedKd 0.0
You should get effectively the same result as the PID disabled for the bed. But then with the PID code running as well. (Does need a reset of the machine settings)
OK, the test is running right now. I can tell it looks the same as with proper PID settings (means it shows no banding). However, the machine made an awful noise when travelling with 250mm/s (it sound really bad, like a mixture of screeching and motor skipping). So it seems there is indeed some scheduling issue.
The FCC/CE stuff means PID-heating of the bed will not make it into the default firmware again, right? One should certainly not run the UM2 like this on the nightstand... Apart from violating these rules, is there any risk for the hardware?
edit: I bit later in the print I have to say that there is a very slight banding compared to the proper-PID version but not as pronounced as with the bang-bang mode.
The FCC/CE stuff means PID-heating of the bed will not make it into the default firmware again, right? One should certainly not run the UM2 like this on the nightstand... Apart from violating these rules, is there any risk for the hardware?
No risk to the hardware, just more chance it causes other equipment to stop working.
I suppose it could be causing problems for the Z stepper but much more likely it's the head temperature swinging through various temperatures. The bed uses the most power so when it is on the voltage probably changes a bit and may affect the nozzle temperature somehow either by messing with the temp sensor (seems unlikely) or by changing the characteristics of the nozzle heater (now at lower voltage) that messes up the PID controller and causes some overshoot.
You could see it in Octoprint if you monitor a print and look at the temperature curves. I don't know if Pronterface show curves too but you should see some changes in both at relatively the same time if what you say is true.
just more chance it causes other equipment to stop working.
Like cell phones, wifi, quadcopters and other radio receivers. Don't fly too close to the UM2!
Like cell phones, wifi, quadcopters and other radio receivers. Don't fly too close to the UM2!
You have to see this as a 'natural' protection of the UM2 against drone attacks. It's not a bug, it's a feature... :lol:
Well, in reality, there won't be any real risk. But with the bed PID enabled we went over the maximum emission by a few db at a single frequency (a harmonic of the bed PWM frequency, not sure which it was). Any radio equipment will have enough filtering to withstand this with ease.
CE regulations are quite hard on the emission rules.
Isn't it possible to add a hidden switch or an option in the advanced settings? I care more for print quality then for the CE certification and I'd rather not build my own firmware because I don't want to merge my changes every time you release a new version.
Isn't it possible to add a hidden switch or an option in the advanced settings? I care more for print quality then for the CE certification and I'd rather not build my own firmware because I don't want to merge my changes every time you release a new version.
Nope, cannot do that. That would be in violation with those rules. What we (Ultimaker) supply has to comply with those rules, else we can get some hefty fines.
Ok, sucks but I understand it.
Well, I'll ignore it for now and if this particular problem should bother me too much, I'll resort to firmware customizing.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
17
12
10
7
Popular Days
Jul 21
10
Nov 5
6
Jul 22
6
Jul 24
6
Top Posters In This Topic
undeviljur 17 posts
Daid 12 posts
gr5 10 posts
Dim3nsioneer 7 posts
Popular Days
Jul 21 2014
10 posts
Nov 5 2014
6 posts
Jul 22 2014
6 posts
Jul 24 2014
6 posts
undeviljur 0
Thx for testing anyway.
Link to post
Share on other sites