Z axis Full speed without ramp since RC3->RC5

[FalloutBe]

When moving the Z axis 10mm, I can clearly hear a rampup happening. When moving it 100mm, there is no ramp time at all?! There is also no ramp when homing the Z axis.

To reproduce, I suggest simply decreasing your acceleration a lot so that you can clearly distinguish between ramp or no ramp by listening to the sound (or looking at the movement).

This happens since I updated from 1.1 RC3 to RC5.

[thinkyhead]

How fast does your Z axis move at top speed?

[FalloutBe]

40mm/s
I also tried this at 10mm/s and the same happened.

[jbrazio]

Which printer do you have ?

[FalloutBe]

A custom built one, ramps 1.4

[jbrazio]

But do you suspect the robot is losing steps after a 100mm move ? Or you're just noticing that no ramp up/down happens on longer moves ?

[FalloutBe]

Well yes, it's not about losing steps, I can just clearly hear and see that there is no ramp on the longer moves. Really strange

[Pmant]

I'm not sure if I'm experiencing the same bug but I also can't hear/see any ramp when doing a g28.

[jbrazio]

@thinkyhead did some modification to the acceleration code for RC4/5, let's wait for his feedback.

[thinkyhead]

Try undoing this change if you think it might be involved: 614feba

Two main changes happened there:

1. long bsx became unsigned long bsx
2. Acceleration steps are limited differently, according to code from Ultimaker.

Compare with https://github.com/Ultimaker/Marlin/pull/7/files and perhaps try their version of the code to see if some nuance was missed in translation.

[Daemonentreiber]

I got a similar problem after updating from RC3 to RC5.
When homing the Z-axis just stutters and doesnt move.
Moving the Z-axis "manually" (with the lcd controller) works.
Same on RC4 and the latest RCBugfix. Switching back to RC3 and everything works fine.

[thinkyhead]

@Daemonentreiber It sounds like your Z axis might be trying to move too fast. This could be due to a new bug, or it might be due to fixing a bug. What are your configuration settings for these options?

• MANUAL_FEEDRATE
• HOMING_FEEDRATE
• DEFAULT_MAX_FEEDRATE

[thinkyhead]

If anyone feels like reverting the changes that I linked to above to see how it affects behavior, that would be helpful. I am not able to reproduce this issue with my hardware, so I need testers.

[Daemonentreiber]

• HOMING_FEEDRATE 3*60
• DEFAULT_MAX_FEEDRATE 3
• MANUAL_FEEDRATE 4*60

Undoing change 614feba seems to help.

[thinkyhead]

@Daemonentreiber Thanks for the feedback. What if you only change the unsigned long bsx back to long bsx? Is that enough to get better behavior, or do you also need to revert the rest of 614feba to get it to behave? And what if the code were more like the code that Ultimaker used? Or, maybe it would help in those calculations to make sure everything is cast to long values so there's no doubt that there are enough bits to handle the large multiplication products.

Note that Ultimaker calculates them like this:

if(((float)block->acceleration_st * (float)block->steps_x / (float)block->step_event_count) > axis_steps_per_sqr_second[X_AXIS])
  block->acceleration_st = axis_steps_per_sqr_second[X_AXIS] * (float)block->step_event_count/(float)block->steps_x;

The current Marlin is calculating them without float:

xsteps = axis_steps_per_sqr_second[X_AXIS];
if (xsteps < (acc_st * bsx) / allsteps) acc_st = (xsteps * allsteps) / bsx;

An earlier version of Marlin calculated them with float, but didn't apply the limit in the same way as Ultimaker:

xsteps = axis_steps_per_sqr_second[X_AXIS];
if ((float)acc_st * bsx / block->step_event_count > xsteps) acc_st = xsteps;

A mashup of Ultimaker with current Marlin might behave differently:

if (((float)acc_st * (float)bsx / (float)allsteps) > xsteps) acc_st = xsteps * (float)allsteps / (float)bsx;
if (((float)acc_st * (float)bsy / (float)allsteps) > ysteps) acc_st = ysteps * (float)allsteps / (float)bsy;
if (((float)acc_st * (float)bsz / (float)allsteps) > zsteps) acc_st = zsteps * (float)allsteps / (float)bsz;
if (((float)acc_st * (float)bse / (float)allsteps) > esteps) acc_st = esteps * (float)allsteps / (float)bse;

[Daemonentreiber]

Only changing the unsigned long bsx back to long bsx helps.

[thinkyhead]

Aha! Very interesting… I wonder if @FalloutBe can also confirm…?

[FalloutBe]

Thanks a lot for all your replies!
Maybe this weekend I'll have time to try this fix. I'll let you know then

[thinkyhead]

I thought of another thing you can try, which might work just as well. Change this line in planner.h…

  long steps[NUM_AXIS];                     // Step count along each axis

…to this instead…

  unsigned long steps[NUM_AXIS];            // Step count along each axis

…leaving unsigned long for bsx (as it is in the current code).

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.

[FalloutBe]

I'm wondering,
I thought the issue was confirmed but it is still marked as a 'potential bug'. Does that mean there is need for more proof, or more people who experience this problem?

[jbrazio]

It's also marked as inactive, we were waiting for you feedback.

[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.