Enabling remote OctoPrint (HACs)

Snapmaker J1/J1s
1

This is to continue the discussion from here:

Looking at the source code:

To summarize, the initial question was fast tool changes via OctoPrint. I found that lines 246-250 of the Snapmaker-special M2000.cpp do a check of printer status to determine if the printer is printing. It looks like if that status isn’t set, it will refuse to do a fast tool change.

I would guess this is to prevent, for example, doing a tool change when both extruders are parked.

[EDIT: This does not happen if HACs are enabled. One needs to initiate the print_control to start and set the print status to printing. That doesn’t fix much else though.]

I’m having a look at this more closely now, @MarkA121 and @jbot , in parallel to trying to install a server directly on the main board. I’ll just barf my notes so far down below.

2 Likes
2

Take everything I say with a grain of salt as I just try to read the code and manuals and understand what’s going on. Would love to have some help. :sweat_smile:

From what I see, HACs enable external control of the printer as communicated back and forth with basic messages for things like stop, start, pause, filament runout, etc, between an outside host and the “LCD” screen. At first glance, you “simply” uncomment #define HOST_ACTION_COMMANDS in Configuration_adv.h and recompile Marlin.

There’s also HOST_PROMPT_SUPPORT which sure sounds nice to have. This lets the printer send prompts back to the host for interaction.

Now it likely isn’t that simple. There’s some assumption here about the logic that’s been programmed in the J1 screen firmware. Does it actually interact with HACs at all? For example, does it check what’s going on with the printer via HAC statuses before trying to do things like starting prints?

Naively trying to enable action commands and prompt support, I immediately get warnings while compiling. A few functions for host actions are not defined references in MarlinCore and the lcd object files.

I also notice HAS_FILAMENT_SENSOR to enable runout.h in host_actions.cpp is not defined as written. @Mechanikus and others have talked about this at great length: The J1 does not use a standard sensor. I’ll have to look more to see if runout is handled in the Marlin source, or if it’s managed by the screen.

So. I’ll see if these warnings can be cleaned up, but I dunno, man.

1 Like
3

Not an exciting first try!

I switched to only enabling HOST_ACTION_COMMANDS. This still threw one warning for a host kill reference.

Can still send a print via OctoPrint, but it skipped right over an M600 (filament change) command without stopping. Printing the same file from the screen pauses as usual.

So… not that simple.

Looking through the Marlin source though, there’s surprisingly more in it than I thought. The filament sensor ADC interpretation code is in there, and a bunch of the calibtration [sic] procedures, and a few other Snapmaker-special commands including screen- or mainboard-only restarts and stuff.

OctoPrint detects HACs are enabled. However, just turning on HACs does not enable full communication. Didn’t try a tool swap. Gotta poke around more, but as is, the screen isn’t listening when it isn’t what initiates printing?

1 Like
4

i cant recall for cure, but im at least halfway sure host action commands is related to the dummy display: rotary dial, button, digital screen style of an ender 3 or voron or whatever.

in 2020 i was recompiling marlin a lot to try and get some wanted features for the mainboard upgrade i did to my artillery x1. thats when i first became aware of the concept of feeding data back to the screen when controlling the printer via usb or octoprint. people were, as i recall, struggling to get some related features to work on the display because that had a simple touch display that didnt interact with marlin the same as the older style controllers did. as i recall btt had a very similar dual mode screen and people borrowed a lot of their code to make it halfway function right. klipper was also unable to display on it.

if im remembering correctly, and that function you are enabling is meant for a dummy display instead of a “smart display”, we may never see readout into the android app without the app being programmed to receive unprompted data from the marlin board, rather than polling marlin asking for status and it waiting for replies. i think this is also why 3d printer manufacturers started hooking (either physically or via software settings in marlin) the filament runout sensors directly to the touch screens rather than to the marlin boards.

i hope this is useful.

1 Like
5

That is! I kind of figured it was for simple text screens like old Prusas and Crealitys.

There’s quite a lot more in this custom firmware source yet though. More than I appreciated at first glance, like the runout code seeming to be on the main board side.

So I’ll keep poking around some more, but I’m sick at the moment and short on braincells. :sneezing_face:

1 Like
6

good luck and congratulations on getting this far.

7

Of interest though, even for a separate host, are that it looks some of the calibration functions and other things exist on the printer side, not the Android side.

I’m not sure how much without reading and mapping it all, but possibly some could be exposed for other hosts devices. Needs an interface still though.

(I dunno about you, but the XY calibration was a selling point for me and works well.)

1 Like
8

the calibration is nice and mine thankfully still is calibrated, since i lost access to that function after factory resetting the android screen. overall the printer is very nice and i am pleased with it. the bambu labs x1 series is similar in aesthetic and function and friendliness, but they have no idex. one thing that they have which we dont is a massive user base. thats why they get a custom open source firmware for their printer screen and we dont. but also i think they had an enabled function to allow root and the possibility of a custom firmware. which is what the j1 creators also wanted i believe.

if we had such a large community i think our problems would have been solved already lol. instead its only a few of us.

9

i will say this though: having an actual open firmware that can be adjusted or customized that way, with total access to the underlying operating system would definitely attract a user base that is underserved. the snapmaker people should think of this and take steps to assert dominance in the market this way before bambu labs makes an idex that has this feature.

2 Likes
10

Well, my stomach feeling there’s not much hope for that, judging from the past… the fact that Snapmaker took a really long time to finally release one (!) version of the J1 Marlin firmware (and only after users started to complain here since the original Jadelabo team had primised to make the printer Open Source) tells me that it does not seem to be their policy to make things open…

1 Like
11

So, yes. Looking through the Marlin source some more, as you said and as I feared, I don’t see any way to trigger a listening response from the screen app coming through a USB-wired OctoPrint server.

I started out just looking at how M600 works because I use filament pauses/changes. I’d have liked to have it kick back to the screen UI for that.

It all makes sense though. For any device that says “hey, a touchscreen UI would be cool” that’s using Marlin, how do you code Marlin so any touchscreen behaves the same way? The first, lazy answer is: It’s too hard, don’t even try. Then you end up with manufacturers spinning their own printing functionality into screen app/firmware.

So maybe there’s some way this could be made to work. I certainly think M2000 fast tool changes look OctoPrint-salvageable if that’s all someone wants, since they don’t appear to need screen interaction. But for anything else it’s pretty damn hard when you don’t have any information about the screen software. No APIs, no source. Nothin’.

For now this all looks dead on arrival, with my goal having been to preserve M600 as well.

1 Like
12

fast tool changes are critical as is enabling use of dual extruder prints. i found an octoprint plugin that should work with external filament sensors on pi via gpio. we can probably make a octo macro to simulate filament chang/pause parking. i need a new pi first

13

i may be able to grab some stuff from the android app later tho

14

I still think M2000 S200 may work if those few lines are uncommented.

I’m trying to think if the only important case captured by confirming it’s in print mode is to make sure they’re not both parked. Maybe a different check (like positions) would work instead, though that does not check extruder temps. Or maybe enabling HACs was already setting the flag it checks, though I didn’t test that.

Another check it does first is that the printing mode is not a duplication mode. Also wise, and also unsure how an external client gets handled.

15

Changed the title to enabling remote OctoPrint, not to be confused with doing so locally on the screen (though they’re certainly related).

1 Like
16

Hey @MarkA121 , I saw some comments from you on the OctoPrint forum and had a couple questions.

When using the front USB connection, everything works without conflict. When using Octoprint over the back USB connection, the print heads don’t always play nicely with each other.

Here, you mean printing using a USB memory stick? Or you mean you saw that connecting your OctoPrint server to the front USB port yielded a different response from the printer, when control using the OctoPrint server?

…my J1s has a “filament runout sensor”, but apparently it doesn’t do anything when the gcode has come in over the Octoprint connection.

This I meant to test for other reasons, but you’re saying if a job is running via OctoPrint and there’s no filament, there’s currently no detection/pause?

(These would be helpful things to me as I think a little bit about ways to test triggering the HMI from Marlin, if possible. I want to see if it’s a) the HMI is not listening which cannot be changed or, b) the main board is not speaking, which can be changed.)

17

Yes. I believe I was comparing gcode on a thumb drive, plugged into the front USB port, vs gcode coming from Octo thru the rear USB (B) port. I believe that another member tried connecting Octo to the front USB port, but it wouldn’t work.

…my J1s has a “filament runout sensor”, but apparently it doesn’t do anything when the gcode has come in over the Octoprint connection.

Yes. If the filament runs out during a print, Octo has no way of knowing that. It just continues the print, using air as the filament.

1 Like
18

Thanks.

Runout or pauses seem like good places to start. It’s clear there’s logic for initializing and checking the runout sensor in the Marlin firmware. But it’s also obviously not tied to the standard Marlin runout code, and having a hard time seeing where it’s then monitored and alarmed.

Since it monitors filament motion and not just a presence sensor, I guess it only works while extruding. Marlin (non-Snapmaker) base code only checks for filament presence? All that stuff is flagged off.

I was having a look in the Android “binary” apk after decompiling, but that’s much more of a labyrinth to me trying to find the business logic.It would help so much to understand what’s happening on the other side.

I’d really still like to see the screen react to OctoPrint: 1) stop/start job, 2) M600 pause, 3) filament runout and 4) M2000 S200 fast swap.

Anyway, thank you. That confirms runout isn’t picked up.

2 Likes
19

On the list of things to check, this thread for the SM2.0:

Wonder if the J1 was tricked in the same way or not. Triggering M600 filament change via a false runout (which we know is not detected under OP).

It did not look that way to me, but check again.

20

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. :confused:

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?