Show all posts by user
Page 1 of 1 Pages: 1
Results 1 — 24 of 24
It is indeed mm/min in the gcode.
The behavior occurs also in the middle and at higher speeds. Certain ratios of extruder- and motor-speed are causing it. Sometimes, very low speeds (e.g. for the first layer) even work better than faster speeds.
I guess that stepper pulses coincide at certain feedrate ratios and cause mess within the firmware (accumulation of interrupts?).
Had no luck with Rep
by
ribaldos
-
Delta Machines
The topic is still open. Can someone with Marlin and RAMPS please test the three commands? It should not take more than 3 minutes.
by
ribaldos
-
Delta Machines
Quotedc42Does it vary with the number of segments per second that you configure?
The behaviour expresses differently when going as low as 20 - 30 segments per second but it still persists (see upper [3] for further info)
QuotefrankvdhG29 is for auto-levelling (Z probing). Did you mean G92 E0?
Thank you for the correction!
by
ribaldos
-
Delta Machines
Hi dc42, yes, the behavior is still present when using higher speeds, however it is best visible with lower speeds. The weird thing is that it does not occur when the 4th axis (E) is not involved. In that case even lower speeds are possible.
by
ribaldos
-
Delta Machines
.. for confirming a bug in Marlin. It's a very simple test:
go to starting position using G1 X84 Y-45 Z30 F1000 (Z and F are arbitrary) reset Extruder position using G92 E0 move slowly to second position while extruding 17 mm using G1 X-54 Y51 E17 F180 (feed unit mm/min)
The effector should start moving with 180 mm/min and soon accelerate like in this [1] video. We are affected with the bug si
by
ribaldos
-
Delta Machines
People keep saying that: 32 bit for a Delta, everything else is deprecated or a waste of time. In my opinion, 8 bit and 16 MHz RISC (= 16 MIPS!) and all the nice periphery (e.g. 16 bit timers with variable COMP-buffers) is more than enough for a delta when hosting a nicely done firmware. At least when I am printing with decent speed (< 150 mm/s). Or did I miss something?
by
ribaldos
-
Delta Machines
I also switched from Marlin to Repetier, however, I had a few issues (http://forums.reprap.org/read.php?267,655768) which I solved by switching back to Marlin.
One thing I really miss in Repetier is the ability to print really slow, e.g. for small structures which otherwise get too hot. Repetier has a minimum speed calculated from the acceleration. This minimum speed is quite high when working wi
by
ribaldos
-
Delta Machines
Here our temporary solution: switched back to Marlin using 30 mm/min minimum speed and .3 mm first layer height, here the bug reported previously does not occur.
Another two things we noticed with Repetier:
The motors are singing songs when printing (C, D, A, G#,...) while Marlin does not.
Low speeds (about less than 300 mm/min with 1000 max acc.) lead to severe problems, partially resettin
by
ribaldos
-
Repetier
FYI: tried a few things: turned off endstop check, raised STEP_DOUBLER_FREQUENCY to 15000, set DOUBLE_STEP_DELAY to 1 (as seen in this post ), lowered all accelerations to 1000 max, lowered ZJERK to 0.1. However, it just seems to get worse. I attached an image of two test prints, with the right one after parameter change (same gcode).
Edit: are there any such facilities as to check for steps los
by
ribaldos
-
Repetier
Hi there,
we recently moved from Marlin to Repetier for our Kossel Mini driven by a RAMPS 1.4 board. Everything seems to work fine, the nasty speed deviations we had with Marlin have vanished (see [1] for details).
However, it now appears that we are loosing steps (see attached image for failed prints) and I don't know the reason. First I thought the head hits the print but it seems that steps
by
ribaldos
-
Repetier
After a few more tests I've posted a bug report on github [1]. I hope, someone can confirm the bug soon.
In between I tried to move to Repetier, however it's not that easy. What would be the best approach to use the PanelOne from t3p3 with Repetier? Is there a firmware-side library for similar panels which just needs adjustment of Pins?
Generally, is it okay to just define Ramps and look if it
by
ribaldos
-
Slic3r
I didn't use the Marlin definitions for Arduino before. It is never mentioned in any tutorial, including t3p3's. However, using them now with Arduino 1.6.7 didn't help me.
I also disabled the Panel One. However, still the same behavior.
So should we use Repetier?
Could someone try to reproduce this bug on his Mega-Marlin-RAMPS-Delta? Go into x-direction by 60 mm using 180 mm/min and extrude 7 m
by
ribaldos
-
Slic3r
Okay, here are the news.
First: the new RAMPS + stepper drivers I got from T3P3 didn't do it. We had exactly the same behavior as before.
I remembered that the printers user interface (Panel One) sometimes did respond very slowly when using the knob. So I produced the upper "bug" and tried to navigate the marlin menu. I observed that during the accelerated periods, the cursor was not responsiv
by
ribaldos
-
Slic3r
Okay, the behavior from my previous post resulted from the jumpers I didn't transfer to the new E1 port. Now it works........ like before
The wiring is exactly as suggested in the T3P3-Documentation. Both electronic boards are not exposed to excessive EM.
The longer I think about it, the more I assume it's the RAMPS board allowing some cross-talking between the stepper drivers. When you again
by
ribaldos
-
Slic3r
The mysterium continues.. The replacement Mega2560 arrived today and I tested it... Same behavior.
I cloned the latest RC3 Marlin firmware and transferred the settings... Same behavior.
Currently I am trying to exchange PIN_E1 and PIN_E0 in firmware as well as the drivers and connections on RAMPS to test the board. However, it shows really weird behavior e.g. z moving up when giving an extrusion
by
ribaldos
-
Slic3r
I thought of the DELTA_SEGMENTS parameter as well, but it wouldn't explain the speed-up. Except there is a "catching up" mechanism in Merlin as you mentioned but I rather don't think so. However, I gave it a try using values of 50, 40 and even lower but it still showed the same behavior. I also tested removing the stepper driver for the extruder to check for electrical feedback but it still showe
by
ribaldos
-
Slic3r
Hi Paul,
I used "G92 E0", moved to the outer left and started testing by alternating use of "G1 X-57 Y51 E17 F180" and "G1 X84 Y-45 E17 F180". The "E17" was replced by "E7" or "E30" or similar to test varying extruder feed.
I also just tested your point 2) by issuing "G1 X0 Y0 E8 F180" from the outer left. The same behavior as before, except that it suddenly stops in the middle without decelerat
by
ribaldos
-
Slic3r
Thanks for your answers! We did some further investigation. The firmware is the same as the latest git commit from Think3DPrint3D [1] except the calibration parameters. I rolled out the firmware anew while using the latest Arduino (1.6.7), switching to GCC -O3 optimization and overwriting EEPROM with default settings. However, we've still the same behavior.
As for the theory with computation of
by
ribaldos
-
Slic3r
We tried disabling pressure advance but without any improvement. PA only seems to insert a few additional extruder feeds.
I uploaded a new video showing the acceleration while printing a skirt [1]. This time I filmed the extruder wheel which accompanies the strange head acceleration. I also attached the gcode used for the print on the video: indeed the feedrate seems not to be changed during the
by
ribaldos
-
Slic3r
Okay, I will try to disable pressure advance. However, shouldn't this option only affect the extruder speed? Furthermore it's already compiled by Slic3r. So you mean the Arduino is just too slow to process the commands created by pressure advance?
Edit: we already print using SD card
by
ribaldos
-
Slic3r
The printer is from think3dprint3d, I think they used the A4982 driver for our Kossel Mini rev 2.
Still, could it really be the driver? The extruder speed seems to adapt to the strange acceleration phenomena, which in turn means that Slic3r or the firmware knows about them. However, the stepper circuit is feed-forward only.
If it helps I will recheck the driver chip this evening.
by
ribaldos
-
Slic3r
We made a few tests: the strange behavior does not seem to be caused by the acceleration parameters. The default acceleration is 9000 mm/s², which I suspect is the end-effector acceleration. We tried 11000 mm/s² but it brought no improvement.
What is really weird: there are circumstances in which the trajectory is driven off cleanly and without speed changes. We observe the strange behavior main
by
ribaldos
-
Slic3r
Hi Dave,
thanks for your reply! I will look for the acceleration parameters and report back when I could validate your suspection.
Regards
ribaldos
by
ribaldos
-
Slic3r
Dear Slic3r-users,
we own a Kossel Mini printer (bowden extruder) and observe strange printing behavior during larger-area jobs [1]: While doing solid infill, the printing speed continuously increases and decreases within longer paths. The extruder feed speeds up and down simultaneously. It seems as if Slic3r wants to spare time. The problem: when decelerating again, too much filament is coming
by
ribaldos
-
Slic3r