Printing issue, please,help

Hi, everyone.
I have few questions regarding my printings.
1. Printer making additional extrusion in one corner where is Z-axis lift. What is the reason?
2. Same story with skirt, In corners printer slows down and making more extrusion than in straight line.( I'm making skirt around close to detail to have more surface attached to the bed).
3. Printer slows down with horizontal axis during printing till complete stop. ( Microstepping issue?! - Now i have 1/16 for x/y axises).

Prusa + Gen 7 1.4.1 + Teacup + Slic3r + Repetier/Pronterface

; layer_height = 0.3
; perimeters = 3
; top_solid_layers = 3
; bottom_solid_layers = 3
; fill_density = 0.8
; perimeter_speed = 20
; infill_speed = 30
; travel_speed = 130
; scale = 1
; nozzle_diameter = 0.4
; filament_diameter = 3
; extrusion_multiplier = 1
; perimeters extrusion width = 0.42mm
; infill extrusion width = 0.42mm
; first layer extrusion width = 0.42mm

Here is part of gcode file with one layer

G1 Z0.600 F7800.000
G1 X34.684 Y34.727 F1200.000 E5.98054
G1 X34.760 Y34.474 E5.98524
G1 X34.711 Y15.289 E6.32631
G1 X15.289 Y15.289 E6.67161
G1 X15.289 Y34.711 E7.01690
G1 X34.263 Y34.760 E7.35423
Hope somebody helps, or at least directs me in correct path. Thanks in advance.

Wow, something is going on there! I'm thinking that your printer is expecting relative not absolute extrusion distances. That gcode sample is definitely absolute extrusion - in other words the E value is the total amount of plastic that has been extruded when you reach that point in the layer. (slic3r resets this number every layer) If your printer is expecting relative the its extruding the whole E value at every line, not the difference between lines!! The corners in your model are probably rounded so the printer does lots of tiny moves to get round. At each of these tiny moves its having to extrude a ton of plastic. You can change between relative and absolute E values in your slicing program or in firmware. Make sure you are only changing this for E, the other axes are and should remain as absolute positions. It would be better to set your firmware to absolute extrusion since this system doesn't build up errors.

Edited 2 time(s). Last edit at 01/24/2013 11:18AM by konwiddak.

Teacup is set to Relative extrusion by default. It is also my preference as it makes things much easier to read through and alter as well as splice files together.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Splicing files is an interesting point. I also suppose the cumulative error from relative distances isn't going to have any real effect on quantity of material extruded.

Thanks a lot guys !!! You save my day !!! Such a small point, but so valid !!! I've changed firmware settings to use absolute for extrusion, and adjusted steps(due previous problem I was used different value). For first little try I've HUGE difference. At least now I can work on fine tuning. One more time - THANKS ! I'll update soon with my upcoming results.

konwiddak Wrote:
-------------------------------------------------------
> Splicing files is an interesting point. I also
> suppose the cumulative error from relative
> distances isn't going to have any real effect on
> quantity of material extruded.

What cumulative error? From what I have learnt the firmware carries the remainder regardless of being in Relative or Absolute. If you are talking about the slicing software then maybe. But I have not heard any definite answers on this.

If it does accumulate then it would cause issues on Absolute not Relative because it would cause extra material to be deposited where it is not supposed to due to it carrying over to the next extrusion where it is not needed.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

this to me looks fine.... ok except for the fact that the filament's being heated too much... at least that's what it looks like... it looks like it did try to print on the right spot but it was too hot to stay in its spot.

.995+.995+.995+.995+.995+.995+.995+.995+.995+.995 = 9.95

BUT - if your slicer only works to 2 decimal places (just for examples sake) and you use relative extrusion, you would end up with
1+1+1+1+1+1+1+1+1+1= 10

This is the theory... That using absolute, your values would be rounded to 1+.99+1+.99 etc So in the end you still end up with 9.95, although along the way YES you do get "a little more here and a little less there".

Having said that, I use relative. The rounding doesn't bother me. And as Sublime says, easier to read, easier to splice / resume after an error (eg extruder blocks, I measure the part, find that z-height in my gcode and continue the print after unblocking the extruder)

But I digress,
Have you fixed the issue? doesn't look like ENOUGH extra plastic to be a relative/absolute issue? And if it's depositing extra on the one corner where it does a Z lift (where in the code there is NO filament fed) I think it might point to ooze in that corner?

It's a very strange looking print - they all come out relatively the same 4ebypek?

How does firmware take a decimal number, like 4.582 and interpret it for calculations in the processor. If that number is ever a fractional binary number (like a floating point) then there must be error due to the fact you generally can't exactly convert a decimal fraction to a binary one without an infinite length binary.

Is there a clever trick such that your decimal fractions are never ever ever converted to binary ones?

Edited 2 time(s). Last edit at 01/29/2013 11:58AM by konwiddak.

Looks like teacup has to do a "floating point like" calculation at one point. From wiki:

"The gcode parser converts floating values to integer or fixed-point representations"

Further on:

"decfloat_to_int[gcode.h] is used to convert incoming floats to integer implementations by starting off with a (very!) crude floating point implementation, then choosing appropriate scaling factors within the gcode parser itself. "

I don't know of a way this is possible without introducing a tiny error. I'm very willing to concede the error could be so infantessamally small that even the most complex, enormous prints would never see a position error if you used relative positioning.

konwiddak Wrote:
-------------------------------------------------------

> I don't know of a way this is possible without
> introducing a tiny error. I'm very willing to
> concede the error could be so infantessamally
> small that even the most complex, enormous prints
> would never see a position error if you used
> relative positioning.

What is a "fractional binary number" :-P

I work with CNC machines all day at work and my machines generally work in microns. Inside the circuitry of the machine, of course, this is expressed in a binary representation, because machines can only send signals in "voltage on / voltage off" format (ones and zeros) but 1mm = 1000 "units" in the machine, and this is then expressed as "1.000mm" on the controller for us humans who like to read 103.5mm instead of 103500 microns.

When you input G-code, the machine reads the g-code, realises where the decimal places are (and knows you are working in mm, not cm or microns), converts every number to microns, THEN expresses them in binary (which is the only language most electronics are capable of 'working with') and so in the end, the error can only be equal to the resoloution of the system (which depending on the system, is often microns. Grinding machines it is less, 1/10th of a micron or less... Repraps I'm not 100% sure of, if anything I would think it would be higher)

But this error can build up, depending on the software. (And as you say, it's preeetty much negligible... the physical error of our machines will outweigh the few 1000ths of a mm that it over/under extrudes...

JazzyB

1010.01 (binary) = 10.25 (decimal)

The .01 is my "fractional binary number"

What I was getting at is that:
10.3 (decimal) =1010.01001100110011001100110011001100110011001100110011001100110011... (binary to 62 digits)

Now realistically you would represent this as a float, but it's the same thing effectively.

Any maths where there is a conversion between decimal and float will introduce error for non integer values.

The way you are saying of taking the decimal and treating it as a number of microns avoids this problem.

Yeah, plus computers dont have a decimal point to work with when sending a signal... you can send 10.01 in ascii, but as a signal you can only send high voltage (ones) or low voltage (zeros) and rather than send a byte for each character the machine will generally prefer to raise the resoloution so that 00000001 becomes the minimum increment amount, then there is never a decimal place. Using 1 micron as an example, if the machine was asked to move to .5 of a micron it would simply round this off to fit in its resoloution of 1 micron...

I only know binary because of computers and their signals - hadnt heard of a binary fraction! On paper it makes sense but its not functional as a signal type and not as efficient as a data type. Totally functional from a mathematical viewpoint though!

JazzyB

Although computers don't have a "decimal point" floating point numbers have an assumed one.

Floating points are of the form:

1.01101001x2^10101

When written they are of the form: 00110100110101 where the first bit represents the sign, the next specified number (8 in my example) of bits are the numbers after the 1. And the last 5 are the power. The 1. Has no bit assigned since its always going to be a 1.

Anyway, this doesn't apply in this situation! :p

Over my head ;-)

But yeah, higher resoloution and a definate "minimum increment" are generally used, the decimal points are only there to help us weak humans to understand what is going on! ;-)