When starting to print from a .gcode file, normally the printer gets set to use absolute position for the XYZ movements (G90) but when sending manual GCODE commands from the UI/front-end WebApp it is expected to use relative movement (G91) to avoid caching of the printer XYZ coords.
Possible solution1: Start caching the printer XYZ coords or request this data before making the initial absolute movement (whenever user switches from print from .gcode file to UI printer manual control)
Possibel solution2: Printer gets initialised with G91, every time the user requests to print .gcode file, the prior UI printer manual control command requires to send a mandatory G91 code. If parallel commands are allowed when printing from .gcode file, then this will raise and additional problem of switching from relative to absolute position (don't think that manual movement gcode commands will be allowed while printing from file - may ruin the printing job)
When starting to print from a .gcode file, normally the printer gets set to use absolute position for the XYZ movements (G90) but when sending manual GCODE commands from the UI/front-end WebApp it is expected to use relative movement (G91) to avoid caching of the printer XYZ coords.
Possible solution1: Start caching the printer XYZ coords or request this data before making the initial absolute movement (whenever user switches from print from .gcode file to UI printer manual control)
Possibel solution2: Printer gets initialised with G91, every time the user requests to print .gcode file, the prior UI printer manual control command requires to send a mandatory G91 code. If parallel commands are allowed when printing from .gcode file, then this will raise and additional problem of switching from relative to absolute position (don't think that manual movement gcode commands will be allowed while printing from file - may ruin the printing job)