Fix M909 (set microstepping) and M92 (set steps per mm)

[ThatWileyGuy]

• remove Printer.steps_pr_meter because it's redundant with Stepper.microsteps
• remove callback from Stepper to Printer to update steps_pr_meter
• remove redundant microstepping bounds check from M909 - the Steppers can do this themselves
• add microstepping bounds check to B-series Steppers to match the A-series
• update steps per mm in M92 correctly (instead of restarting the path planner, which doesn't help)
• add tests for M909 and M92
• revise PathPlanner::setAxisStepsPerMeter to preserve the current location of the printer

Validated on the hardware - you can now change microstepping settings without losing printer positioning.

If no one objects I'd like to take an IOU on test coverage for the PathPlanner bits - that interface is about to be significantly refactored anyway to make probing more flexible.

Fixes #188

[Wackerbarth]

One thing that is significantly missing is a descriptive behavior of just what "preserve the current location of the printer" means. In particular, which coordinate system is maintained? The coordinate system is defined by the combination of its origin and the unit distance. Possible origins include the endstops, the bed, the workpiece, and the nozzle. The units might be in terms of meters, steps, or micro-steps.

[ThatWileyGuy]

The "world position" is preserved - M114 will print the same result before and after.

This makes perfect sense for M909 - you can move 20mm with one microstep setting, then move 20mm with another microstep setting and expect that you've definitely moved 40mm total. It makes less sense for M92, but there isn't a simple strategy that will sensibly work for M92 as far as I'm aware. The best thing to do would probably be to preserve "steps from the endstops," but that would require us to know which end of the axes the endstops are on. The path planner doesn't currently know that.

[Wackerbarth]

I think that there may be an issue in changing these parameters "on-the-fly". If you change the "steps_per_mm" for a physical axis, doesn't that imply that the perceived position changed because it now takes a different number of steps to return to the origin?

[goeland86]

The number of steps yes, but the position not necessarily. You have occasionally similar behavior on a lathe, where you can engage different ratios for the drive mechanism, where your advance rate is different in two different sections, however your position did not get modified as a result of that change...

Unless you're internally using step counts to keep track of position I don't foresee a problem?

[Wackerbarth]

But we ARE using (scaled) step counts. That is the only mechanism that the printer, by itself, and use to measure. The difficulty is that "position" is stored as a number in some kind of units.

There is no issue when you change the micro-stepping mode. In that case, it is like changing gears in a transmission. You are able to change both the physical mechanism and the numeric value at the same time. It's like changing the step size from millimeters to inches. If my mechanism starts at some origin, the position is zero, in either set of units. Let's choose "inches". If I move ten steps of 1 inch, my position will be "10". And that is 0.254 meters. Thus when I change back to metric, and return 25 steps of 10mm, I am, and know that I am, still 4 steps of 1mm away from the starting point.

However, let's assume that when you change the "steps-per-", then I no longer know where I am unless I am physically at the origin when I make the change. There are three points of interest: The current position of the actuator, the origin for that axis, and the "endstop" position that we used to align the scale. I have no way to know which of those is assigned the correct value in the new scale. two of them need to be adjusted. But which two?

[goeland86]

Wait, backup. If you know where you are, whether in steps or actual distance, the enstop location doesn't actually matter. Sure you may need to convert the number of steps until you reach your reference (be it endstop or axis zero) to stay coherent with regards to your current position.

But your configuration defines which way to go for an endstop, the endstop offsets tell you where you are with regards to the origin of that axis, and so ultimately, it's just a matter of translating your existing reference to the new one... There's no need to adjust the endstop position relative to that axis as that is a constant provided to you by the configuration file. And in any case, when homing, as long as you don't trigger, you keep going.

[Wackerbarth]

@goeland86 -- No, that IS the problem. Remember that the only thing that the printer can do is count steps. Therefore, physically, there is some number of steps from the endstop to the origin, and some number of steps from the endstop to the "current" position. All that the printer "knows" is the latter. If we change the length of a step, then since we have changed the units in which we count, either the claimed distance from one point to another changes OR the number of steps required to move that distance changes. Since we are not physically moving the current position, we must either change the distances between the endstop and the other two points OR we have to change the number of steps between them. If we change the distance, that physically moves the origin. If we change the number of steps, then that moves the current position. We have no way to distinguish which is correct.

[goeland86]

Therefore, physically, there is some number of steps from the endstop to the origin, and some number of steps from the endstop to the "current" position. All that the printer "knows" is the latter Really? We're building this super-duper firmware and we're still just counting steps in Python when we change step mode? And even if we were, unless a move is happening at the same time as we're changing the number of steps in memory, the only possible error you'll get is numerical rounding errors.

[Wackerbarth]

No, NOT STEP MODE. We handle that by changing the physical response of the system and the "math" at the same time. The problem occurs when we change the length of a step (steps per mm). In that case, we are changing only the "math". There is no physical change to the physical motion. Hence the problem.

[goeland86]

Now I'm utterly confused. Whether you change step mode or step per mm you do this as an atomic action anyway, so you're dealing with a (temporarily) static system. Why is changing the math of the steps per mm making you innately lose your reference point, if you're doing this in a system not currently in motion? If we wanted to do this during motion, yes, I understand this will be impossible.

[Wackerbarth]

Yes, you are confused. Consider that we have a physical system which has steps of exactly 0.1mm. Now, to make my point clear, I'll measure all distances in a unit that I call a pinch. And let's assume that I had set my scale at 250 steps per pinch. Further, assume that specify my endstop to be at -1 pinch from the origin. I re-index the movement. The printer moves to the endstop and then 250 steps to reach the origin. I ask it to position to +1 pinch. Thus, the printer moves an additional 250 steps, a total of 500 steps from the endstop. I'm 2 pinch from the endstop.

Now, I realize that there is an error. My "pinch" is supposed to be an inch. That is 254 steps per inch. Therefore, I am not 2 inch from the endstop. But, where is the origin? Is it 254 steps away, or 250 steps, or 246? Any of these might be correct. Without further information, you cannot tell.

[goeland86]

So you're saying you can't access the previous step_per_mm value when you execute the change to be able to reliably execute your conversion? Because that's essentially the core of the issue. You travelled to 500 steps at 250 steps per pinch. That means you are at 2 pinches from the endstop. Then you want to change your step per pinch to 254. Assuming that your step per pinch was correct at 250 when you executed it, you know that 500 steps means 2 inches from endstop. You change something (change pully, tighten a belt, whatever), and now your setup is 254 step per pinch. So you can derive from 2 inches, at 254 step per pinch means I'm at 508 steps from the endstop.

If your step_per_mm is incorrect when you're moving, you need to obviously re-home to get your correct position. But imagine you have a gearbox on your axis to do fast then fine movements - both step values are exactly correct and, at least on the python side, known during the transition phase.

[Wackerbarth]

No, the point is that you didn't actually change anything physically. All that you have done is told the math to use some different conversion factor. If you attempt to move the 508 steps toward the endstop, you will still hit the stop at step 500. Thus, you are not actually where you though you were.

[Wackerbarth]

If you do have something like the switchable gearbox, then I contend that you must also have some additional instructions involved in the switchover. Those instructions would also be able to specify the proper position after the change.

[goeland86]

Or not. Perhaps you're using a servo signal to change gears, and m909 to then change step per mm. That would be my approach.

On Wed, 3 Apr 2019, 18:31 Richard Wackerbarth, notifications@github.com wrote:

If you do have something like the switchable gearbox, then I contend that you must also have some additional instructions involved in the switchover. Those instructions would also be able to specify the proper position after the change.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/intelligent-agent/redeem/pull/194#issuecomment-479563990, or mute the thread https://github.com/notifications/unsubscribe-auth/AQiOecErxC06aD3yHOXcDhqf1xNAtHYXks5vdNdMgaJpZM4cXJJy .

[Wackerbarth]

M909 changes step mode, not "stepsper". I'm talking about using M92 which changes those values.

In your example case, you have some instructions to activate the servo. For things to work, you would want to: (1) Bring the motion to a stop (2) Activate the servo (3) Wait for the servo to stop (4) Change the scaling factor then resume motion

I'm suggesting that you just add an instruction at the end of that to specify the desired current position (G92). You should be required to do either that or a G28 (or equivalent) before performing any instructions that depend on the printer knowing its position.

[goeland86]

My argument was that running M909 to change stepper mode during a print is fine - and you agree. Changing steps_per_mm means that you have to be at rest and aware of your exact position to do the same.

I would suggest that we either document in as big and bold as we can that changing steps per mm during a print is not a good idea, or enforce that when we do this, M909 actually forces a motion stop to effect the change.

[ThatWileyGuy]

This is silly.

Changing the microstepping mode and preserving the M114-reported position is simple and logical. Changing the steps per mm of an extruder and preserving the M114-reported position is simple and logical. Changing the steps per mm of a carriage/effector/bed axis and preserving the M114-reported position is simple and unlikely to cause harm, but not terribly useful.

All three of these are things we nominally already supported, but implemented buggily. This change corrects those bugs.

Do you believe this PR is an improvement to the codebase?

[Wackerbarth]

@ThatWileyGuy -- I agree with most of what you have said. The first statement is true. The second statement is reasonable only because with extruders, usually, we don't care about "position", but only "relative distances". In the third statement, although you don't explicitly state it, by your use of "not terribly useful", I believe that you understand that the operation actually places the machine in an inconsistent state. That leaves us with "unlikely to cause harm". Although I cannot say that that is untrue, neither am I convinced that it is true. I would be much more comfortable if M92 left the affected axes in a "requires homing" state such as we should have during the startup phase of operation.

[ThatWileyGuy]

Right now the options are to preserve position or set position to all 0. Would it make you happier if I went with all 0?

[Wackerbarth]

No. But we need to document the fact that the global position is no longer valid until a future instruction re-establishes the value. And, as an enhancement, make that condition a part of the state and issue error messages if the user fails to follow with appropriate adjusting instructions. One thing that we will need to do as a part of configuration is to distinguish nozzle positioning steppers from those that feed filament.

[Wackerbarth]

Incorporated in PR #201