Printer slows down a lot for long passes

jonawald

Hi there. I'm printing with a big (600mm) home made delta printer. Everything works as it should except that for long passes it slows down to a craw.

When its printing the infill and the travel distance between point a and point b are longer than about 100mm it print speed will slow down to almost nothing. Then, when it gets to a corner where the distance is shorter it will travel at a much faster pace. What is causing this?

I am using Slic3r and repetier 0.92.9 firmware.

I don't know if this is something slicer is doing or repetier.

Repetier

That is strange. Normally on long moves it should even be faster since it can optimize that better while in curved regions the planned path gets shorter and hence it might reduce speed.
Are the diagonals nearly flat at some point? In that case one axis must move very slow so that is a position area that should normally be avoided since there is no calculation for adjustment inside firmware. What can slow down is if the timer misses the time then it takes one full cycle which would be a slowdown in 8 bit AVR. With a due it would be a 4 minute wait.
So one question is which processor/board are you using here?
Also is upgrading to latest dev version an option. Can't remember if there were any bugs I fixed in the last 2-3 years.

jonawald

I'm using ramps 1.4/Arduino Mega board. I tried upgrading to the latest dev. version last week, but for some reason it failed to upload to the arduino. I tried re-downloading it a few times to make sure it wasn't corrupted, but no go. So I went back to previous version, and downloaded a fresh copy. It uploaded flawlessly.

I'm doing big prints, over 1Kg parts this slowness really extends print time.

By diagonals, I'm guessing you mean printing directly away from an axis tower? I'd have to check. But that wouldn't account for the huge increase in speed as soon as the lines get shorter.

jonawald

I was just able to check. The long passes are slow no matter in what direction they happen.

Repetier

Uploading dev is same software as for 0.92. As I understand it compiles successfully but avrdude is failing somewhere? Otherwise check that text segment is less then 64kb - disable additional languages if you are above that.
Also make sure to reduce moves/subsegments so free ram is at least 1kb. V1 has a bit increased memory usage and this is critical for correct function.

What is your definition of slow here? Sounds like printing still works. I understood it that it went from 60mm/s to well below 1mm/s.

jonawald

<a rel="nofollow" target="blank">Repetier</a> said:

What is your definition of slow here? Sounds like printing still works. I understood it that it went from 60mm/s to well below 1mm/s.

Sometimes the slowdown is not that dramatic, depending on how long the run is.

https://photos.app.goo.gl/AxzJStGSbHoVGbJT8

Here is a video that I took. It shows some short runs then for or five long runs then short ones again.

Jonathan

Repetier

Ok that looks very regular and I see now what you mean. That is surely no error in interrupt or so missing anything. That is really just that a different feed rate is used for the long moves. So question is does slicer for some reason reduce this or is it in firmware.

Have you tried a simple only move without extrusion to see clearly if it is in firmware and at which distance it happens. Neat end of video I see infill with shorter lines being quicker.

If it is firmware next step is upgrading to dev version. That is the only one where I make any fixes at all. And with all the fixes I made already it might already be fixed without me remembering that.

jonawald

Ok I finally got that print finished and was able to explore some. Uploading the latest firmware changed nothing. I cannot find anything in slicer or repetier host that would slow travel down.

Do you have any suggestions where I could check for this problem? The video I showed shows some slowdown. Sometimes it is a lot slower than shown in the video clip.

Jonathan

Repetier

Difficult. First you should have some simple script
G1 X-100 Y0 F9000
G1 X100

to have a long move with defined speed below max speed. Compile firmware with
#define DEBUG_QUEUE_MOVE
and enable echo before doing the test
M111 S7

This will show lot of informations in log including commanded feedrate and fullSpeed - the maximum speed computed for that move. That would first show if it is the path planner with the slowdown or if reason happens later also planner wanted a fast move.