nzinov commented 7 years ago

I am running d3cb1a86 on delta. When I try to print with LIN_ADVANCE uncommented, printer moves to the start point, then extruder produces some noise for ~1sec and then printing completely stops. Hotend led is blinking at changing rate as usual - so firmware is not crashed at that moment. However, it only outputs busy: processing into console and is not responding to any commands. Any tips on debugging that?

psavva commented 7 years ago

It was with the debug code...

Sebastianv650 commented 7 years ago

It was with the debug code...

I guess it's due to the same error. We checked for 0 with the debug code, but if it becomes another tiny number it can also block the system that much that the heater system doesn't have enough calculation time to do it's job.

Thanks for your help so far, we should find a solution.

psavva commented 7 years ago

@Sebastianv650 I think I need to make a small change to the debug code in a specific case:

After the specific line: eISR_Rate = ADV_RATE(OCR1A_nominal, step_loops_nominal);

Timer is not recognised in the scope in the debug clause I'll change that to:

if ENABLED(LIN_ADVANCE)

  if (current_block->use_advance_lead)
    current_estep_rate[TOOL_E_INDEX] = final_estep_rate;

  eISR_Rate = ADV_RATE(OCR1A_nominal, step_loops_nominal);
 //Start Debugging Code
    if (!eISR_Rate) {
      SERIAL_ECHO_START;
      SERIAL_ECHOPAIR("OCR1A_nominal:", OCR1A_nominal);
      SERIAL_ECHOPAIR("step_loops:", step_loops);
      SERIAL_ECHOPAIR("esteps:", e_steps[TOOL_E_INDEX]);
      SERIAL_ECHOPAIR("tool_index:", TOOL_E_INDEX);
      eISR_Rate= 65535; //Disable the extruder ISR to prevent a frozen system.
    }
    //End Debugging Code
#endif

SPLIT(OCR1A_nominal);  // split step into multiple ISRs if larger than  ENDSTOP_NOMINAL_OCR_VAL
_NEXT_ISR(ocr_val);

Since the timer for ADV_RATE is OCR1A_nominal in this case...

Ok?

Sebastianv650 commented 7 years ago

Yes, that's right!

psavva commented 7 years ago

@Sebastianv650

Here's the results:

I have deleted the "echo:busy: processing" in the log file... Find the paste here :) http://pastebin.com/906NKWUS

Sebastianv650 commented 7 years ago

Alright, we should not wonder when Marlin crashes when it tries to execute over 4 million steps per second. That's what your log file says ;-) The maximum Marlin can do on an ATMega is 40.000 steps per second.

That high extruder step amount should be a result of the high K factor. I would double check if it's realy needed, but nevertheless we need a solution to handle such cases without crashes. Let's think about what options we have:

Write a check function that tries to find out if a K value is save after setting it. If it's not, throw a message and prevent printing. If you don't have a serial connection, the printer will do nothing and you don't have an idea why. And I think there is no perfect way of determining if K is valid or not. Bad.
Determine a safe maximum extruder step rate (OCR1A value calculated from maximum extruder speed setting). If the calculated eISR step rate is lower, set it to the min. allowed OCR1A value. This will delay the extruder advance steps a little bit, but no one should get lost and the printer keeps alive. Beside that, a boolean variable could be set if this safety feature was used, printing a warning message compareable to the Busy printing.. message from time to time so the user knows (if connected..) that the advance steps are not longer executed 100% where they should go in time.

I will try to reproduce this again using a high K value combined with high speed to be sure it's no other calculation in the LIN_ADVANCE process that produces wrong numbers before starting with a patch for this.

psavva commented 7 years ago

Let me know if there is anything else you need from me, happy to oblige :)

Seriously awesome work... Now when 32-Bit Marlin is up, maybe we can get 4 million steps per second :)

Sebastianv650 commented 7 years ago

I applied your steps/mm settings and also jerk and acceleration values. No freezing, no 0 values (tested up to 180mm/s). I have no clue why I can't get your result in my printer.. I'm afraid that the high esteps values are maybe the result of an overflow or something and that limiting the eISR rate will cure only the result but not the root cause.

I think I have to use your printer again. I will create a branch of Marlin and modify the code to track all values used for LIN_ADVANCE. When it reaches the point where we have that magic 0, it will dump all the data to serial and block all further movements until the printer is power cycled to prevent a flooded serial display. That will need some time for coding, but with this final test I should be able to follow the complete calculation. Therefore if something overflows I will see it, and if not it should be clear why your code ends up with no time between ISRs while mine never goes below 21 clock cycles.

Now when 32-Bit Marlin is up, maybe we can get 4 million steps per second :)

If you find a stepper that can handle that speed :D With your estep/mm setting of 385, that means over 10m per second.

Sebastianv650 commented 7 years ago

I need your patience again. Here is the code with the debug information: https://github.com/Sebastianv650/Marlin/tree/Debug_esteps

Download it, copy and paste your configuration.h and configuration_adv.h files into it and give it a try. The code compiles on my machine, but everything else is untested, so fingers crossed that it throughs out a lot of numbers. And fingers crossed that we don't need another 10 loops to solve this! :)

psavva commented 7 years ago

@Sebastianv650 , Need a little help to compile.

I guess int* is a pointer? I'm not a C++ Programmer, and thus don't know how to fix it ...

Arduino: 1.6.8 (Windows 8.1), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

sketch\stepper.cpp: In static member function 'static void Stepper::isr()': stepper.cpp:619: error: invalid conversion from 'int' to 'int' [-fpermissive] debug_current_estep_rate = current_estep_rate; ^ stepper.cpp:620: error: invalid conversion from 'int' to 'int' [-fpermissive] debug_current_adv_steps = current_adv_steps; ^ exit status 1 invalid conversion from 'int*' to 'int' [-fpermissive] This report would have more information with "Show verbose output during compilation" option enabled in File -> Preferences.

psavva commented 7 years ago

I guess it should be debug_current_adv_steps = current_estep_rate[TOOL_E_INDEX]; debug_current_adv_steps = current_adv_steps[TOOL_E_INDEX];

Can you confirm before I run the next test?

Sebastianv650 commented 7 years ago

Yes, that was wrong. I updated it in the repository: https://github.com/Sebastianv650/Marlin/tree/Debug_esteps

psavva commented 7 years ago

And here you go.

Crashed during crusing... http://pastebin.com/rNEMAWF3

psavva commented 7 years ago

I'm busy running a second test, where i'm printing this model: http://www.thingiverse.com/thing:1624412/#files

Lots of small moves. I'm checking the serial monitor, and had a "cold extrusion prevented", and i'm 9 mins into the print. I'll upload the log file once it's finished or frozen ;)

psavva commented 7 years ago

And Bingo.. Crashed...

http://pastebin.com/ccB2MkEU

Hope this is enough to find the issue :) This time is crashed during decel...

Sebastianv650 commented 7 years ago

Thanks again! You are using 1.75mm filament with a layer height around 0.2-0.25mm in this prints? Just trying to see if the calculations regarding the extruder speed <=> movement speed connection can be right.

Both crash cases are not logical to happen on a error free printer:

During crusing, even on the first step, there should be no speed change to the last step. Therefore no advance steps can happen. Comming from 75 advance steps executed, your printer tries to add another 549 where I would expect 0.
During deceleration, the extruder speed can only slow down. Therefore the amount of executed advance steps has to be reduced. But your printer, comming from 294 executed advance steps, wants to increase the nozzle pressure even more in this case by adding another 234 steps instead of subtracting some steps.

The calculation itself is OK, nothing seems to overflow. There is basicaly only one thing left which would also explain why I can't reproduce your issue: While I used all you settings like steps/mm, acceleration and so on, I was not using bed leveling as you do. I was never using it, therefore I also don't know how to set it up for a quick test. Therefore I also don't know exactly what it does to the moves inside the planner.

Guess what comes next? I'm sorry to keep asking such things, but would it be possible for you to disable the bed leveling thing in Configuration.h completely and re run the known for crashing code again, maybe including a z-offset to be shure your nozzle isn't damaging the bed? If it's not crashing now, we have a winner. Then I have to dig into the bits and bytes of bilinear leveling, set it up for my printer and I should also have a crashing system. That's my goal, I don't see another way to debug this only based on remote tests - and it's also the right way not to eat other peoples time..

psavva commented 7 years ago

@Sebastianv650 , it is always my pressure to work with this community :) I will certainly test and report back to you soon...

psavva commented 7 years ago

Hi @Sebastianv650, It failed with LIN_ADVANCE enabled, and all Bed Levelling Features disabled.

http://pastebin.com/HN1CHiPk

I'm about to test with LIN_ADVANCE Disabled, and Bed Levelling Disabled, and report back shortly

psavva commented 7 years ago

Hi @Sebastianv650, With LIN_ADVANCE disabled, and FR to 900%, then also cranked up Velocity + Acceleration via LCD Menu during the print to try push to the MAX, and there is No Failure after 10 Minutes of Printing...

start
echo: External Reset
Marlin 1.1.0-RCBugFix

echo: Last Updated: 2016-12-06 12:00 | Author: (none, default config)
Compiled: Feb 23 2017
echo: Free Memory: 3238  PlannerBufferBytes: 1232
echo:V29 stored set  M203 etrieved (393 bytes)
echo:Steps per unit:
echo:  M92 X160.00 Y160.00 Z800.00 E385.00
e00 Z500 E3000
echo:Accelerati
echo:  M203 X250.00 Y250.00 Z20.00avel
echo:  M204 Pum Acceleration (mm/s2):
echo:  M201 X2000 Y2000 Z500 E3000
echo:Accelerations: P=printing, R=retract and T=travel
echo:  M204 P2000.00 R3000.00 T750.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
echo:  M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.40 E10.00
echo:Home offset (mm)
e0 H180 B70 F0
  M145 S1 H240 Bcho:Hotend offsets (mm)
echo:  M21301 P51.83 I5.020
echo:Material heatup parameters:
echo:  M145 S0 H180 B70 F0
  M145 S1 H240 B110 F0
echo:PID settings:
echo:  M301 P51.83 I5.02 D133.75
echo:Filament settings: Disabled
echo:  M200 D3.00
echo:  M200 T1 D3.00
echo:  M200 D0
echo:Z-Probe Offset (mm):
echo:  M851 Z2.00
echo:SD card ok
echo:SD card ok
echo:enqueueing "M23 wb_dra~1.gco"
echo:enqueueing "M24"
echo:Now fresh file: wb_dra~1.gco
File opened: wb_dra~1.gco Size: 4023557
File selected
 T:189.5 /190.0 T0:189.5 /190.0 T1:0.0 /0.0 @:72 @0:72 @1:0 W:8
 T:189.6 /190.0 T0:189.6 /190.0 T1:0.0 /0.0 @:76 @0:76 @1:0 W:7
 T:190.0 /190.0 T0:190.0 /190.0 T1:0.0 /0.0 @:67 @0:67 @1:0 W:6
 T:190.0 /190.0 T0:190.0 /190.0 T1:0.0 /0.0 @:72 @0:72 @1:0 W:5
 T:190.4 /190.0 T0:190.4 /190.0 T1:0.0 /0.0 @:59 @0:59 @1:0 W:4
 T:190.5 /190.0 T0:190.5 /190.0 T1:0.0 /0.0 @:59 @0:59 @1:0 W:3
 T:190.5 /190.0 T0:190.5 /190.0 T1:0.0 /0.0 @:61 @0:61 @1:0 W:2
 T:190.5 /190.0 T0:190.5 /190.0 T1:0.0 /0.0 @:62 @0:62 @1:0 W:1
 T:190.5 /190.0 T0:190.5 /190.0 T1:0.0 /0.0 @:63 @0:63 @1:0 W:0
echo:Active Extruder: 0
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:Active Extruder: 0
X:160.00 Y:105.00 Z:10.00 E:0.00 Count X:25600 Y:16800 Z:8000
X:160.00 Y:105.00 Z:15.00 E:0.00 Count X:25600 Y:16800 Z:8005
X:160.00 Y:105.00 Z:15.00 E:0.00 Count X:25600 Y:16800 Z:8041
echo:Settings Stored (393 bytes)
echo:Settings Stored (393 bytes)
echo:enqueueing "M84 X Y Z E"

psavva commented 7 years ago

After 10 Mins of Printing with Bilinear Bed Levelling Enabled, and No LIN_ADVANCE, No crashes. It's certainly caused by LIN_ADVANCE, Please let me know if there is anything I can do further to help?

Remote Desktop :) ?

Sebastianv650 commented 7 years ago

Remote Desktop :) ?

We need a remote printer connection in Marlin for debugging - great idea ;)

Next thing I would do is to have a look at the gcode you use to reproduce the crash. If you know the area where it crashes it would be even better, but if not I will do the analysis on the complete file. So please upload it :)

If I can't find anything in it, I will set as much as possible in my config to your settings and run exactly that gcode at a high FR. Then it simply has to crash..! Hopefuly..

I still have no real idea where to start for specific tests. We know now what numbers the error produces and that this will freeze the system. But where is this ugly small bug sitting that causes it? A Marlin simulator would be nice, where we could run a specific configuration with gcode and watching some variables step by step..

psavva commented 7 years ago

@Sebastianv650 , You can find the gCode here: https://drive.google.com/open?id=0B6kS8tqbO6jVR2s3ajRRT3FBVGc

I have no idea on what line it fails, as it's really random it seems...

I will now test LIN_AVANCE, with a single extruder. Maybe Dual Extrusion Setup was causing it. I'll report back later.

psavva commented 7 years ago

Hi @Sebastianv650 , I can now confirm that with Dual Extrusion Disabled, it will still fail with LIN_ADVANCE enabled. It's something else...

start
echo: External Reset
Marlin 1.1.0-RCBugFix

echo: Last Updated: 2016-12-06 12:00 | Author: (none, default config)
Compiled: Feb 24 2017
echo: Free Memory: 2848  PlannerBufferBytes: 1568
Error:EEPROM checksum mismatch
echo:Hardcoded Default Settings Loaded
echo:Steps per unit:
echo:  M92 X160.00 Y160.00 Z800.00 E385.00
echo:Maximum feedrates (mm/s):
echo:  M203 X150.00 Y150.00 Z6.00 E25.00
echo:Maximum00 R5000.00 n (mm/s2):
echo:  M201 X750 Y750 Z100 E5000
echo:Accelerations: P=printing, R=retract and T=travel
echo:  M204 P750.00 R5000.00 T750.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
echo:  M205 S0.00 T0.00 B20000 X8.00 Y8.00 Z0.40 E5.00
echo:Home offset (mm)
echo:  M206 X0.00 Y0.00 Z0.00
Auto Bed Leveling:
echo:  M420 S0
echo:Material heatup partings: Disabled
ech5 S0 H190 B50 F0
  M145 S1 H240 B110 F0
echo:fset (ttings:
echo:  M301 P51.83 I5.02 D133.75
echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
echo:Z-Probe Offset (mm):
echo:  M851 Z-0.60
echo:SD card ok
echo:SD card ok
echo:enqueueing "M23 wb_dra~1.gco"
echo:enqueueing "M24"
echo:Now fresh file: wb_dra~1.gco
File opened: wb_dra~1.gco Size: 4023557
File selected

 T:190.5 /190.0 @:59 W:3
 T:190.5 /190.0 @:61 W:2
 T:190.5 /190.0 @:63 W:1
 T:190.5 /190.0 @:63 W:0
echo:busy: processing
X:160.00 Y:105.00 Z:10.60 E:0.00 Count X:25600 Y:16800 Z:8480
G29 Auto Bed Leveling
echo:busy: processing
echo:busy: processing
Bilinear Leveling Grid:
      0     1     2
 0 +0.40 +0.52 +0.51
 1 +0.27 -0.24 -0.80
 2 +0.70 -0.48 -1.60

X:340.00 Y:290.00 Z:11.81 E:0.00 Count X:54400 Y:46400 Z:8480
X:340.00 Y:290.00 Z:15.00 E:0.00 Count X:54400 Y:46400 Z:8482
X:340.00 Y:290.00 Z:15.00 E:0.00 Count X:54400 Y:46400 Z:8490
echo:Failed during accel.
Step: 1 from 715
Timer: 328
step_loops: 1
esteps: 339
acc_step_rate:6076
abs_adv_steps_multiplier8:9908
K:300.00
de_float:0.24
mm_D_float:6.32
nom_speed:55.50
nom_rate:6280
axis_steps_per_mm:385.00
delta_adv_steps:339
current_estep_rate:459
current_adv_steps:120

thinkyhead commented 7 years ago

@Sebastianv650 Do these numbers seem reasonable to you?

echo:Failed during accel.
Step: 1 from 715
Timer: 328
step_loops: 1
esteps: 339
acc_step_rate: 6076
abs_adv_steps_multiplier8: 9908
K: 300.00
de_float: 0.24
mm_D_float: 6.32
nom_speed: 55.50
nom_rate: 6280
axis_steps_per_mm: 385.00
delta_adv_steps: 339
current_estep_rate: 459
current_adv_steps: 120

thinkyhead commented 7 years ago

@Sebastianv650 I wonder if it would be possible to make the updated interrupts-interrupting-interrupts scheme into a conditional behavior, and then test with that behavior disabled. The optimization makes sure bytes aren't lost from the serial UART, but perhaps it contributes to the instability.

Another thing testers can try is to drop the BAUD rate and see if printing is more or less reliable. Perhaps too much time is being tied up in the serial communication and this is exacerbating the behavior — along with LIN_ADVANCE incurring extra stepper interrupts.

Sebastianv650 commented 7 years ago

There are in fact things in you gcode that looks strange. What's the extrusion width you are using for your print? Should it be fixed or are you using different widths for infill, perimeters and so on? As far as I know Cura is still not supporting variable gap fill, therefore even if you would use different extriusion widths for external / internal perimeters and so on I would expect to see distinct values and not a wild range of floating numbers.

While LIN_ADVANCE is designed to handle different extrusion widths, they have to be reasonable. If for example due to an slicer error the extrusion width for a single segment is complete different from the last and next one, this will result in extreme values which would fit to the numbers we see here.

That's what your gcode is looking like, displaying the extrusion width along each segment width a fixed filament diameter of 1.75mm and a layer height of 0.24mm, both taken from your file: extrusion widths

We can clearly see a favourite extrusion width slightly below 0.4mm. It might be slightly different from the value you set in Cura because a slicer is not calculating with simple rectangle extrusion paths, but I do for this one to keep it simple. But around that main value, we see spikes of any number between slightly above 0 and around 0.55mm.

So I see the following options to continue:

Reslice the model with another slicer with your printer settings and try again. But to exclude other error posibilities, also think about the step rate when increasing the FR: Marlin has a limit of 40.000 steps/s, due to the limit to quad stepping I would avoid to go above 20.000 steps/s for printing moves. So for a first step, you might set the print speed to <125mm/s (=20.000/160). I would also do this analysis again to the new gcode file to see what it looks then.
If you prefer to stick to your Cura version, we could set the ratio used for LIN_ADVANCE to a fixed value according to your real extrusion width and height for test purposis. But I'm not shure if this will work without other errors when the gcode is realy faulty.

We can also test @thinkyhead proposal, disabling the nested interrupts. Most likely you will see other errors then like serial communication errors but as long as you keep your baud rate low it should be OK at least for testing.

From my side, I would prefer to test another slicer first, combined with a second look to the gcode.

psavva commented 7 years ago

I printed only of an SD Card... So, didn't even try printing via USB... I'm not using anything special on Cura, and don't see how I could have specified different extrusion widths...

Sebastianv650 commented 7 years ago

It depends on the version of Cura you are using. I'm not using it anymore, but the version I still have installed 18.03 (Lulzbot Version) doesn't have a control option. Therefore the values are all the same as expected: cura 18_03

Here a chart from the current master branch from Prusa Slic3r. Note that the 0.55mm peak is a result of Slic3rs way of doing bringing over sparse infill before the top solid layers, so its alright: slic3r

But as far as I know there is a new Cura version where the options are located on the right side of the window, while the old ones had it on the left. I had a short look into a beta version of this a few month ago, and as far as I remeber it had a lot of options compared to the old one. I think there were also options for various line widths, but I can be wrong.

In any case, I guess the version you are using is bugy. I can have a quick look at it if you provide us the Cura version and profile you are using.

psavva commented 7 years ago

I'm using the latest Cura Version 2.3.1 Profile is attached: https://drive.google.com/open?id=0B6kS8tqbO6jVd3ZyMWdNR1pPQm8

However @Sebastianv650 , I think that this is not the real issue here. The issue is that LIN_ADVANCE is causing the printer to freeze, whereas, without it, it prints happily.

At the end of the day, gcode is a command, and the firmware is supposed to carry out whatever command is sent to it.

I therefore think that the issue which causes the high steps, and freeze is what really should be looked at.

Even if I move to Slicer, It doesn't resolve the issue that this gcode from cura triggers a bug. This is what should really be resolved.

james94jeans2 commented 7 years ago

2.4 is the latest version of cura

psavva commented 7 years ago

I'll update, thanks for letting me know :)

Sebastianv650 commented 7 years ago

If you execute a bugy *.exe on your PC it can also crash the hole system as a worst case. How should LIN_ADVANCE handle such cases? It can't do what it is told to do, and it wouldn't make any sense even if it could because it was told to do rubish.. Without LIN_ADVANCE it's not that important to have correct extrusion length numbers. If the extruder should do 3 or 5 steps will not harm Marlin, but it might be visible in the print in worst cases or maybe we have a skipped step but nobody notice it.

The "nice" thing: I can reproduce the gcode anomalies with Cura 2.3.1 and your profile. By the way, you can set the line widths under the Quality Tab and they are all set to 0.4mm. According to a short Google search Cura still can't do variable gap fill and such things, so the line widths in the config should be 100% what you get in the gcode. With Curas layer view I can also not find any lines that look much thinner or thicker than the rest of the model.

Slic3r gcode looks good. Cura 18.03 (based on 15.02 original Cura) is much better than 2.3.1, but also bad. I wasn't testing 2.4, but the changelog says nothing about a fixed bug regarding to that.

I also found one possible error source from Cura: It's not thinking about line lengths. The X and Y values of the gcode has 3 places behind the decimal point, sometimes the XY distance of a move is only 0.001mm. On E, we have 5 digits behind the point. But that's not enough to get a precise enough scaling for the extrusion distance if we have a 0.001mm move. Therfore Cura goes to the next possible number, at thats +0.00001mm on E, but that's not what we need in reality. But thats only one special case, I have no idea what's going wrong on the other places.

I can only think about a work around at the moment: Specify a parameter for LIN_ADVANCE that sets the extrusion width to a fixed number. This parameter could be set within the start-gcode. As only Slic3r uses variable extrusion widths and it also produces nice gcode, it would be OK to have the automatic thing only on Slic3r gcode and fixed numbers for Cura.. Any further idea is welcome.

psavva commented 7 years ago

Thank you for your explanation. I'll vote for setting it in the Firmware as a default, and overwrite it with some GCode in the slice as needed.

Sebastianv650 commented 7 years ago

OK so I will do the following as long as there are no further ideas:

Configuration_adv.h, LIN_ADVANCE section: Specify a LIN_ADVANCE_E_D_RATIO = 0 with descrition what it is used for and the formula for calculation (extrusion width layer height / ((filament diameter / 2)^2 PI). This will be used as a default value one very printer cold start. 0 means calculate ratio based on gcode values as it is done at the moment in RCBugFix.

Expand the already used M905 command to have additional options beyond K (set K factor) which would be: D for the filament diameter (D1.75) W for the extrusion width (W0.4) H for layer height (H0.2) If all this three values are passed at once, Marlin will calculate the new E_D_Ratio and use that until a new one is set or the printer is power cycled. This way, you can use a parametric start-gcode so that Cura or any other Slicer should be able to fill in the current values of this 3 parameters when executing or saving the gcode. If one or more parameters are passed as 0, or if not all 3 values are sent at once, the ratio will be set to 0 (automatic mode as in current RCBugFix). M905 will return the current K factor and E_D_ratio over serial (if connected).

psavva commented 7 years ago

@Sebastianv650 How did you generate the graph for the Extrusion Widths? Any software, or Excel?

I will check the same against Slicer, and CURA 2.4

Sebastianv650 commented 7 years ago

Just Excel and some math. Basicaly I'm importing the gcode to Excel, delete everything that's not G0 or G1 and then create collums for X, Y, E, dE, dXY, dE/dXY and width.

The language will be wrong for you, but maybe you get an idea how to do it: X=WENNFEHLER(TEIL(A3;FINDEN("X";A3)+1;FINDEN(" ";A3;FINDEN("X";A3))-FINDEN("X";A3)-1);"") Y=WENNFEHLER(TEIL(A3;FINDEN("Y";A3)+1;WENNFEHLER(FINDEN(" ";A3;FINDEN("Y";A3));99)-FINDEN("Y";A3)-1);"") E=WENNFEHLER(TEIL(A3;FINDEN("E";A3)+1;9);D2) dE=D3-D2 dXY=WURZEL((B3-B2)^2+(C3-C2)^2) dE/dXY=E3/F3 width=(1,75/2)^2PI()E3/0,2/F3

Sebastianv650 commented 7 years ago

@psavva Here is the new branch, including the new option as described above: https://github.com/Sebastianv650/Marlin/tree/Option-static_E_D_ratio

It's brand new and not tested up to now with real non-test prints. When you test it, remeber to keep the print speed below 125mm/s. If it works up to this speed, you can go higher and see when it crashes ;)

psavva commented 7 years ago

@Sebastianv650, I am a little unclear how you're expecting the configuration to be defined in the Advanced config file. Are you Expecting only a value of 0 or 1? What are all the valid values? I was under the impression that I should/could use the config file to override the settings if not given by the produced GCODE.

define LIN_ADVANCE_E_D_RATIO 0 // W H / ((D / 2)^2 PI)

Example of valid values for above? Extrusion width = 0.4mm Extrusion Height = 0.24mm D = 1.75mm

From reading the prior comments, I understand it's just a flag to enable/disable the Ration? ie Valid Values is 0 or 1.

I will try to test using the GCODE example, and specify the ration = 1, which I assume enable :)

Sebastianv650 commented 7 years ago

No, 1 will lead to realy wired moves. I see I have to redo the info text. What is expected to go there is the calculated default ratio you get using the formula in the comment. In your case 0.4*0.24/((1,75/2)^2*PI) = 0.039912.

So set LIN_ADVANCE_E_D_RATIO to 0.039912.

psavva commented 7 years ago

For anybody that would be interested, you can easily use variables to have Cura set start GCODE for you. This is what I have used: M905 K300 W{machine_nozzle_size} H{layer_height} D{material_diameter}

The {keywords} above will be replaced by CURA during slicing

Sebastianv650 commented 7 years ago

I will add that as an example for cura. But with one change: i don't think nozzle size is the right keyword here. There should be something line extrusion width or perimeter extrusion width.

psavva commented 7 years ago

Based on your feedback, I found {line_width} exists in the configs...

M905 K300 W{line_width} H{layer_height} D{material_diameter}

Putting this exactly as is in CURA will result in the values being replaced by the keywords.

psavva commented 7 years ago

Here is the Excel to Calculate Extrusion Widths if anyone is interested: https://drive.google.com/open?id=0B6kS8tqbO6jVcUF1bmQzTTVTRzg

Sebastianv650 commented 7 years ago

@psavva I reworked the description in Configuration_adv.h a little bit, can you have a look at it and decide if it's understandable now? When it's OK and the PR is created, I will add further information like the Cura start code line in the Marlin documentation.

Have you already tried printing with it?

psavva commented 7 years ago

I will be out of the country for a week, and will be able to test when I get back...

I've done some preliminary research around CURA extrusion widths and it turns out that it's how CURA has done it since the start. It's designed that way intentionally.

Hopefully your enhanced LIN_ADVANCE will play nicely with Cura...

Sebastianv650 commented 7 years ago

If you find a reason why they do it this way I would love to read that. There are some points where I can't understand why Cura is behaving as it is, but this one is hard on the edge to call it a bug!

hexane360 commented 7 years ago

This thread explains some of Cura's extrusion calculations: https://ultimaker.com/en/community/10422-how-is-extrusion-width-calculated

I'm not sure we can assume a constant line width throughout a print. Despite not doing gapfill, Cura still has a few methods to deal with perimeters on thin walls.

Sebastianv650 commented 7 years ago

@psavva if you already downloaded my branch, please do it again. I just fixed a bug, setting the fixed ratio worked the wrong way around, it enabled the auto detection of the line width instead of disabling it..

Sebastianv650 commented 7 years ago

@hexane360 as far as I know up to now Cura has no gap fill function. Even if it would, that would be OK if it would generate proper extrusion distances in the gcode. psavva published his Excel file, the graph looks the same as mine so I can confirm he did it right - have a look at it or the picture in my post. This spikes are not due to variable line widths, I fixed them all to 0.4 during my tests.

hexane360 commented 7 years ago

I don't think the noise is caused by a variable extrusion rate. I think that's most likely rounding.

However, what I'm saying is that Cura does have some variable extrusion width features, though you are correct it doesn't have gap fill. The thread I linked has a more in depth explanation, but basically if the shell thickness is not an even multiple of the extrusion width, Cura will fudge each line to have a width of (shell thickness)/(num lines), where num lines is something like floor(line width*1.5/shell thickness). Output from cura can have anywhere between 100% to 150% of {line_width}.

I am confident you will see this in practice, although possibly not with the calibration model used here.

MarlinFirmware / Marlin

LIN_ADVANCE freeze #5699

if ENABLED(LIN_ADVANCE)

define LIN_ADVANCE_E_D_RATIO 0 // W H / ((D / 2)^2 PI)