A little progress this morning.
Looking over the code, the main issue seems to be syncing up print_control when the print isn’t initiated from the screen.
At first I looked at editing host_actions.cpp to include setting the print status (using Snapmaker’s print_control) in addition to issuing the host action. OctoPrint doesn’t issue host actions though. It just starts printing.
So… that sucks.
To see if I was even on the right track, I instead modified M110. OctoPrint does issue an M110 N0
when it starts a print, to set the current progress to line zero.
I added the following code (after also including system.h and print_control.h):
if (parser.value_long() == 0) {
planner.synchronize();
print_control.start();
}
Theoretically this should check for a line reset, then if the print status is not “started,” start the service.
With this change, M2000 S200 tool swap worked via OctoPrint! However, M600 did not work correctly. And when M600 happens before a tool swap, the tool swap then gets screwed up and out of sync too.
I’m not sure the HMI actually picked anything up since print_control seems to run on the main board side. There’s also this SACP (Snapmaker action command protocol) stuff in snapmaker/event that actually sends command to the HMI. Not a lot of references to it elsewhere though, so it’s not very obvious where/when to trigger it. I’d kind of expect print_control to already be managing it, but the assumption might be that the commands are all coming from the HMI, so why bother echoing back that a print started?
All to say, why the heck isn’t start/stop/etc managed centrally regardless of source? This isn’t all on the HMI. OctoPrint doesn’t (does it?) announce requests to stop/start jobs and just starts piping in gcode.
Will I actually bother to hack together some attempt to synchronize these things?