Slow and weird at 140mm/s on curvy/circular path
-
AMAZING ! it's working and now really smooth !
MaxReps: 8, StepErrors: 0. Underruns: 0I pushed the printer to 140 mm/s and no visual degradation, at 200 it jerk.
Thanks !!!! You're a great master !
-
Oh sweet.
Just a note, I think it might have worked had he replaced the MOTION steppers with 1.8 degrees, not just the extruder stepper.
A firmware fix is always a nicer solution.Edit: Though, I guess I didn't understand the problem fully. Step generation wasn't the issue, it was merely the lookahead queue? Or was it a combination of both?
-
The problem was lookahead, in other words the g-code segments were very short and the queue was starving.
Changing the steppers or microstepping would not have changed that.
-
The improvement is really, and as my english is not really fluent i took a short moovie, inner path are at 100mm/s in first moovie part and speed increase to 150 % in second part.
https://youtu.be/gBk3flOt3-wI just notice that when you increase speed by the web the retraction and prime are also afected, mainly the prime, result is a bad seam where speed change because you will appear a big blob.
-
Indeed, however in theory you could make gcode with even smaller segments or go even faster. I think that either slicers or the model being sliced should work at the resolution of the type of printer being sliced for.
For reference I have used programs like EasyFit (no cost) to drop the number of triangles on really detailed models.
-
Cubexupgrade, our posts crossed.
you are right the speed slider on the web interface increases all speeds including extrude and retraction speeds. this can have bad effects on extruders which don't like going 1.5x faster for example, retraction skips and then you get a huge over extrude when the next extrude command is issued. I find the speed slider useful for testing speeds but always re-slice t the faster speed for actual prints to keep my retraction speed constant.
-
Thanks for the informations, i didn't know this soft. My main workflow are rhinoceros3d and fusion360 and they are not really good (or me) for mesh generation.
One thing i didn't understand is why we cannot send a STEP file into a slicer to generate a gcode ++…. Maybe in few years !
-
Thanks for the clarification about the speed slider, i noticed this but was not sure.
-
Incidentally, I printed a stress test file yesterday and got 50,000 underruns. I'll reprint with new firmware before I post the ugly results
-
I ran out of filament during the re-print, but after 2.5 hours there were 0 underruns, so I think that specific problem is fixed. And I've discovered that I had some slightly loose arm joints, so I can't conclude much from the print quality issues that I was seeing. Will attempt another go at it.
-
You bit the record ! 50 000 ! Are you slicing a dental model ?
For me motion is now really clean, i waiting my PT100 to get clean print, i installed an old thermistor that i don't all informations and i have wave on my print evry 10mm… -
you are right the speed slider on the web interface increases all speeds including extrude and retraction speeds. this can have bad effects on extruders which don't like going 1.5x faster for example, retraction skips and then you get a huge over extrude when the next extrude command is issued. I find the speed slider useful for testing speeds but always re-slice t the faster speed for actual prints to keep my retraction speed constant.
I could modify the code so that moves that only involve extrusion or retraction and possibly Z movement (no X or Y movement) are not affected by the speed slider. Would this be a good idea?
However, there are already two ways round this issue:
1. Even when you use the speed slider, the speed limits set by M203 are respected. So you can set the E parameter in your M203 command to the maximum extrude or retract speed that you want to use. Of course, this will also limit the speed at which you can load or unload filament.
2. Some slicers have a "use firmware retraction" option. If you use this, then you define the retraction amount and speed using M207 and the speed is not affected by the slider. See http://reprap.org/wiki/G-code#M207:_Set_retract_length.
-
It's a good idea to limit this slider effect to XY, but extruder have to follow only while printing and not during retraction. As you described the problem is while retraction or prime extrude for bowden setup and i don't remember if slicer comment those tiny part.
I never used firmware retract but it can be a good solution to manage this slider. Is it better to use it vs slicer ? And is it necessary to use it with pressure advance control M572 ?
-
Hi,
A small update about high speed print, i get this statue in 4h30, 220mm height at 0.12 mm layer height.
I setup the speed near 200 mm/s +-20 % . and 10 % infill, 3 loop.
S3D announced 2h40, quicker than the reality (it surely forget retraction) but the duet handle quite well this speed but on really sharp curve there is some artifacts.
-
Hi Cubexupgrade
can you embed a larger version please!
-
@cubexupgrade:
I never used firmware retract but it can be a good solution to manage this slider. Is it better to use it vs slicer ? And is it necessary to use it with pressure advance control M572 ?
The main reason I added firmware retraction is to handle mixing hot ends such as the Diamond. With these, all the filaments need to be retracted the same amount, regardless of the current mixing ratio. Firmware retraction in RRF does that.
Use of pressure advance is entirely separate. However, if you use a lot of pressure advance then you should reduce retraction, because at high printing speeds pressure advance will already do some retraction at the end of an extruding move that is followed by a non-extruding move.
-
Sorry i'm little newbie with this kind of code…
I will post more picture, the back is clean but the front less cause it have lot of curve.
I will do more print of this with less mesh to have a reference.
Thanks DC42 for your explanation. I will do some test.
-
Some better pictures :
https://drive.google.com/folderview?id=0B3QhjlM2HLWsa0RZbXNnS29tMTA
I didn't setup a minimum layer time for cooling.
-
Sorry to butt in on the end of this thread but having just rebuilt my delta to fix an issue (unsuccesfully by the look of it) before swapping over to the DuetWiFi, from the 0.8.5 board, I've got a print running and decided to check for underuns as I to use S3D and have 0.9 steppers.
I got MaxReps: 5, StepErrors: 0. Underruns: 229 over about a 5 minute window.
Sliced with 3.02 of S3D at only 90mm/s.
Only noticed this as I wanted to baseline things before swapping
Copy of the gcode file zipped in dropbox https://dl.dropboxusercontent.com/u/28032744/chatimage/caselid.zip if that helps. -
S3D 3.0.2 is before the "reduce small segments" fix, you should probably update to 3.1. (I'm still running 3.0.2 and not having any big issues since David patched the motion planner queue, but it depends a lot on the STL poly count.)