Closed boelle closed 8 years ago
boelle
commented
8 years ago 
It would be helpful for me to see close up pictures of a JKN improved print versus a 'Normal' print. Does anybody have a way to get both pictures so it is easier for us to visualize and discuss the properties?
boelle
commented
8 years ago 
OK here is what I plan to do on next Saturday (hoping a have enough time):
I think I found out whats the problem with both existing advance implementations: They calculate a speed depending advance step amount. That's OK and I think especialy the k*dv (dv=delta velocity, extruder velocity to be precise) is the right way how to do it. But they spread it equaly through all acceleration/deceleration step loops. That would be true if this ISR is called in equal time steps, so dv is the same for each loop. But we step the steppers in equal distances depending on the step/mm value, not in equal time frames. This leads to a wrong advance step distribution. You can see a graph of the speed distribution over distance at the bottom of the page here: http://prusaprinters.org/calculator/ The best way to get around this would be to calculate the dv between each ISR call (dv= currentv - last v) and calulate the neccesary extra esteps "on the fly". I will try such an implementation in the next days, I think it should work much better..
boelle
commented
8 years ago 
Sebastian, as far as I know - at least in marlin - the advance has its own ISR (TIMER0_COMPA_vect).. the extruder stepper is not fired in the same ISR as other axis. Did you ckeck that??
Cheers.
Alex.
2016-04-14 12:42 GMT-03:00 Sebastianv650 notifications@github.com:
OK here is what I plan to do on next Saturday (hoping a have enough time): .) Create a pull request against RCbugfix for Marlin advance. .) Create a presentation about what I found out up to now, also with pictures so we can reference to something if we discuss a special detail. I think this is absolutely necessary to get a common understanding to start with.
I think I found out whats the problem with both existing advance implementations: They calculate a speed depending advance step amount. That's OK and I think especialy the k*dv (dv=delta velocity, extruder velocity to be precise) is the right way how to do it. But they spread it equaly through all acceleration/deceleration step loops. That would be true if this ISR is called in equal time steps, so dv is the same for each loop. But we step the steppers in equal distances depending on the step/mm value, not in equal time frames. This leads to a wrong advance step distribution. You can see a graph of the speed distribution over distance at the bottom of the page here: http://prusaprinters.org/calculator/ The best way to get around this would be to calculate the dv between each ISR call (dv= currentv - last v) and calulate the neccesary extra esteps "on the fly". I will try such an implementation in the next days, I think it should work much better..
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210008602
"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )
Alex Borro
boelle
commented
8 years ago 
Just for reference: MarlinFirmware/Marlin#3424
boelle
commented
8 years ago
@alexborro thats right, but the esteps addition is made in the usual ISR. They are only executed by a seperate ISR. I don't get the purpose of this to be honest, I think that's not absolutely necessary.
boelle
commented
8 years ago
It is strange.
I think we should understand how a good advance algorithm should work and compare Sailfish and Marlin solutions.. Implementing it will be pretty much straight forward.
@Sebastianv650, if you could spend some time making some doc about what you figured out, the math involved, I can help you debugging the code and implement the fixes/new algorithm.
We can create a branch off of Marlin to work together.
Cheers.
Alex.
2016-04-14 13:07 GMT-03:00 Sebastianv650 notifications@github.com:
@alexborro https://github.com/alexborro thats right, but the esteps addition is made in the usual ISR. They are only executed by a seperate ISR. I don't get the purpose of this to be honest, I think that's not absolutely necessary.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210022259
"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )
Alex Borro
boelle
commented
8 years ago
I did a quick-and dirty presentation about the basics I got up to now: https://drive.google.com/open?id=0B5UvosQgK3adaHVtdUI5OFR3VUU
I hope it is enough for a first step, I want to spend my time into coding now. I'm very excited if my aproach regarding new advance step distribution will work!
boelle
commented
8 years ago
Great info, great investigation, great work ! :double-thumbs-up:
It makes perfect sense that dV will vary between ISR(), this could be overcome by having Marlin doing some kind of global average instant velocity or why don't include a dt into the advance calculation like some PID have exactly to compensate for inconsistent sampling intervals ?
boelle
commented
8 years ago
I'm currently looking for some existing dt.. We have an acceleration_time and a deceleration_time used by the ISR. They are used to calculate when the next interrupt has to happen. But I don't get the unit they use, maybe someone can help? I printed the result after a block to serial. A move with speed = 100mm/s and accel. of 1200mm/s² should take (speed/accel) about 80ms. But Marlin prints 154567 for accel. and 160889 for decel. So the numbers could be in µs, but they are doubled compared to my calculated ones. This is repeatable for other speeds, if I calculate 40000µs to reach 50mm/s, Marlin reports 80000 and so on. Why?
Anyone has a better idea how to get e velocity? Looks like I have a little mental block..
Edit regarding acceleration_time: Dumb question, it proves my last ATmega project was some years ago.. Of course this is due to the timer / prescaler settings. 1ms = 2000 "cycles" for the settings used in Marlin. Perfect, so everything we need as input is already calculated!
boelle
commented
8 years ago
What if we put all the esteps related calc in a separated place?? I mean, maybe in its all ISR ?? We have the total total steps the extruder should move and the total time of that movement. And the other axis acceleration as well. I mean, something like this:
Does it make sense??
[image: Imagem inline 1]
2016-04-16 10:18 GMT-03:00 Sebastianv650 notifications@github.com:
I'm currently looking for some existing dt.. We have a acceleration_time and a deceleration_time used by the ISR. They are used to calculate when the next interrupt has to happen. But I don't get the unit they use, maybe someone can help? I printed the result after a block to serial. A move with speed = 100mm/s and accel. of 1200mm/s² should take (speed/accel) about 80ms. But Marlin prints 154567 for accel. and 160889 for decel. So the numbers could be in µs, but they are doubled compared to my calculated ones. This is repeatable for other speeds, if I calculate 40000µs to reach 50mm/s, Marlin reports 80000 and so on. Why?
Anyone has a better idea how to get e velocity? Looks like I have a little mental block..
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-210813734
"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )
Alex Borro
boelle
commented
8 years ago
Maybe I'm not understanding what you are meaning, but the calculation for advance is only 3 or 5 extra lines. I would go the other way round:remove that unnecessary extra advance isr and do the esteps inside the main ISR as it's done without advance.
boelle
commented
8 years ago
Do you believe we can create this as a self contained object ?
boelle
commented
8 years ago
Somebody want's to see some awsome pictures? I got it working, and it's way better than the implementations before! I would say it's hard on the border to perfection - sorry, but I feel like a child on christmas :-)
I printed two identical test cubes: 20x20x2mm, 0,2mm layer height, 80mm/s print speed, 500mm/s² accel. to see the distribution. On the left you can see the one without advance (k=0), on the right there is the cube with advance (k=250, I'm using integer calculations for speed). I think the pictures and the dimensional tolerance increase don't need more words - the k=0 part has the rough top infill due to the high speed, the other one is smooth as skin!
Here you go: Pictures
Now the code needs some testing and streamlining, then I call it ready to share!
boelle
commented
8 years ago 
Dude, @Sebastianv650 , that looks outstanding!!!!
I am super excited about this!
boelle
commented
8 years ago boelle
commented
8 years ago 
Great work done there! That is cool.
In regards to the results cube when using K=0, why the warped corners? A normal print without using this feature won't create that, is that the result of having the feature enabled? (and working, because before it wasn't actually doing anything... :) )
-Nando Sent from my Sinclair ZX81
On 18 April 2016 at 17:32, João Brázio notifications@github.com wrote:
Congrats, that looks awesome !
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-211459963
boelle
commented
8 years ago
why the warped corners
Due to the [high] printing speed.
boelle
commented
8 years ago
@Nandox7 , @jbrazio is right it depends on the print speed. That's why you should print the perimeters slow without advance. The faster you go, the more the edges will bleed out. If you print at or around jerk speed, the edges will be perfect. But than a big print will take ages.. Same is true for the top infill. If you print it slowly, it will look nice even without advance. But if you go fast, it will get rough at the direction change points. Fast is meant as mm³/s to be precise, if you are happy with your print quality at 30mm/s and 0,2mm layer height you can do also 60mm/s at 0,1mm layer height without quality changes. At least if your axes can to that, of course..
boelle
commented
8 years ago
Nice work Sebastian!
If you don't mind sharing the code, I would like to merge it into my branch and perform more tasks.. I think the more data we gather, the better.
Cheers...
Alex. Em 18/04/2016 14:34, "Sebastianv650" notifications@github.com escreveu:
@Nandox7 https://github.com/Nandox7 , jbrazia is right it depends on the print speed. That's why you should print the perimeters slow without advance. The faster you go, the more the edges will bleed out. If you print at or around jerk speed, the edges will be perfect. But than a big print will take ages.. Same is true for the top infill. If you print it slowly, it will look nice even without advance. But if you go fast, it will get rough at the direction chance points. Fast is meant as mm³/s to be precise, if you are happy with your print quality at 30mm/s and 0,2mm layer height you can do also 60mm/s at 0,1mm layer height without quality changes. At least if your axes can to that, of course..
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-211489911
boelle
commented
8 years ago
I created a fork of Marlin RCBugfix and added my changes: https://github.com/Sebastianv650/MarlinRC_LIN_ADVANCE
Any comments are welcome, consider it as a working draft. The goal is to improve the code until everyone is happy and we can transfer it into Marlin. Working with Github (forks, pull requests etc) is new for me, so also feel free to tell me if I'm doing something wrong with it!
What should be tested: .) Is one k value true for different print settings (layer height, speed ranges, ..)? K should differ between filament types (PLA, ABS, PETG, ..) or extruder types. .) There might be a problem with very tiny perimeter steps. Take this model as a reference. Without advance, it prints with much of stutter on my TAZ 5 over USB with high print speeds, with advance there is too much material on the feets of the gecko. I'm not sure if this is because Marlin can't catch up calculating all the necessary steps in general or if it has something to do with the advance feature.
One important thing is still open in the code: If you have a look into stepper.cpp, line 770 to 784, you can see I got crazy about macros staggered on each other. I had a mental block how to write this in a nice way so I took the original advance way of doing it and clipped it to only fire the first extruder. So this will not work if you have more than one..
Edit: And the M905 code was only choosen because it was free, if someone has a better idea where it would fit - tell us!
boelle
commented
8 years ago
So you have completely removed this method ?
// extruder advance constant (s2/mm3)
//
// advance (steps) = STEPS_PER_CUBIC_MM_E * EXTRUDER_ADVANCE_K * cubic mm per second ^ 2
//
// Hooke's law says: force = k * distance
// Bernoulli's principle says: v ^ 2 / 2 + g . h + pressure / density = constant
// so: v ^ 2 is proportional to number of steps we advance the extruder
//#define ADVANCE
#if ENABLED(ADVANCE)
#define EXTRUDER_ADVANCE_K .0
#define D_FILAMENT 2.85
#endif
The original advance is still there, my implementation is quite different so I wasn't able to reuse code. So I created a new LIN_ADVANCE because I wasn't sure if somebody wants to keep the original thing.
boelle
commented
8 years ago
If we improve then this one shall replace the other, re using as much as possible (not the code) but the configuration flags.
If you don't mind cleaning the code from the previous unused implementation that would also be appreciated.
boelle
commented
8 years ago
.) There might be a problem with very tiny perimeter steps.
Got it. Marlin will collapse very short moves to the next longer move. If a short move is executed together with a retract or unretract move, this leads to an unwanted hughe advance step mounts. The math is correct, but advance together with retract moves is unwanted. I have to find a way to filter is one out. A workaround is to compare bse and allsteps, if they are nearly equal it is a retract or unretract move.
boelle
commented
8 years ago
@jbrazio, no problem, I could do that. But there is one thing to consider: Due to the new advance esteps distribution, the extruder has to do a lot of steps at the beginning and ending of a line. This seems to be no problem for a direct drive, but what's about bowden systems? I guess they need a much bigger k value, maybe their extruder can't handle that. Than it would be better to have a (working) classic advance than nothing. Maybe someone with a bowden system can test this?
boelle
commented
8 years ago
@Sebastianv650 I have a bowden system to test. And believe me, it is possible to have faster bowden extruder, with correct gear ratio. Mine is capable of 85mm/s.
By why does it need a lot of steps in the end of a line?? I understand in the beginning - the advanced steps - but it should be subtracted from the esteps in the end of a line, shouldn't it?
boelle
commented
8 years ago
I know a bowden can be as fast as a direct drive, but I'm afraid it has to be much faster then a direct for this. Think of the filament between the nozzle and your extruder as a spring. If you have to bring this spring to a specific force by compressing it, that might be no problem if your spring is short. If your spring is 10x longer, which means it's much "softer", you have to do a lot more travel mm to reach the force needed in the same time..
You are right, the beginning is the chalanging part. If it can handle the "jumpstart", the break down will be no problem.
boelle
commented
8 years ago
It seems to me that the machine's acceleration settings will have a dramatic impact on the advance extruder velocity demands. The default 4000 mm/s/s is pretty aggressive. Having proper advance really eliminates the need for such aggressive acceleration. I already run mine closer to 2000, with no advance. Though I print at slower speeds usually.
On Tue, Apr 19, 2016, 2:03 PM Sebastianv650 notifications@github.com wrote:
I know a bowden can be as fast as a direct drive, but I'm afraid it has to be much faster then a direct for this. Think of the filament between the nozzle and your extruder as a spring. If you have to bring this spring to a specific force by compressing it, that might be no problem if your spring is short. If your spring is 10x longer, which means it's much "softer", you have to do a lot more travel mm to reach the force needed in the same time..
You are right, the beginning is the chalanging part. If it can handle the "jumpstart", the break down will be no problem.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-212070773
boelle
commented
8 years ago
I noticed that I get too much material extruded with advance enabled, which is most noticeable on small details with 100% infill like the top of a cone. To track this down, I created a counter for the sum of all esteps due to advance and another one that counts the time spent accelerating and decelerating.
In theory, they should be both 0 after each print - you can't come to a stop if you are always longer accelerating than decelerating. In reality, both values gets bigger over time which means Marlin is always longer in accel. than decel.
Anyone has an idea what's wrong in my thinking? You can try it very simple with a static long counter_timer variable in stepper.cpp. Add all "timer" for accel., subtract all "timer" during decel.
boelle
commented
8 years ago
The number of acceleration is not equal to deceleration due to jerk and look-ahead. You can have a sequence of movements with 10 accel and just 1 decel.
About the amount of extruded material, are you sure you are not changing the total amount of steps?? If one movement is suppose to have 1000 esteps, no matter when you fire the steps, it should have done 1000 esteps in the end of XYZ movement. Maybe you are adding (advancing) steps in the beginning of the movement and not subtracting them in the end??
Cheers.
Alex.
2016-04-20 13:35 GMT-03:00 Sebastianv650 notifications@github.com:
I noticed that I get too much material extruded, which is most noticeable on small details with 100% infill like the top of a cone. To track this down, I created a counter for the sum of all esteps due to advance and another one that counts the time spent accelerating and decelerating.
In theory, they should be both 0 after each print - you can't come to a stop if you are always longer accelerating than decelerating. In reality, both values gets bigger over time which means Marlin is always longer in accel. than decel.
Anyone has an idea what's wrong in my thinking? You can try it very simple with an static long counter_timer variable in stepper.cpp. Add all times for accel., subtract all times spent on decel.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/MarlinDev/issues/402#issuecomment-212504327
"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )
Alex Borro
CCS86
commented
8 years ago @Sebastianv650
How difficult would it be to merge your code into the 1.0.x branch of Marlin?
Part of me wants to try the new 1.1.x RC, but I'm a little worried about all the safety stuff being 100% online, and I'm not sure if anyone has set it up for an Ultimaker yet.
jbrazio
commented
8 years ago Duplicate of #3676
SimonSolar2C
commented
6 years ago Id like to add an observation to this discussion, regarding my observation running tests of the LINEAR_ADVANCE functionality.
I started this investigation when I observed inconsistent extrusion thickness whilst printing thin walled wing sections, and then in diagnosing, I syudied the thicker blobbing corners on a basic test square. My conclusion is that the speed. I also wanted to print as fast as possible. According to E3D, the ability to push through the filament consistently at the specified temperature is limited to 60mm/s at 0.20mm height, 0.40mm nozzle.
I wanted to actually see when this dropoff occurs - when does extrusion stop being consistent as we increase the speed.
The results were astounding !
The Test
10 test cubes printed at speeds of 10,20,30,40,50,60,70,80,90,120mm/s
Esun PLA tests with K=70, wall thickness extrusion setting
Measure the single wall thickness averaged around the cube.
Results
What I saw did not match the theory - the wall thjckness at slow speeds is far greater than higher speeds and it is not linear. The wall thickness should not change until it hits that point where extrusion cannot keep up.
Conclusion
The ADVANCE algorithm may help with blobiness at the ends/starts of extrusion, but thickness is not consistent at various speeds and likely across the acceleration. So for small intricate models, XY motion will move slower and likely be over-extruded compared to large models where full speed is reached (60mm/s in my case)
My Action Item
Write into this thread and hope a developer cleverer than me will implement a 'fudge factor' into the part of marlin that relates extrusion velocity to XY velocity so we can use it to adjust the angle of the curve in the graph below to become more horizontal.
.
Sebastianv650
commented
6 years ago I think I don't get your chart to 100%. What do you mean with 1 turn / 2 turns and what are the differences between the 4 plots in generall. The short description below is a bit confusing to me, do you tested different heat blocks or extruders?
Beside this, I think you might have a problem not related to the intention that an advance function has. Advance only adjusts for the effects during acceleration / deceleration, where the main portion is comming from the springiness of the filament but there are a lot of other smaller factors that are not covered from any implementation at the moment. So advance tries to cover a dynamic behaviour.
When you measure the wall thickness of a "suitable long" straight wall at different speeds, where suitable long means it's much longer than the acceleration distance, you should see a stabilised flow with and without advance active. Therefore, also the wall thickness should be equal through all test cube speeds. If it's not, you have a slipping extruder to filament drive. Think about it: If the filament wouldn't be slipping in the extruder gear and you see less extrusion than your extruder speed should result in - where is the delta filament volume gone? It can't disapear. Some slipping at high print speeds is quite common, depending on the drive system used. The best solution if you have problems with it is to upgrade to a better drive system. A software solution could be to use variable estep/mm settings depending on extrusion speed. But this would be maybe even more complicated to calibrate than advance K factor and I'm not a fan of SW solutions if there are hardware ones. Especialy because our AtMega boards are already quite on their processing power limit.
SimonSolar2C
commented
6 years ago Hi @Sebastianv650 - only just saw your comment now - Yes I 100% agree that the delta filament cannot disappear - hence my test to try and find cause. Also looking to see if linear advance can fix the problem seen in the graphs. As stated the graphs should be a straight line, until the speed increases such that the heatblock can no longer keep up, and then what will happen? If it cant shove the filament through, then either it compresses ( and oozes out during the next move ), or the extruder slips. You can see I got better results with the screws on the filament tighter - so that answers the second part of this. But what this test should be showing for good linear behaviour, is a straight line up to the theoretical top speed , which is said to be about 60mm/s @0.48mm /0.20layer . For some reason the original TEVO hotend performed better than the E3DV6, but I never went back to double check the original hotend again. And so I wanted to see just where the performance dropped off, but because it is not a straight line, I have to wonder where is the cause. What it means in reality is that more extrusion comes out at slower speeds, eg corners of test squares, which is often what we see. Is it the same on all machines - is it a physical science problem of liquid flow - what is the cause, and does marlin need a fudge factor of extrusion*speed, or maybe I just need a new extruder. I'm suspicious that tightening the screws improved the linearity, therefore 'm thinking of buying the TitanAero, then I will run a comparison test.
Sebastianv650
commented
6 years ago Maybe #9852 will give you some informations.
github-actions[bot]
commented
3 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
github-actions[bot]
commented
3 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
github-actions[bot]
commented
2 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
We seem to have some interest now in retooling the "Advance" function in Marlin, and had a good discussion in another issue, here: https://github.com/MarlinFirmware/MarlinDev/issues/77
Here were the key points: