Endstop behaviour for non-cartesian coordinate systems

Last week was spent fine-tuning the endstop behaviour. With normal cartesian printers, triggering an endstop should cause the stepper motor to only be able to turn the other way. For H-belt, coreXY and Delta printers, the problem becomes a bit more complicated. Consider the case of H-belt where triggering the X min endstop should allow both steppers to go backwards, but not forward. On the other hand, triggering the Y min should allow one stepper (X) to only turn forward, while the other (Y) to turn backwards.

In Redeem this was solved by having the other PRU poll for changes to the endstop inputs, using a look-up table to determine the masking of each stepper motor and then publishing that mask to the first PRU which handles the stepping. The look-up table is specified in the config file. For MendelMax and Cupcake it looks like this:

# If one endstop is hit, which steppers and directions are masked.
# The mask is 0b00<Z+><Y+><X+><Z-><Y-><X->
lookup_mask_X1 = 0b00000001
lookup_mask_Y1 = 0b00000010
lookup_mask_Z1 = 0b00000100
lookup_mask_X2 = 0b00001000
lookup_mask_Y2 = 0b00010000
lookup_mask_Z2 = 0b00100000

While for Thing which is an H-type belt system, it looks like this:

lookup_mask_X1 = 0b00001010
lookup_mask_Y1 = 0b00011000
lookup_mask_Z1 = 0b00000100
lookup_mask_X2 = 0b00010001
lookup_mask_Y2 = 0b00000011
lookup_mask_Z2 = 0b00100000

Since the second PRU is used for decifering this, no toll is taken on either the stepping PRU or the main CPU. In addition, if you happen to switch endstop X1 and X2 during installation and you are too lazy to get to the electronics (it might not be very accessible), you can simply change it in config.