Cura Gcode has me puzzled

[jhinkle 1]

I just received my UM1 in the last 30 days.

I purchased the UM1 because of its printing resolution and ability to be modified.

I intended from day 1 to replace the marlin control system with one of my own design that would allow me to micro-step all steppers at 1/256 - or 16 times finer than Marlin does today.

Towards that end, I have been analyzing the Gcode that Cura produces since THAT is what drives the control system.

I have found two types of code generated by Cura that does not make sense to me --- I'm hoping someone can explain.

First -- an assumption on my part. I am assuming that Cura attempts to lay down a constant volume of material during the formation of the printed part.

I am also assuming that the printhead temperature is properly set for the material being extruded and the feed rate is set for precision printing and not speed.

A G1 segment says go from my last position (X/Y) to the X/Y stated and if an E argument is present -- push the specified number of mm of material into the printhead.

If you take the delta X and delta Y movement we can calculate a segment length (square root of the sum of the squares). This length will be the straight line segment length to deposit the amount of E material.

In the file attached and pictures below, X,Y,and E have been multiplied by 100000 to remove the dependence on floating point.

So --- for each G1 segment --- we have a straight line length that the printhead moves and we have the length of material the extruder pushes into the printhead.

If my first assumption was correct -- that Cura is attempting to lay down a bead of constant volume --- then the ratio of E length to Segment length should be fairly constant.

In fact --- most of the time that is true --- with a ratio (times 100) being in the area of .6.

The two areas that puzzle me is were Cura lays a Segment of approximately HALF the volume or one that is thousands of times larger.

The HALF volume segment may be associated with the under-extrusion concerns I have found in multiple threads.

The first number in the line is the actual line number in

UltimakerRobot_support.gcode

The string between the < > is the actual Gcode line segment definition.

The remainder is delta X, delta Y, Segment Length, E length, and ratio

Notice the first RED arrow .... it identifies a HALF volume segment to be extruded.

The second area that puzzles me is indicated by the second arrow where the amount of material is thousands of times more than the standard segment.

This second HI-VOLUME segment --- is Cura counting on it oozing sideways making a much wider track?

This second picture shows multiple HALF segments and multiple HI-Volume segments.

I have shown examples well away from the initial foundation layers that Cura builds --- so these segments are associated with the actual robot.

I have attached the file that holds this data if anyone would like to examine it in more detail ... please note ... only refer to the G1 lines that are associated with absolute X/Y positions. For this analysis, I did NOT pull out the relative addressed line ... there are not many --- but if you look at one --- ignore it.

http://joehinkle.com/DownLoad/GDumpNew.txt

Any and all comments welcome.

Thanks.

Joe

 

[illuminarti 18]

Yes, Cura specifies its extruder coordinates assuming that each segment's length will be filled with a rectangular cross-section bead which has a constant height (the layer height) and a constant width (the extrusion width - which is usually the nozzle width).

Length x height x width gives the volume of plastic required for the line segment. Knowing the diameter of the filament being fed in to the system, and assuming no volume is lost in the process, one can therefore calculate the length of input filament required for each segment of the print, to feed in the necessary volume of plastic.

Regarding the segments where you are seeing less-than-expected extrusion amounts; I'm not sure what is happening - it might be a bug in Cura, or it may be that Cura is doing something clever to fill in gaps, or compensate for overlapping lines. I'd need to see those lines in the full context of the file to figure out what is going on.

For your massive over-extrusion amounts, it simply looks like you're doing the math wrong. Those are lines that come after a G0 travel move where there is no extrusion specified. Therefore, you need to assume that the E coordinate remains that same as the previous line, rather than assuming it becomes zero.

 

[jhinkle 1]

I'm getting old ... I looked at those large volume segments many times and did not see the delta from zero.

This was a quickie test and I missed it -- nice catch on your part.

The real intent of the post was the HALF volume segments as they might be some of the under extrusion concerns people are posting about.

 

[Daid 306]

It's a simple case of Cura being smarter then you would expect. These lines are in the infill sections.

See the center infill line? It's thinner and squeezed between the contours. If it would do the normal amount of extrusion it would put down too much material.

The GCode viewer in Cura works in reverse on the GCode, it calculates the extrusion widths back from the E values. So under-extrusion in GCode would show there. (And it did in my very early CuraEngine code, which did had an extrusion bug)

 

[jhinkle 1]

Diad:

Thank you for quickly explaining.

Joe

 

[jhinkle 1]

Diad:

Does Cura ALWAYS generate gcode with X/Y/Z to two decimal places and E to 5 decimal places?

Do you see the precision increasing in the future?

Do you know what precision the other slicers generate?

Thanks.

Joe

 

[Daid 306]

Diad:

Does Cura ALWAYS generate gcode with X/Y/Z to two decimal places and E to 5 decimal places?

Do you see the precision increasing in the future?

Do you know what precision the other slicers generate?

Thanks.

Joe

 

https://github.com/Ultimaker/CuraEngine/blob/master/gcodeExport.cpp#L217

I opted for this precision because we have 80 micro-steps per mm, so 2 decimals should be enough for that. Note that Cura rounds everything to microns in the X,Y,Z position. So more then 3 decimals would not do anything.

Also, while you have 16 microsteps. Or, with better chips, 256 microstepping. The motors are not 100% precise with microstepping. (If you actually plot the physical position vs the microstep you will see a sinus wave)

For E we have this crazy amount of steps per mm on the UM-Original, which is why the E value has so many digits.

 

[jhinkle 1]

Thanks.

Yes - micro-stepping does not provide a linear movement between full steps.

Standard Stepper chips don't let you directly control the steppers current --- but if you could you can drive the coils NOT with a sine wave but with one which included specific harmonics that would linearize it's movement --- but THAT is much more complicated driver.

Personally - I'm looking at 1/255 for better control over the extruder and smoother motor operations overall.

You are at 78.7402 micro-steps per mm when driving 1/16 micro-steps.

That increases to 1259.8 micro-steps per mm when driving 1/256 micro-steps

Joe

 

[gr5 2,173]

It seems a little silly to go beyond 2 decimal places (.01mm) when the nozzle diameter is .4mm. But it looks like Daid pointed out to you the file to edit (gcodeExport.cpp).

Are you going to try to rewrite Cura also? Or just the firmware. You should know that Erik Zalm (not a UM employee) who maintains the "primary" open source version of Marlin is working hard on a ARM processor version of Marlin.

 

[Daid 306]

Are you going to try to rewrite Cura also? Or just the firmware. You should know that Erik Zalm (not a UM employee) who maintains the "primary" open source version of Marlin is working hard on a ARM processor version of Marlin.

 

Actually, it's a group of people working on that. But progress has been a bit slow so far.

I'm also working on it.

We're using TMC260 steppers. Which are quite awesome.

 

[gr5 2,173]

We're using TMC260 steppers. Which are quite awesome.

I'm glad you like them. But it sounds like they don't measure skipped steps so well when rpm < 1. Maybe that's good enough?

edit: changed to "skipped steps"

 

[Daid 306]

I do not thing detecting missed steps will be 100% accurate. But you can measure how much "force" the steppers need to apply, which is an indication of how well your machine is running. Could be useful for tuning your machine.

But I haven't plotted that data yet.