Help! Retraction issue

Hi All

Just got my Ormerod built, trying to print the ormaxis (well, just the gauge for a start). I loaded the gauge.stl into Slic3r, (settings appear to be what others have posted on the forum). I've then exported the g code, loaded in Pronterface and set it going.
It all starts off nicely, builds 1.73 up, then decides to retract about 2 metres of filament!!

Any one have any ideas? Using dc42's firmware.

Cheers

Stu

Stu - under printer settings->General settings in slic3r, you need to enable "Use relative E distances"

Cheers

Ray

ps - dc42: have you analysed what it would take to provide support for absolute extruder distances in the firmware? I think it would save a lot of grief for people starting out if RRP or you took a look at it

Aah, thanks Ray, I'll try that!

Stu

Quote
stoodle
Hi All

Just got my Ormerod built, trying to print the ormaxis (well, just the gauge for a start). I loaded the gauge.stl into Slic3r, (settings appear to be what others have posted on the forum). I've then exported the g code, loaded in Pronterface and set it going.
It all starts off nicely, builds 1.73 up, then decides to retract about 2 metres of filament!!

Any one have any ideas? Using dc42's firmware.

Cheers

Stu

Sounds like something to do with having an absolute rather than relative E values in the G code, though why it should change mid-print is a mystery. Double check that Slic3r is set to use relative E distances (Printer settings / General - though the print would not work at all if it was wrong) and you might check that retraction length is set to at least 4mm while you are there (Printer settings / Extruder 1). Check for any other strange settings generally - there are settings that Ormerod does not use but which may have an undesirable effect if enabled, such as "retraction when tool is disabled" - or maybe download the 3 suggested ini files and replace them in case you inadvertently changed something.

Was it perhaps at the end of the print? If so, the problem is likely to be in the end code (Printer Settings/Custom G-code). Look for commands that have an "E" parameter. I had a similar issue when an end code I had picked up switched the extruder to absolute mode and then commanded a retract 1mm - which was taken to mean that the entire amount of filament printed plus 1mm should be retracted!

Dave
(#106)

Quote
rayhicks
Stu - under printer settings->General settings in slic3r, you need to enable "Use relative E distances"

If it printed OK up to 1.73mm, I doubt it is that simple. The wrong setting makes a mess from the very start.

Dave
(#106)

Working a treat now, thanks Ray!

Many happy hours printing to come now

Stu

It depends where it falls back to "0" Dave - I managed some small prints from Cura before Cash made his plugin, but at some point during long prints, the E distance dropped back to zero and that triggered the rewind (almost as if there's a wraparound on overflow in the slicer) - it's odd that it works at all frankly, so it looks like the duet is trying to calculate relative E values from the absolute values given in files sliced that way and manages fine UNTIL the values do this wraparound and it then calculates a massive negative relative extrusion. I haven't really looked properly at the code (gcode or firmware), but will try to get my head around it if dc42 doesn't fancy it It may just be that it only needsa slight tweak.

Cheers

Ray

Quote
rayhicks
ps - dc42: have you analysed what it would take to provide support for absolute extruder distances in the firmware? I think it would save a lot of grief for people starting out if RRP or you took a look at it

I think the issue may be that the Duet uses floating point maths for all distances, including extruder distances, so there are only about 7 decimal digits of precision. slic3r outputs extruder distances to 5 decimal places. So with absolute E distances, rounding error would degrade print accuracy once you extrude about 100m of filament, which is not impossible for a large print. But I haven't looked at it in detail.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
rayhicks
ps - dc42: have you analysed what it would take to provide support for absolute extruder distances in the firmware? I think it would save a lot of grief for people starting out if RRP or you took a look at it

I think the issue may be that the Duet uses floating point maths for all distances, including extruder distances, so there are only about 7 decimal digits of precision. slic3r outputs extruder distances to 5 decimal places. So with absolute E distances, rounding error would degrade print accuracy once you extrude about 100m of filament, which is not impossible for a large print. But I haven't looked at it in detail.

If the 5 decimal place accuracy is for mm of filament, the accuracy would degrade after only 100mm of filament which would occur in nearly every print. But it should be pretty easy to overcome by truncating all incoming absolute distances to the *least significant* 7 digits (up to 4 or 5 decimal places) before converting to floating point, and having a simple trap to deal with overflows whenever the arithmetic results in a move that is impossibly large. Unlike XYZ moves, small rounding errors that accumulate over a print are not going to matter because they will merely result in a miniscule amount of over or under extrusion spread over the whole print that will be insignificant compared with the over or under extrusion caused by filament diameter tolerances.

Dave
(#106)

Thinking about it, if the incoming values (in mm) were truncated/extended to 5 decimal places by the input parser, and then the decimal point ignored (effectively multiplying by 100000), it could trivially be converted to a signed 32 bit binary integer, which is perfect for the 32 bit ARM, and would allow representations of distances in excess of 200 meters. Integer arithmetic is far faster than floating point (and uses less RAM), and for this purpose would be just as accurate (if not more so). I think I would be converting all incoming values to stepper-motor step units (perhaps 1/256 of a step) immediately, and then carrying out all operations in stepper units using integer arithmetic. The 4 values (X, Y, Z and E) for converting mm to stepper units are going to be constants for any particular print, and so much of the heavy work needed (e.g. to convert mm to steps and speed to step interval times) could be pre-computed as a one-off operation and lookup tables created for print-time so that integer addition and subtraction would end up being the only arithmetic operations needed. All multiplication and division will either be by a power of 2 (accomplished by a simple binary shift operation), or will have been pre-computed so they can be carried out by 8 or so table lookup and addition operations.

But then I'm thinking as an assembler programmer!

Dave
(#106)

If I get time I'll run a test - but last time I ran one that retracted wildly I think it the last positive E position that Cura came up with was around19000mm, then it went to 0.01 ish and climbed it's way up. The firmware coped with the large positive absolute distances fine, it was the (apparent) wrap around to 0 in the gcode that triggered the retraction. Aborting an absolute print then restarting it has the same effect (ie it'll run fine for a few metres of filament, but when you restart the firmware remembers the absolute filament position and the first absolute position it sees in a gcode makes it rewind to there). [edit]It's the wild retraction is not due toa rounding error from the scant investigation I did (this was before Cash's plugin came out so just working from memory).

Ray

Edited 1 time(s). Last edit at 03/07/2014 02:15PM by rayhicks.

dmould, my mistake - yes only 100mm needs to be extruded before rounding errors occur.

I agree with you, I would rather use integer arithmetic in most places in the Duet firmware. However, RRP have decided to use floating point, and I don't want to make large-scale changes that make it less likely that RRP will merge my changes into their version. I think that relative extruder distances make more sense anyway, even if that isn't what other machines use.

I'm actually more concerned with the use of floating point maths for the system time, which I really don't like. The precision of the system time will drop the longer the Duet is powered up. But now that I've moved the ADC functions into a tick interrupt, I think the only thing that depends on the time is the heater PIDs, and they only kick in every 500ms. So I think the loss of precision in system time doesn't actually matter any more - you would have to run the Duet for 3 months without resetting it before the PIDs started misbehaving.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

for what it's worth, here's the place of the "wraparound" in a file I sliced in early Feb

G0 X116.93 Y13.24
G0 X117.09 Y13.15
G1 F4500 X109.35 Y5.41 E19360.20614
G0 F3600 X109.26 Y5.58
G0 X111.67 Y7.14
G0 X111.79 Y6.99
G1 F4500 X115.49 Y10.70 E19360.48865
G1 F2400 E19355.48865
G0 F3600 X97.16 Y3.40
G1 F2400 E19360.48865
G92 E0
G1 F4500 X96.88 Y3.54 E0.01115
G1 X95.94 Y3.45 E0.04542
G1 X96.32 Y4.25 E0.09300
G0 F3600 X95.89 Y4.67
G1 F4500 X94.91 Y3.70 E0.16733
G0 F3600 X94.25 Y3.89
G1 F4500 X95.47 Y5.10 E0.25969
G0 F3600 X95.04 Y5.52
G1 F4500 X93.62 Y4.10 E0.36816

Presumably Cura drops back to zero because of a limitation on its fixed point range - it sends a G92 which seems not to be acted on properly by the firmware, this also explains why restarting an abolute Cura print causes retraction, since Cura places G92 E0 at the top of the file by default, but the firmware remembers the previous E distance and goes there.

The problem probably lies in the function "void GCodes::LoadMoveBufferFromGCode(GCodeBuffer *gb, bool doingG92, bool applyLimits)" this function exists to turn relative x,y,and z values into absolutes, and E values into relatives to be passed on to the Move class from the GCodes class - it looks like the error is particularly in the clause below (which is reached only for non-axis moves that are absolute (where i>2):

i

f(gb->Seen(gCodeLetters))
	      {
		    float moveArg = gb->GetFValue()*distanceScale;
	        if(drivesRelative || doingG92)
	          moveBuffer = moveArg;
	        else
	        {
	          float absE = moveArg;
	          moveBuffer = absE - lastPos[i - AXES];
	          lastPos[i - AXES] = absE;
	        }

I'll see if I can fix it when I'm next at my machine - unless you'd care to dc42

Ray

Edited 1 time(s). Last edit at 03/07/2014 04:16PM by rayhicks.

I'll take a look at how G92 is handled for the E axis. However, even if I fix this, there will still be problems with absolute extrusions, because of the lack of significant bits in the floating point representation of extruder position.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks dc42 - I'm sure it's a bug (rather than a missing feature), since the firmware is intending to translate the absolutes into relatives (but stumbling on the G92 E0 as far as I can see) - the knock on effect of the rounding error may well be the next contender for the "why does my first print fail" award once this is fixed though However Cura at least resets to E0 around 20 metres into the print in the example I pasted above, and I vaguely remember (but can't find) one slicing where it reset at 4 metres - I'm not sure what their logic is in resetting when they do, and I haven't ever tried slic3r with absolute E to see what the gcode looks like.

Anyway my approach to this bug was going to be to try sticking a "lastPos[ i- AXES] = 0.0;" in the clause above if "doingG92 "is true

Ray

I'm only thinking about it because I am seriously toying with the idea of writing a complete firmware version from scratch in assembler as a "busman's holiday" project. Arm is so versatile that it is quite a pleasure to write. I already have assembler code for TCP/IP and USB functions that would probably drop in reasonably seamlessly, and a RTOS code framework that would work fine, so I could concentrate on the robotics side. The only difficult part of that AFAICS is the acceleration/deceleration function. I think one way to go would be to use counters for each stepper that are decremented by a timer interrupt and trigger a step move when reaching zero, and have the timer interval set by a completely separate acceleration module that computes the required speed and uses it to set the timer interval. Then the movement algorithms will only need to be concerned with the vector and can load the counters with the same numbers for the same relative movement vector regardless of what the speed of that move will be. A string of buffered counters pre-loaded by the movement module would then be used as the lookahead buffer by the acceleration module to compute what the current speed should be and set the timer interval.

I guess that while the XY speed limit should be computed from the vector, Z and E speeds can be applied independently, as can acceleration for all 4 motors with the minimum resultant speed limit governing the whole move. Which could then alter the acceleration of other axis in the previous move, which could affect its previous move and ... my head hurts, I'm going to open a beer!

Dave
(#106)

While you deservedly sit back and relax... Have you checked out the wiki on firmware versions? There seem to be a range of ideas around one or two of which match your ethos I think [reprap.org]

If you need a beta tester...


Ray

Quote
dc42
I think the issue may be that the Duet uses floating point maths for all distances, including extruder distances, so there are only about 7 decimal digits of precision. slic3r outputs extruder distances to 5 decimal places. So with absolute E distances, rounding error would degrade print accuracy once you extrude about 100m of filament, which is not impossible for a large print. But I haven't looked at it in detail.

If it is a problem with accumulating rounding errors, then we should have a problem with relative distances and not with absolution distances. Right?

Quote
Flyskyhy
If it is a problem with accumulating rounding errors, then we should have a problem with relative distances and not with absolution distances. Right?

No. If the Duet is given a relative extruder distance, it just has to multiply that distance by the extruder steps/mm to get the number of steps. If it is told to extrude to an absolute distance, it has to subtract the current extrusion amount from that distance (which is where the rounding error occurs), then multiply that difference by steps/mm to get steps.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
No. If the Duet is given a relative extruder distance, it just has to multiply that distance by the extruder steps/mm to get the number of steps. If it is told to extrude to an absolute distance, it has to subtract the current extrusion amount from that distance (which is where the rounding error occurs), then multiply that difference by steps/mm to get steps.

Aha, now I understand! I assumed it calculated the absolute amount of steps needed, and subtract the previous amount from that.

Fixing absolute extrusion is on the list - [github.com] (though it's slightly mis-titled with what I thought the problem might be). I'll point Adrian at this thread, as it may contain an obvious fix for him.

Ian
RepRapPro tech support