Closed Traumflug closed 13 years ago
I am also seeing issues on acceleration, and have had to disable it.
I'm seeing problems because of my drastically different Z and XY steps/mm I think. Z is 700 steps per mm, XY is 8. So, in GCODE I do a G1 that just moves the Z, and that works fine, but then the feedrates and acceleration constants are wrong for the next move, and it does maybe 1 tick per second for that whole move. Disabling acceleration helped, though I see the issue under both RAMPING and REPRAP acceleration. I will check out your proposed fix and see if it's related.
Hmm, I have applied your fix to my branch, but I didn't see a big difference. When I get moves with a drastic change in feedrate, F30 to F3000 change between moves for example, I get back to my 1 tick/sec bug (for REPRAP acceleration). On RAMPING Acceleration, it sounds cool but it pauses for about a second between moves which isn't right.
I'm getting very nice prints without acceleration though, 50mm/sec: http://jakepoz.com/images/IMG_0021.JPG
get rid of the timer reset. they both use the prescaler, so resetting the prescaler to get accurate timing on one timer mucks up the timing on the other timer. I'll probably eventually make everything use one timer.
was just experimenting to see how much difference this made- apparently too much!
jakepoz: "I'm seeing problems because of my drastically different Z and XY steps/mm I think. Z is 700 steps per mm, XY is 8. So, in GCODE I do a G1 that just moves the Z, and that works fine, but then the feedrates and acceleration constants are wrong for the next move, and it does maybe 1 tick per second for that whole move."
If you can reproduce that reliably, I'd very much like to get a copy of your sources - likely you have tweaked them to match your machine - to reproduce this here. Occasionally I see similar misbehaviours myself, but they're hard to reproduce or debug, as they usually don't survive an Arduino reset.
Regarding these pauses, I think I have found an issue: http://github.com/triffid/FiveD_on_Arduino/commit/f6f2b7f44f41850977319ab5c2fdf397217885f0
Please test :-)
Hi,
I am currently printing a new piece with your patch. It has succeeded where it used to misbehave, stopping for a second on short moves.
However, I'm seeing a different issue, when I backup/restart the extruder, I'm seeing similar 1 second pauses. It will stop, wait a second, backup the extruder, wait a second, move, restart it. It happens when the move without extrusion is a very short one.
Here is some sample GCODE:
;regular printing G1 X-11.08 Y-7.12 Z1.32 F1920.0 E0.378 G1 X-3.46 Y0.5 Z1.32 F1920.0 E8.42 ;backing up the extruder G1 F5700.0 G1 E-10.0 G1 F1920.0 M103 ;move without extusion (very small move) G1 X-3.56 Y-0.25 Z1.32 F1920.0 G1 F5700.0 G1 E12.0 G1 F1920.0 M101 ;Resume printing as normal G1 X-10.85 Y-7.54 Z1.32 F1920.0 E8.055 G1 X-10.55 Y-7.89 Z1.32 F1920.0 E0.362
I'd need at least your machine.h, better all sources. Is that your "gen3" branch?
Yep, I'm running exactly the latest gen3 branch :)
I've just pushed http://github.com/triffid/FiveD_on_Arduino/commit/94e0cce89be8bf6913c9a1bafd312b14d51aaa2b , which has the potential to avoid unwanted delays. Please test.
When testing new features I recognized acceleration is no longer accurate for higher speeds. It's difficult to describe, but ramping up is fine and at about 80% of the end speed, speed jumps to that end speed immediately. At lower speed this happens unnoticed, but at 600 mm/min, which translates to 3200 steps/s here, one can hear that well. Not sure wether this also involves step losses, but it also prevents me from maxing out my stepper motors.
Whatever, I tracked it down to this commit: http://github.com/triffid/FiveD_on_Arduino/commit/92eb4c97cae2b4773f86e6ba666dd4cb3af6ca19 , more precisely the timer reset in line 107 (file timer.c). If I comment out this single line in the current version, everything works well again.
Probably there's a reason why this code in timer.c was introduced, so I'm holding back from just reverting the commit. Please enlighten me :-)