Possible bug in elasticity compensation when extremely low values are used

Hello,

So I really like the elasticity compensation, even with direct drive extruders. One problem I've encountered, though, is when using very small values, it causes the x/y movement to either attempt a crazy move and stall, or make a z move, and loses registration. It seems like it could be related to some extruder moves, but I've not investigated thoroughly when it is happening in the gcode.

I believe I was trying to use values as low as S0.01 when the problem occured.

I guess I should mention I'm using a duet 0.8.5 with firmware 1.15 beta 3

Edited 1 time(s). Last edit at 09/03/2016 05:42PM by n8bot.

Here are some photos. Near the top, where the real drastic effects take place, is where I changed the S value from about 0.03 to about 0.01. Most of the print was done with some value, but it wasn't until I decreased it further that the real problems started.

[imgur.com]

Thanks for your report. I've added a work item to check out the behaviour of pressure advance when small nonzero values are used.

---

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. BTW I'm using Simplify3D to slice; I'm not sure if the problem is present with other slicers' gcode.

Is this a feature/setting in the slicing software or in the RRF on the controller? Where can this be setup? Does it help on corners also, where jerk settings are low and using a long Bowden tube, or only at the beginning and ending of the loops?

It's built in to RRF. See [reprap.org]. It helps wherever extrusion speed varies over a move, including corners.

Edited 1 time(s). Last edit at 09/04/2016 01:32PM by dc42.

---

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
It's built in to RRF. See [reprap.org]. It helps wherever extrusion speed varies over a move, including corners.

Just tried to use it tonight, added a value of S0.15 (I have a 70cm bowden tube) and with the retraction set to half of what I used, around 2mm. The layers started to look a lot cleaner and with sharper edges, I was really impressed, until on the third layer when starting a loop, the X axis acted weird and skipped almost a full centimeter in steps ! This was the first time I had ever had a skipped step on this printer...

M572 is out now, and everything looks ok so far, but I really like how the extrusion worked with it...
I'm on duet 0.8.5 with 1.14 at the moment.

Edited 1 time(s). Last edit at 09/06/2016 02:24AM by unromeo21.

Your S value of 1.5 is extremely high. Try lower, for example 0.2.

Edited 1 time(s). Last edit at 09/05/2016 05:35PM by dc42.

---

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].

Oh, sorry, that was a typo. The value was S0.15. The results were excellent, infill was uniform and no gaps.

Quote
unromeo21
Oh, sorry, that was a typo. The value was S0.15. The results were excellent, infill was uniform and no gaps.

I suspect your X axis skipping was nothing to do with pressure advance. Perhaps the print head got caught on a blob?

---

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].

Hmm.. I was there when it happened: I had a print made of two objects, it printed the first two layers flawlessly, no blobs, no strings, on third layer the first object was done and the head moved to the second object and in mid air it started to act strange and never made the last centimeter to the second object. It continued to print, around 1 cm short of it's target. This never happened to me before, and the printer is made with good quality components (IKO linear rails, 30x30 extrusions, PU belts with steel core, everything tight and stiff, it will break the hot-end heatbrake before skipping steps).
I know that right before this happened, I upped the speed on the web interface from 100 to 140%, speed of around 2000mm/minute at 100%, so it was printing quite slow.

I will give it another shot this evening, see how it goes.

Happened again, this time a little bit less than 1 mm. Just made a "clank" noise and continued printing. One thing is for sure, this does not happen without the M572 in the config file.

maybe you could post a video showing the problem? maybe even one with M572 and one without?

I could try, but it happens randomly, every time it was after a few layers into the print, so I have record more than half an hour of print time. I will try with the same g-code file to see if I get the "hiccup" at the same point in time.

The thud noise and a skip is exactly what happens for me, and the exact same gcode works flawlessly without m572. I was, however, using a much much much smaller value for m572, but also I have no bowden tube so maybe it's related to the relationship between retraction distance and m572 value.

Edited 1 time(s). Last edit at 09/14/2016 09:04PM by n8bot.

Did some more tests, I can confirm that skipped steps only happen when the M572 is used. I have now moved to direct extrusion and given up on bowden tube, so I don't think I am going to need this feature at this moment, but the second extruder might be installed with bowden, so... would be nice if the bug gets fixed.

Thanks

Quote
unromeo21
Did some more tests, I can confirm that skipped steps only happen when the M572 is used. I have now moved to direct extrusion and given up on bowden tube, so I don't think I am going to need this feature at this moment, but the second extruder might be installed with bowden, so... would be nice if the bug gets fixed.

Thanks

m572 works great for direct drive extruders as well, so I really hope we can get this bug worked out of it.

I have reproduced this issue on a test print with hexagonal infill by setting pressure advance to 0.005. Investigating.

---

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].

I have fixed this issue in the forthcoming 1.15e release of RepRapFirmware.

Edited 1 time(s). Last edit at 10/01/2016 07:38PM by dc42.

---

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].

Hi David,

had an event today that may be related. I just installed 1.15e to try pressure advance.
I had a print today, and maybe one hour into the print I heard some strange noise. Thought the print head was bumping into a blob. But there was no blob. So I watched the next few layers: very fast travel moves, nearly at the same positions the next few layers. Then the print shape on this position changed, and the hiccups were gone. There were no lost steps, only ultra fast moves, that were nearly shaking the printer. Never had this bevor.
I had: M572 D0 S0.1 in config.
I took a look into the g-file for that layers, but all travel movements were with F7800.

Could be this part:

G1 X12.355 Y16.707 E0.0046
G10
G1 X10.435 Y16.598 F7800
G1 X10.435 Y14.836 F7800
G1 X7.565 Y14.836 F7800
G1 X7.565 Y16.435 F7800
G1 X0.793 Y16.050 F7800
G11
G1 X1.264 Y15.579 E0.0199 F3600
G1 X1.264 Y14.900 E0.0203

Slicer is S3D with option 'Avoid crossing outline for travel movement' activated, so its following the outline.
But in the g-file are more of that moves, and only a few layers had the problem.

This are my movement settings:

M201 X1000 Y1000 Z1000 E1000		; Accelerations (mm/s^2)
M203 X20000 Y20000 Z20000 E7200		; Maximum speeds (mm/min)
M566 X1200 Y1200 Z1200 E1200		; Maximum instant speed changes mm/minute

This is from M122:

=== Move ===
MaxReps: 5, StepErrors: 0, MaxWait: 2ms, Underruns: 0, 0

and software info:

Firmware Name: 	RepRapFirmware for Duet WiFi
Firmware Version: 	1.15e (2016-10-02)
WiFi Server Version: 	1.02
Web Interface Version: 	1.12

My guess is that the particular sequence of fast travel moves was exciting a resonance in the printer mechanics. Reducing the XY jerk to the default of 600 may help. Pressure advance is not active in travel moves.

---

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].

How do you enable Hardware retraction in S3d ? I can't configure S3d to use G10 and G11 commands

What version of S3d do you have?

Quote
dc42
I have fixed this issue in the forthcoming 1.15e release of RepRapFirmware.

I have been testing this in the last two weeks or so and it's working perfectly ! No skipped steps or strange behavior. Wonderful ! Thanks a lot for your effort.

Regards,