Enabling remote OctoPrint (HACs)

Yeah I’m using base Marlin to handle parking. You can configure your runout sequence (load length/speed, unload length/speed, purge, park position, etc) just like normal in configuration_adv under advanced pause settings.
Runout, pause, and m600 files are heavily modified to make this work though, but I believe I’m doing it in a way that won’t break anything when printing from HMI.

I created a is_hmi_printing flag to keep the code necessary for hmi printing functions like power loss recovery and their pause method system_statue_pausing. The flag is set to false by default and set to true in printcontrol::start since that is only used by hmi prints.

I fixed the bugs mentioned in my last post. Trying to figure out my latest issue now. Extruder pauses, parks, and sends prompt as expected. My heater timeout is set to 5 minutes, so I wait for that to occur (for testing), but I can’t get the heater to reheat after the timeout.
I’ve set it up so the “filament runout detected - insert filament” prompt is closed and replaced by a “heater timed out. Reheat?” Prompt after the timeout period. Clicking the reheat button on the prompt should reset the target temp, and it does, but heater doesn’t actually begin heating again, and you get stuck in a pause with no way to proceed or cancel. It shows the target temp has been set, but it doesn’t heat up. Gonna troubleshoot that tonight. I’m sure there’s some safety feature in the temperature code that’s holding me out, or Marlin behavior while in a paused state could be holding me out.

3 Likes

Thanks so much for putting all the time and effort into this. The Octoprint limitations are really my only complaint with the J1. If they can be sorted out, this would probably be the top machine in my fleet. I just don’t have the programming expertise to be of much help, unfortunately.

1 Like

I really appreciate the work you’ve put in. The Octoprint (annd subsequent Obico) issues are really my biggest complaint with the J1. I know it’s a lot of work, but thank you for the effort!

1 Like

Thank @DLMCW if he pulls it across the finish line! He went the extra mile where I just didn’t want to. :sweat_smile:

Progress update: very close to being finished now.
I discovered what was holding me out before. Host action prompts rely on the emergency parser feature. When you click “continue” on the prompt, or “reheat”/“anything else the button is configured to say”, e_parser injects an M108 into the queue to break the wait loop and continue executing code. I had e_parser enabled, but the underlying code that allows e_parser to work was missing from the repo, so no M108 was being injected and I was stuck in a wait loop as I expected.

I killed two birds with one stone now by adding the code necessary for e_parser. We now have e_parser capability, and upon my last test, the runout sequence ran as expected. Print resumed after replacing filament, and it resumed in the correct spot exactly where it paused at. Perfect. Runout sensors for Octoprint officially work. I’m still working out bugs though because after the print resumed, I no longer had anything new showing in the Octoprint terminal. The gcode was still being sent to the printer, but none of it was being reflected in the terminal. I have an idea of what might be causing that behavior that I’ll work on later. It’s probably just missing a host action to change state from “resuming” to “resumed”. I made it runout again and I was also not receiving host action prompts any more, which made it impossible to handle the 2nd runout. I think it all stems from Octoprint itself being stuck in a “resuming” state and not having transitioned to “resumed”. Should be an easy fix.

My next update will be in a new thread, because I think my next update will be the finished product. It will still need more testing to see what happens when people print from HMI and experience runout. I’ll have to make sure none of the new code interferes with native HMI processes. It shouldn’t though because I put guards in place to isolate the different runout handling processes from each other. HMI prints should still perform just like always.

Anyway, here’s the new branch that I’m working from in case anyone wants to look at it. I reworked my previous implementation so that it’s all now standard Marlin processes and the relevant code is in the appropriate files that it would be found in for vanilla Marlin. That means you can also use other pause gcode instead of M600 if you want. You can use any runout_script (in configuration.h) that you want.

https://github.com/DLMCW/Snapmaker-J1-custom/tree/runout-for-octo

3 Likes

It’s finished. See new thread.

New thread for those seeking in future: