Number of steps does not match positon

[lampmaker]

Many people using marlin for ultimaker experienced skewed builds or missed steps. Some might be hardware related, but often the missed steps occur at odd places.

I made a branch that counts the steps right at the place where the output pins are activated.
https://github.com/lampmaker/Marlin/tree/skewtest

Using M114 (and after waiting for the last movement to stop), you can query the current_position[] values and the calculated position values, based on the steps forward and backward.

As it seems, there is sometimes a difference between the two position values. I've seen differences of 1mm and larger.

[ErikZalm]

Hallo,

Kun je mij dit probleem eens laten zien in de praktijk.
Nomaal gesproken zouden er met M114 geen stappen mogen missen. (Tenzij er iets mis gaat door de hoge snelheid die jullie gebruiken)

Ik zou graag eens zien hoe het in de praktijk gebruikt wordt. Dan kan ik een betere diagnose stellen.
Het liefste heb ik een stukje g-code van een paar regels waarmee het probleem gereproduceerd kan worden.

Groeten,

Erik

On Sep 12, 2011, at 10:05 PM, lampmaker wrote:

Many people using marlin for ultimaker experienced skewed builds or missed steps. Some might be hardware related, but often the missed steps occur at odd places.

I made a branch that counts the steps right at the place where the output pins are activated.
https://github.com/lampmaker/Marlin/tree/skewtest

Using M114 (and after waiting for the last movement to stop), you can query the current_position[] values and the calculated position values, based on the steps forward and backward.

As it seems, there is sometimes a difference between the two position values. I've seen differences of 1mm and larger.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7

[ErikZalm]

Hallo,

Ik heb nog even naar de code gekeken.
Ik vindt het erg vreemd dat M114 een andere waarde terug geeft. Deze code komt rechtstreeks uit sprinter.
M114 is nog niet goed geïmplementeerd en geeft momenteel de waarde die uit de g-code parser komt. Als hier wat anders uitkomt is dat erg vreemd.

Groeten,

Erik van der Zalm

On Sep 12, 2011, at 10:05 PM, lampmaker wrote:

Many people using marlin for ultimaker experienced skewed builds or missed steps. Some might be hardware related, but often the missed steps occur at odd places.

I made a branch that counts the steps right at the place where the output pins are activated.
https://github.com/lampmaker/Marlin/tree/skewtest

Using M114 (and after waiting for the last movement to stop), you can query the current_position[] values and the calculated position values, based on the steps forward and backward.

As it seems, there is sometimes a difference between the two position values. I've seen differences of 1mm and larger.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7

[bkubicek]

there is some rounding here:

plan_set_position(...)

and in

void plan_buffer_line(float x, float y, float z, float e, float feed_rate) {
line 1818

---

target[X_AXIS] = lround(x_axis_steps_per_unit[X_AXIS]);
target[Y_AXIS] = lround(y_axis_steps_per_unit[Y_AXIS]);
target[Z_AXIS] = lround(z_axis_steps_per_unit[Z_AXIS]);
target[E_AXIS] = lround(e_axis_steps_per_unit[E_AXIS]);

---

you could also try to insert some serial debugging code here, to see if the calculated steps are actually allright:

void calculate_trapezoid_for_block(block_t *block, float entry_speed, float exit_speed) {

...
// Calculate the size of Plateau of Nominal Rate.
long plateau_steps = block->step_event_count-accelerate_steps-decelerate_steps;
///insert here

...

it would be nice to circle this problem

also what could be a candidate:
in the interrupt routine there are a couple of " >0", which could be moved to a ">=":

if (counter_x > 0) {

e.g. line 2244 2251 ...

I think this is the most probable candidate, as far as I understand the other code was taken from grml and is hopefully tested.
ALL linenumbers refering to my (bkubicek) current git version..

greetings,
bernhard

[lampmaker]

Hi Erik,

I modified the M114 command so it also returns the position based on the counted steps.
However, I can't seem to reproduce (yet) what I've been doing yesterday.

I'll try Bernard's fork first and see if I have any issues there.

[lampmaker]

I may have a bit more insight. The print I was having troubles with had a hole with (too) many small segments. (36 segments on a 4mm diameter) While printing the circumference speed droped significantly and it sounded more like sprinter. Running a print now with hexagon instead of the hole, and everything is perfectly fine.
It could mean that marlin or the communication has a problem with a series of short segments. (36 segments would mean .34 mm per segment at F18000

[ErikZalm]

Als er te veel korte segmenten zijn dan kan de lookahead / serial interface het niet bij houden. Hij moet dan als het goed is terugvallen in een sprinter like mode.
Ik in de lookahead een tijdje terug een bug gevonden. Die zou hier van invloed kunnen zijn.

Ik moet bekijken of de seriele snelheid het probleem is. Of dat het probleem in de lookahead reken snelheid zit.

Welke baudrate gebruik je?

Groeten,

Erik

On Sep 13, 2011, at 10:28 AM, lampmaker wrote:

I may have a bit more insight. The print I was having troubles with had a hole with (too) many small segments. (36 segments on a 4mm diameter) While printing the circumference speed droped significantly and it sounded more like sprinter. Running a print now with hexagon instead of the hole, and everything is perfectly fine.
It could mean that marlin or the communication has a problem with a series of short segments. (36 segments would mean .34 mm per segment at F18000

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2079485

[lampmaker]

Baudrate is 115200
Kan de buffer ook verhoogd worden? Staat nu op 8. Kan die gewoon verhoogd worden of loop je dan tegen andere problemen aan?

[ahmetcemturan]

Have you tried increasing the precision on SFACT/Skeinforge?

[bkubicek]

google translage:
Erik:

If too many short segments, then the lookahead / serial interface is not in keeping. He must as well return to a sprinter
like fashion. I am in the lookahead a while back a bug. That would be this could affect. I have to see if the serial speed is
the problem. Or that the problem is the lookahead calculation speed. What baud rate do you use? Regards,
Lampmaker:
The buffer may also be increased? Is now 8. Can be increased or simply walk over to other problems?

Lampmaker: could you try to build the small test cube with no fill, and hex infill, and see if you have missed steps?
Maybe it only happens

• if there is a buffer underrun.
• or if there are no plateau steps, i.e. if the length of the move is smaller than the acceleration/deceleration distance.

[lampmaker]

Here is what I did today (in between "real" work)

• use Bernards latest version
• Added step counter to that one. results can be queried using M114, which
  shows the normal values for x,y and the step-counted values.
• printed a 10x10mm testblock with a 3mm hole, 36 segments.
• Played with the buffer size (std 8 vs 40). Does not seem to make a
  difference.
• Prints come out nicely skewed at default speed (150 print, 500 travel).
  Difference between x,y and counted x,y values: 1-2mm
• reduced speed to 25% with live controls. skew is less, difference between
  x,y and counted x,y values is ~ 200-500 microns.

So it might indeed be related to some buffer underrun. However, I still
don't think it should lose steps in that case.

On Tue, Sep 13, 2011 at 2:34 PM, bkubicek <
reply@reply.github.com>wrote:

google translage:
Erik:

If too many short segments, then the lookahead / serial interface is not
in keeping. He must as well return to a sprinter
like fashion. I am in the lookahead a while back a bug. That would be this
could affect. I have to see if the serial speed is
the problem. Or that the problem is the lookahead calculation speed. What
baud rate do you use? Regards,
Lampmaker:
The buffer may also be increased? Is now 8. Can be increased or simply
walk over to other problems?

Lampmaker: could you try to build the small test cube with no fill, and hex
infill, and see if you have missed steps?
Maybe it only happens

• if there is a buffer underrun.
• or if there are no plateau steps, i.e. if the length of the move is
  smaller than the acceleration/deceleration distance.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2081167

[ErikZalm]

Kan you send me the G-code and configuration.h file?

I will try to reproduce it.

What host are you using?

Best regards,

Erik van der Zalm

On Sep 13, 2011, at 7:21 PM, lampmaker wrote:

Here is what I did today (in between "real" work)

• use Bernards latest version
• Added step counter to that one. results can be queried using M114, which
  shows the normal values for x,y and the step-counted values.
• printed a 10x10mm testblock with a 3mm hole, 36 segments.
• Played with the buffer size (std 8 vs 40). Does not seem to make a
  difference.
• Prints come out nicely skewed at default speed (150 print, 500 travel).
  Difference between x,y and counted x,y values: 1-2mm
• reduced speed to 25% with live controls. skew is less, difference between
  x,y and counted x,y values is ~ 200-500 microns.

So it might indeed be related to some buffer underrun. However, I still
don't think it should lose steps in that case.

On Tue, Sep 13, 2011 at 2:34 PM, bkubicek <
reply@reply.github.com>wrote:

google translage:
Erik:

If too many short segments, then the lookahead / serial interface is not
in keeping. He must as well return to a sprinter
like fashion. I am in the lookahead a while back a bug. That would be this
could affect. I have to see if the serial speed is
the problem. Or that the problem is the lookahead calculation speed. What
baud rate do you use? Regards,
Lampmaker:
The buffer may also be increased? Is now 8. Can be increased or simply
walk over to other problems?

Lampmaker: could you try to build the small test cube with no fill, and hex
infill, and see if you have missed steps?
Maybe it only happens

• if there is a buffer underrun.
• or if there are no plateau steps, i.e. if the length of the move is
  smaller than the acceleration/deceleration distance.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2081167

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2084170

[bkubicek]

working on it right now as well:
https://github.com/bkubicek/Marlin/commits/
I made a gnuplot of all steps planned and taken for a converted midi file (airwolf) and compared in gnuplot. There were no missmatch between planned and taken steps. I will try testing with a hole example.

[lampmaker]

I did one very large & long print that came out perfectly fine. After that I
printed the small box with hole and it's completely messed up. All with
the same firmware.

M114 sends the position & count. Just make sure it is called after the last
motion has stopped.

On Tue, Sep 13, 2011 at 7:35 PM, bkubicek <
reply@reply.github.com>wrote:

working on it right now as well:
https://github.com/bkubicek/Marlin/commits/
I made a gnuplot of all steps planned and taken for a converted midi file
(airwolf) and compared in gnuplot. There were no missmatch between planned
and taken steps. I will try testing with a hole example.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2084354

[ErikZalm]

I don't see the attached files.

Can you also send the g-code which fails?

On Sep 13, 2011, at 7:56 PM, lampmaker wrote:

Attached is the configuration / pde files I used today

I did one very large & long print that came out perfectly fine. After that I
printed the small box with hole and it's completely messed up. All with
the same firmware.

M114 sends the position & count. Just make sure it is called after the last
motion has stopped.

On Tue, Sep 13, 2011 at 7:35 PM, bkubicek <
reply@reply.github.com>wrote:

working on it right now as well:
https://github.com/bkubicek/Marlin/commits/
I made a gnuplot of all steps planned and taken for a converted midi file
(airwolf) and compared in gnuplot. There were no missmatch between planned
and taken steps. I will try testing with a hole example.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2084354

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2084562

[bkubicek]

the 400 mm/sec testcase of short x-axis moves does not loose steps for me:
http://wiki.ultimaker.com/File:Testfiles.zip
I would expect that this is under the acceleration distance, and also would expect that it causes buffer underruns.
Tested with SD and serial, 115kbaud.

[bkubicek]

lampmaker, what acceleration are you using? And could you please mail a gcode file which exhibits the problems for you?

[lampmaker]

I've located the source of the problem: (https://groups.google.com/forum/#!topic/ultimaker/ySmcYrVZT8E)

when the block_buffer is emptied, steps are lost somewhere. Increasing the size of the block-buffer caused my problems for one print to go away

[bkubicek]

Idea: maybe the error is not in handling the next buffer block,that could be possibly empty buffer, but in the calculation of the block thereafter, since the old buffer did deaccelerate to 0 velocity?

[ErikZalm]

Hello,

I found a bug in the look ahead code. (A user with a RAMPS board found it.)
It was not working ok when the buffer is empty.

The error gives a speed step. This is probably causing the missing steps.

If fixed it in the non Ultimaker branches.

Best regards,

Erik

----- Original Message -----
From: "lampmaker" reply@reply.github.com
To: "ErikZalm" erik@vdzalm.eu
Sent: Friday, September 16, 2011 2:34:05 PM
Subject: Re: [Marlin] Number of steps does not match positon (#7)

I've located the source of the problem: (https://groups.google.com/forum/#!topic/ultimaker/ySmcYrVZT8E)

when the block_buffer is emptied, steps are lost somewhere. Increasing the size of the block-buffer caused my problems for one print to go away

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2114302

[lampmaker]

Either way, when the cause of the lost steps are found, we should still implement a feature to reduce speed when the buffer is starting to empty. Otherwise there will be blobs while it's waiting for new data.
I've implemented this in my fork https://github.com/lampmaker/Marlin/branches/skewtest
simply said: when the number of items in the buffer is below certain threshold, put a minimum on 'microseconds'. Do this progressively if the buffer still is emptying more..
This prevents the buffer from being emptied, thus no more lost steps. But we should still remove the cause for those...

if ((blockcount<=2)&&(microseconds<50000)) microseconds=50000;
else if ((blockcount<=4)&&(microseconds<20000)) microseconds=20000;
else if ((blockcount<=8)&&(microseconds<10000)) microseconds=10000;

[bkubicek]

awesome idea, lampmaker. However I think that a fixed time should only exist in the config.h.

I have already started merging Erik possible fix into my personal git, however, its not an easy merge, because of the other differences in the code.

[lampmaker]

Let me know when you're done, I'll add my stuff to it. I'll put the minimum
time in the config.h

On Fri, Sep 16, 2011 at 4:41 PM, bkubicek <
reply@reply.github.com>wrote:

awesome idea, lampmaker. However I think that a fixed time should only
exist in the config.h.

I have already started merging Erik possible fix into my personal git,
however, its not an easy merge, because of the other differences in the
code.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2115306

[bkubicek]

UltimakerErik has found something that obviously looks like a bug:
in plan_buffer_line:

if(abs(block->speed_x) > max_feedrate[X_AXIS]) {
//// [ErikDeBruijn] IS THIS THE BUG WE'RE LOOING FOR????
// it used to be just this line: speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
tmp_speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;
}
if(abs(block->speed_y) > max_feedrate[Y_AXIS]){
tmp_speed_factor = max_feedrate[Y_AXIS] / abs(block->speed_y);
if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;
}

[ErikZalm]

This is not a bug.

This is limiting the axis speed to the max feedrate.

It works as intended. (As far as I can tell)

This will not cause any speed steps.

Best regards,

erik

On Sep 16, 2011, at 6:50 PM, bkubicek wrote:

UltimakerErik has found something that obviously looks like a bug:
in plan_buffer_line:

if(abs(block->speed_x) > max_feedrate[X_AXIS]) {
//// [ErikDeBruijn] IS THIS THE BUG WE'RE LOOING FOR????
// it used to be just this line: speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
tmp_speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;
}
if(abs(block->speed_y) > max_feedrate[Y_AXIS]){
tmp_speed_factor = max_feedrate[Y_AXIS] / abs(block->speed_y);
if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;
}

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2116489

[bkubicek]

i think it is, in the original code the x axis is handled different. Maybe its a different bug, however... :

@@ -1875,7 +1892,10 @@ void plan_buffer_line(float x, float y, float z, float e, float feed_rate) {

   float speed_factor = 1;

   float tmp_speed_factor;

   if(abs(block->speed_x) > max_feedrate[X_AXIS]) {

-    speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);

+    //// [ErikDeBruijn] IS THIS THE BUG WE'RE LOOING FOR????

+    // it used to be just this line: speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);

+    tmp_speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);

+    if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;

   }

   if(abs(block->speed_y) > max_feedrate[Y_AXIS]){

     tmp_speed_factor = max_feedrate[Y_AXIS] / abs(block->speed_y); 

[ErikZalm]

This is not a bug!!!

It is handled different but it can be handled different because it is the fist axis we test.
After the first we need the temp var. This is not needed for the first.

On Sep 17, 2011, at 9:32 AM, bkubicek wrote:

i think it is, in the original code the x axis is handled different. Maybe its a different bug, however... :
@@ -1875,7 +1892,10 @@ void plan_buffer_line(float x, float y, float z, float e, float feed_rate) {

float speed_factor = 1;

float tmp_speed_factor;

if(abs(block->speed_x) > max_feedrate[X_AXIS]) {

• speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
• //// [ErikDeBruijn] IS THIS THE BUG WE'RE LOOING FOR????
• // it used to be just this line: speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
• tmp_speed_factor = max_feedrate[X_AXIS] / abs(block->speed_x);
• if(speed_factor > tmp_speed_factor) speed_factor = tmp_speed_factor;

}

if(abs(block->speed_y) > max_feedrate[Y_AXIS]){

tmp_speed_factor = max_feedrate[Y_AXIS] / abs(block->speed_y);

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/7#issuecomment-2121366

[bkubicek]

you are right. I have reverted this change in my code

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.