Solved Release 2.02RC5 issue: resume: drivesRelative and axesRelative

[resam]

Maybe not a new issue, but related to the recent discussion around resume.g:

gb.MachineState().drivesRelative and gb.MachineState().axesRelative should IMO be set to the state they were before pausing. SaveResumeInfo already does so by writing it to the resurrect file. RestorePoint needs new members to keep track of them.

Somewhere around here?
https://github.com/dc42/RepRapFirmware/blob/a15773859dabee6e88cce157f7c00d17e29171b4/src/GCodes/GCodes.cpp#L763

I suppose one could make a bigger argument about which machine settings / states should be restored, and which should not, e.g., relative/absolute movement sounds important to me, fan configuration and drive mappings probably not. etc.

We should at least document the list of actions and settings in the wiki...
@dc42 any thoughts on the grand scheme of things?

[dc42]

That's not necessary. Each input channel has its own absolute/relative state. When you resume the SD card print, it will revert to the absolute/relative state associated with the SD card input channel, which will be the same as when it was paused. Any G90/91 or M82/83 commands that you send from other channels while the print is paused will only affect commands sent form that channel.

[resam]

Sounds good - thanks for the explanation!