Inconsistent Extrusion - ARM branch #699
Comments
|
Please let me know if you require additional information. Sorry for the long post. |
|
I just read the code for AVR.
Printer::maxExtruderSpeed = (uint8_t)floor(HAL::maxExtruderTimerFrequency() / (Extruder::current->maxFeedrate * Extruder::current->stepsPerMM));
If i really got this right: It seems that the minimum distance of time between interrupts for extrusion is always constrained to 15 on my Printer.
Some weeks earlier I read about the topic and I think that the extruder should drive Advance Steps at maximum speed. For me it is over maximum as it seems according to your thoughts. But why. Your post is quite interesting! |
|
Always remember you are usinga AVR 8 bit processor. 15 means max. frequency of 16.6KHz which get called always adding extra load to the cpu. We can already easily use 100% cpu load with the normal stepper interrupt, so it should be clear that we have a limit what is useful and that is what I have choosen as limit. For normal extruders with 100steps per mm that is quite fast, but of course nowadays with 1/128 microstepping you can bring the processor to it's limit and the question is if that is a goo dthing to have such a resolution or if it is more cosmetric to have that many steps per mm. At some point you will not see any difference. And even with your high precision it becomes only a problem during retraction where you want high speeds for advance. |
|
thinking... As I understand this, OCR0A = timer + 15 is a faster filament push cycle than OCR0A = timer + 35 So the point is that the function does not set this advance steps speed to "normal fastest steps". Its meaning is that it is set to something like at least 16.6khz . So that we dont constrain the advance algorithms steps to possible slower usermade rectraction-speeds? |
|
Yes I think you got it. Not knowing when the timer interrupt will increase the steps to do we check more frequently then normally needed and work the counter down and then wait for new steps to execute. That we we have only a small delay for normal extrusion and depending on advance value may start lagging if it goes faster but we try to catch up as fast as interrupt allows. |
|
Ok, because the topic is still suitable I post this here in hope to not annoy anyone with my little problem :) Again I am not working with latest repetier, as I am bound to the old version which was originally adopted by Conrad Electronic to drive their RF1000 and RF2000 printer. Originally I read this Issue to find some solution for my problem with blobs. Reason is that found out that those specific blobs I want to get rid of appear with retracts and not when hitting edges.
When I use S3D as Slicer there are several options.
Those blobs are there when 3 is activated with 1 and 2. I cannot tell if this is the whole pool of blobmaking settings, but if I remove the setting 3 the print goes well. 1+2+3 produces:
1+2 produces
Which falls down to:
I see a Move with X,Y and -E That Is kind of how far I debugged this problem. But .. cant it somehow be the case that this very uncommon kind of x-y-retract is bad because its huge amount of negative extrusion? Greetings |
|
I think you have found a bug here. Advance was not for retraction but for extrusion while accelerating/decelerating. Now you want the opposite direction in your wipe using the same code and it even contains fabs(speedE) so completely ignoring direction. So with enough speed it could even get an extrusion where yu wanted to retract. Have to check it in more detail, but that is what might happen here. |
|
Any news on this? |
|
I think you always want to have advanceL=0 during retraction, so it should be:
In addition, you could try forcing a break in the path planning (in updateTrapezoids()) by replacing with |
|
I had some thought son this but no solution yet. Problem is to have a cheap detection solution to find the cases where we do not want advance. Advance wanted: Not Wanted: Especially U3 is here hard to detect since it is very similar to W1. For U3 we could say if previous was a retraction don't advance but at that place we have no previous. U2 is easy by adding one term: So with this it comes down to the question how simplify undoes retraction. Is it a pure E-Move then it is ok, is it while moving we need to know if previous was a retraction. |
|
Hm. Does U3 happen in practice (and if it does, wouldn't advance make as much sense as no advance)? Anyway, in this particular case I would have guessed that adding |
|
Ok, I tested your suggestions: |
|
@qx1147 U3 would be important if it happens since it is done with higher speed then normal printing and then you have even more advance at the start. So that is a case you surely do not want and also why I catch the no move but extruder.
@Nibbels Not sure what that should change at your problem. You only fix junction speeds there, but that does not say anything about not using advance. |
|
I just followed @qx1147 #699 (comment) |
|
Regarding U3, I just couldn't think of a useful case where the slicer would produce U3 G-code. Anyway, as you say, U3 is hard to catch. Regarding the path planning, the idea was that a break might prevent some AdvanceL handling from choking over the on-the-fly extruder reversal. In a way, this reasoning might not be so much different from the reasoning that is behind the already implemented condition. But yeah, this break is not forcing the move (and advance) to come to a full stop before continuing with wipe and retraction. So, sorry for the useless suggestion. |
|
I thought much about this problem. But I cannot think it through because I have lacks in knowledge. We try to generate some ON-OFF condition. But that is not what we actually need when we ignore some possible effect of microoptimisation - I think. I guess that we have some incredible acceleration while retract. We have less acceleration while printing. Or we should just allow negative Advance because faster then fastest isnt possible. Either way - retract and push. |
|
Just tried to create an example that makes the problem. Not sure why, but simplify3d did not create your code. I used latest 4.0 with wipe and here is what I get: As you see it does plain retract, then wipes goes to next position, unretracts and prints. That way it prevents the problem completely. So I guess we can ignore U3 for now and only handle the additional case of retract while moving, which is catched by |
|
Here are some samples S3D did produce: There is Wipe Nozzle + Retract and those combined with this advanced settings checkbox. Pusing of filament to its pre-retract state has not been a special condition. Only retraction (-E) was combined. I'll try ´ |
|
|
|
At least your version did also unretract without move so both do not require U3. What Simplify3D version did you use? An older one that you still get retract during move or is there a setting that you want retract while wipe and not wipe after retract like S3D 4.0 seems to do? |
|
This old code was 3.1.1 as stated at the first line of .gcode in the rar But my tests with those two possibilitys where done with 4.0.0 stack_box.rar.txt |
|
You are right that setting makes it retract during wipe. Now I also get the wipe. Will see what the print will look like with this. But maybe my L is too small for it to see. Will test "fixed" version like I suggested. |
|
If you take L to around L= {40 .. 70} you should be able to see blobs. At around L ={100 .. 200} I got effects like stepper jumps and so on (At least with my stiffer PLA). |
|
Well :) I got it! Your fix was just right and really awsome! The pitfall on my side was that I had two code-locations for the same thing which renkforce implemented in 2014. They have a second coordinate system to do pause moves (and something like babystepping and so on) and the other to hold the parts paths. Now it works like a charm. Greetings! And... https://github.com/repetier/Repetier-Firmware/blob/development/src/ArduinoAVR/Repetier/Printer.cpp#L40 And sometimes you cast F_CPU to float like this: |
Hello All,
Thank you and John Silvia for the great piece of software. I am finally printing with a 32-bit CPU. While setting up, I noticed I was not able to calibrate extrusion - it was inconsistent. Here is what I found:
Issue: Extruded length calibration inconsistent (e.g. extruding 1x50mm is calibrated at 50mm, however 5x10mm do not yield 50mm but rather 38 or so).
Cause: In Extruder.cpp, line 748 and further, we have:
'#if USE_ADVANCE
Printer::maxExtruderSpeed = (ufast8_t)floor(HAL::maxExtruderTimerFrequency() / (Extruder::current->maxFeedrate * next->stepsPerMM));
#if CPU_ARCH == ARCH_ARM
if(Printer::maxExtruderSpeed > 40) Printer::maxExtruderSpeed = 40;
#else
if(Printer::maxExtruderSpeed > 15) Printer::maxExtruderSpeed = 15;
#endif'
Where:
'HAL::maxExtruderTimerFrequency()' is F_CPU/32 or 2.25MHz.
It is used in HAL.cpp line 1268 and onwards to set the next extruder interrupt as:
'extruderChannel->TC_RC = Printer::maxExtruderSpeed;'
maxExtruderSpeed is the ExtruderCounter count when the next Extruder interrupt occurs. This count should not fall below a min value (causing too frequent extruder motor steps) rather than not exceed a max limit (as currently coded).
In my case, maxExtruderTimerSpeed calculated at 214, which was then brought down to 40. This caused the extruder to be driven too fast, missing steps.
Thus, I propose considering the following change be made:
Option A:
'if(Printer::maxExtruderSpeed < 40) Printer::maxExtruderSpeed = 40;'
This yields a min safe value of ~18us, which corresponds to 56250 steps/second. It is questionable whether this is actually a safe value or not, depending of the microstepping mode for the driver. 1/64 or higher modes yield acceptable results, I doubt this frequency is acceptable for motors driven 1/8 or lower.
Option B: remove the safe value check altogether since its purpose is to mask configuration issues. Since maxExtruderSpeed is calculated it should always be a safe value.
Also, the following observations apply:
Thank you!
The text was updated successfully, but these errors were encountered: