Fix acceleration limits, when axes have differing requirements.

[illuminarti]

When moving in x, y and z all at the same time, the planner tries to blend the accelerations so no axis exceeds its max acceleration; it does this taking into account the proportional number of steps used on each axis... however, when it finds the limit has been exceeded, it simply uses the raw acceleration value, not the proportional value used in the test.

This same logic also needs fixing in the UM2 firmware - looks like its around like 780 in planner.cpp

[CCS86]

Is this bug responsible for losing steps when trying to move multiple axes very quickly? I am suffering that right now.

These changes don't seem to be implemented in the latest firmware branch for the UMO + heated bed kit.

[CCS86]

I went ahead and modified my planner.cpp file with Illuminarti's modifications, and while it seems to have improved the situation slightly, the issue remains:

When trying to move all axes together, there seems to be an error in the accel/jerk calculations that causes Marlin to move some axis above the programmed accel/jerk maximums. The result is skipped steps.

We have been discussing it in this thread: https://ultimaker.com/en/community/view/16176-jumping-belts-when-print-finishes

[thinkyhead]

Do you still like the changes suggested in this PR? As we're trying to get bugs cleared up for the next RC and final 1.1.0 release, it would be good to know whether this patch is needed or not. Nobody likes missed steps.

[CCS86]

I just don't think those changes that I applied made much of a difference. I still notice the bug. Mainly at the end of a print, when there is a simultaneous move of all axes.

[thinkyhead]

@CCS86 I suppose one could get scientific about it, somehow log all the block and step activity, print it out, etc. But of course there's just no way. The RAM is too small, the stepper ISR already close to limits… So maybe an easier approach is to simply examine the acceleration code in a few other firmwares — aprinter, Sprinter, Repetier-firmware, etc. — and see how they approach this. Also, I wonder if this couldn't be caused by the stepper ISR taking too much time so that faster moves lose some steps as a consequence…? I know we should probably do more optimization of the stepper ISR anyway.

[daid]

@thinkyhead I can run the whole firmware as x86 process. Logging wouldn't be hard from that :-)

Note, I think this pull request is fine, it looks good. It makes sense. But out of fear of regressions I didn't merge it to the Ultimaker fork. (As we're no longer focusing on the Ultimaker Original, a regression could be unnoticed by us for quite a while)

[thinkyhead]

I can run the whole firmware as x86 process. Logging wouldn't be hard from that :-)

Oh hey, nice! You don't actually have a virtual 3D printer simulator, do you?

a regression could be unnoticed by us for quite a while

Once it's in the release candidate, we'll find out quick!

[daid]

@thinkyhead https://github.com/Ultimaker/Ultimaker2Marlin/tree/master/MarlinSimulator
Yes I do.

[thinkyhead]

Yes I do.

Wow. Based on SDL too. Verrry interesting.

I've been working on a couple of graphical 3D printer simulators. A Deltabot simulator in Javascript (THREE.js), and a more generalized simulator in Unity3D. For the general simulator, so far I've modeled a Prusa i3, but I'm making it so that printers will be hot-pluggable, so it will be able to load and simulate any model. The pluggable printers will also be parametric, so they could include a few different bed sizes or heights, for example. I'd like to simulate everything right down to the individual stepper pulses.