Fixes for endstop errors #14 and SD card behavior #34

[darylbond]

This fix stops redeem from crashing when a soft endstop is hit, addresses issue #14. Also addresses problems with SD card printing, see issue #34.

14

• Problem: It was assumed that PruInterface.get_endstop_triggered() would return a sensible number for indexing into a list of axes whenever AlarmWrapper was called. This was not the case when a soft endstop was hit and so redeem would go down with a cryptic error message from swig.
• Fix: Check if we have a soft endstop hit and skip the PRU interrogation if it isn't necessary. Also included some bounds checking on the indexing that is derived from the PRU endstop status.

Additional: Implemented checking that a move has actually been added to the move queue before the corresponding path overwrites the previous last path. If this is not done the ideal state of the machine is incorrectly updated while the actual state (taken from the native planner) is not.

[darylbond]

These latest commits address #34

The biggest problem was that pausing the SD print, with M25, suspended the path planner. When OctoPrint cancels a print it first pauses via M25 and then waits to finish with M400. It never restarts the queue. Thus OctoPrint thinks that Redeem is down as it is no longer responding to commands. My changes were to make pause independent of the PathPlanner so this issue is avoided.

[goeland86]

I've tested the SD card functionality and it works on the Monster Kossel. I haven't fully pushed the envelope of pause/resume/break yet, but the fact that it's listing the SD files looks like the rest should be a walk through.

I can't comment on the endstop issue from my end though.

[darylbond]

@ThatWileyGuy That change makes total sense, not sure how I missed it.