Testing/calibration routine in firmware?

[lampmaker 0]

Let's discuss the possibilities of adding a routine in the firmware that detects the maximum possible speed & acceleration (& others?) of the ultimakers.

- What should it do?

- How should it be implemented

I like the idea of the system running a certain pattern at increasing speeds & accelerations and checking if steps are lost by going back to the limit switches and see if they're at the same position.

- I'm not sure if we need the DEBUG_STEPS sections to check whether steps are lost, or if there is some other way.

- probably also some margin of error for the switches is needed. They might not be accurate enough to detect single steps lost.

- What kind of patterns should be used?

- at what level should the patterns be injected into the system? As Gcode strings or directly into the block buffer?

[mr_seeker 0]

How I was thinking the calibration:

It could be a certain routine that you can implement. Something that when a certain M-code is inserted, the machine tries to forfill its routine and spits out the maximum values.

For testing, I would recommend using the increasing speed, until you start missing steps, after which you gradually speed down until you find the limit. For the limit I would recommend using a nominal value and its limits. Is the nominal value different than normal, or does it peak out its limit, then its a missed step. What also could be possible (and I think you can do it too) is using the endstops as an electrical switch using 2 pieces of foil/wire. As soon as they touch, they conduct electricity, and even though the switch hasnt been fully pressed the wires will still be connected.

[bkubicek 0]

Testing for a valid max-velocity for a given acceleration is not enought. We also need to test for the ability to do jerk-velocity jumps.

I would recommend the following: homing to a corner. doing quasi-half-circles (small line segments, with the abs(delta velocity)==vxyjerk) from the corner until you hit the axis which has the center on it again. Then back.

Also, I would opt for a binary search. And, acceleration should be set.

However, I am curently more on the idea of EvdZ. He proposed to do this on the host side. The firmware should sent back the location where the end-stop is triggered. Then the host-software could take over that and do choices for further analysis.

[misguided 0]

However, I am curently more on the idea of EvdZ. He proposed to do this on the host side. The firmware should sent back the location where the end-stop is triggered. Then the host-software could take over that and do choices for further analysis.

I've been working on a PID calibration routine in the firmware (getting close to getting something usable) and since you've mentioned that, I'm thinking if maybe this should be on the host side as well...

Only extra thing that's required is for the host to be able to set the controller output (actual value of the analog output, not the target temperature) to determine the initial tuning constants. Not sure if we've got that on Marlin... setting the controller to open loop might do it, but then the way it's implemented at the moment requires you to reflash your firmware, calibrate, then flash back to PID enabled.

Anyway, I'll continue on the PID calibration in firmware since I'm close to a first release.