Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

M876 not being force-sent while printing #3699

Closed
ZhuDaHai opened this issue Aug 22, 2020 · 42 comments
Closed

M876 not being force-sent while printing #3699

ZhuDaHai opened this issue Aug 22, 2020 · 42 comments
Labels
approved Issue has been approved by the bot or manually for further processing bug Issue describes a bug done Done but not yet released
Milestone

Comments

@ZhuDaHai
Copy link

ZhuDaHai commented Aug 22, 2020

What were you doing?

  1. Embed M600 gCode command on layer 51 of my 100 layer print
  2. Print gCode file with OctoPrint
  3. Printer reaches Layer 51 and executes the M600 command by pausing the print, parking the head and retracting the filament
  4. OctoPrint prompts with a 'Print Paused' popup with a 'Dismiss' button
  5. I insert a new roll of filament and click on 'Dismiss' - nothing happens
  6. A short time later a new popup appears: "Print Head Heater Timeout" with a REHEAT button.
  7. I press the REHEAT Button and nothing happens, the hot-end continues to cool down.
  8. At this point, I cannot do anything
    A) The main Printing button is depressed
    B) The Pause button is disabled
    C) the Cancel button is disabled
    D) The State is Pausing
    E) No controls on the Control Tab are enabled
  9. My only recourse is to shut off the printer and start it again - aborting the print entirely

I am using OctoPrint version 1.4.2
OctoPi version 0.17.0
Marlin 2.0.6 from the MakerBase fork of Marlin, as support for the MKS SGENL V2.0 mainboard is not yet integrated into Marlin's release branch (there is a pull request for it, but its not made it into a release as of 2.0.6 of Marlin)

I have check all closed Issues in Marlin for anything related to M600 support, and even the latest fix #18565 (Broadcast Host Actions) is integrated in my Marlin Release, including all the closed issues.

There are no current open issues in Marlin related to M600 and Host Commands

In Marlin configuration_adv.h, i have enabled these lines to enable Host Actions and Host Prompt Support:

#define HOST_ACTION_COMMANDS          // DaHai : Enabled for OctoPrint M600 Support
#if ENABLED(HOST_ACTION_COMMANDS)
  #define HOST_PROMPT_SUPPORT         // DaHai : Enabled for OctoPrint M600 Support
#endif 

What did you expect to happen?

I expected to behave as the M600 was written:

  1. Pause the print (works)
  2. Park the head (works)
  3. Retract the filament (works)
  4. Prompt user to insert new filament to the extruder motor (not working)
  5. Load the filament through the nozzle after user confirms filament is loaded (not working)
  6. Prompt use to choose 'Extrude More' (to further extrude the filament and clear the old color) or 'Continue' (to resume printing where it left off) (not working)

Basically, as I understand it M600 Host Action Commands and Host Prompt Support was implemented in Marlin for 'Smart' Host controllers, like OctoPrint, as it is stated on the RepRap Wiki found here and referenced in Marlin configuration_adv.h:

https://reprap.org/wiki/G-code#Action_commands

And that these commands allow smart host controllers to handle M600 Filament change commands just like dumb LCD displays, like the RepRap Discount Smart Controller with a text display and push button wheel.

What happened instead?

The Print Paused and the Head Parked and the Filament was unloaded, but none of the prompts appearing in OctoPrint allowed the new filament to be extruded or the print to be resumes (as described multiple times above)

Did the same happen when running OctoPrint in safe mode?

If I try this in Safe Mode, that disables all Plugins, including 'Action Command Notification Support' and 'Action Command Prompt Support', both by Gina Häußge, which is required for this to work. Both of these plugins are up-to-date and active.

Now, if that means I need to submit a bug report for those plugins, then I apologize and will do so.

Version of OctoPrint

OctoPrint version 1.4.2

Operating System running OctoPrint

OctoPi version 0.17.0

Printer model & used firmware incl. version

JGMaker A6 running Marlin 2.0.6 MakerBase fork for the MKS SGENL V2.0 mainboard.

Browser and version of browser, operating system running browser

Chrome v84.0.4147.137

Link to octoprint.log

https://drive.google.com/file/d/1Tk9ueh6iqRkbmMe2Z2F3h78-OGJ9AsBw/view?usp=sharing

Link to contents of terminal tab or serial.log

And the Terminal tab just shows:

Recv: echo:busy: paused for user
Recv: echo:busy: paused for user
[...]
Recv: echo:busy: paused for user
[...]
Recv: echo:Press button to heat nozzle
Recv: echo:busy: paused for user
[...]

Link to contents of Javascript console in the browser

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

P.S. Updated the Google Drive link so anyone can use it. Sorry!

@ZhuDaHai
Copy link
Author

FYI: This is a BUG report follow up to my Feature Request as from everything I have found and read thus far indicates this should be working and Marlin is fully up-to-date with no outstanding Issues related to this.

#3697

@GitIssueBot GitIssueBot added the triage This issue needs triage label Aug 22, 2020
@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 22, 2020

Here is a detailed sequence of events with screen shots and corresponding log file:

  1. M600 embeded in gCode at Layer 51
  2. Started print of gCode file
  3. At layer 51, Print Paused, Head Parked and Filament unloaded automatically
  4. Received this dialog from OctoPrint:
    Capture1
  5. Clicked on Dismiss
  6. Removed Filament Spool
  7. Inserted new spool and pushed filament past filament sensor and up to the extruder
  8. While doing 6 and 7 above, got this prompt from OctoPrint:
    Capture2
  9. Clicked on 'Reheat'
  10. Hot end continues to fall in temperature. Does not reheat:
    Capture3
  11. No Further dialog prompts from OctoPrint
  12. Control Tabs buttons are disabled:
    Capture4
  13. Terminal Tab only shows these messages (also linked to file on Google Drive below):
    Capture5
  14. After waiting 6 minutes, shut down OctoPrint and turned off printer - nothing else could be done at that point. Status still showing 'Pausing'. Print button still depressed, Pause and Cancel buttons still grayed out. No further notifications from OctoPrint:
    Capture6

Links to OctoPrint Log file of this test: https://drive.google.com/file/d/1JU-G3zcCujw1v2sovHdxDao0o69EFnno/view?usp=sharing
Link to Terminal Tab Output of this test: https://drive.google.com/file/d/1dsOGS_Bv1JmkZMtks2_a6-jPFjzgPOtW/view?usp=sharing

Let me know if you need anything further.

P.S. Updated links so anyone can use them...Sorry!

@jneilliii
Copy link
Contributor

I think it might be important to enable serial logging, restart octoprint and try the process again. You could of course move the M600 command to a different spot to avoid wasting a bunch of filament. Then share your serial.log, just in case there is something being reported back to octoprint that's not displayed in the terminal tab.

BTW, your google drive links are not public. You can actually drag your log files here into a comment to upload.

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 22, 2020

Its a small 20mm cube, but probably a waste of serial logging, so I set an M600 at layer 10.
Here's the serial log. Its interesting in that I see the messages coming from Marlin for Pausing, Parking and Reheating, but i never see anything being sent back by OctoPrint. Shouldn't I at least see a a response to Marlin to tell it to Reheat the nozzle?

serial.log.2020-08-22_13-38-47.log

P.S. Thanks for pointing out my goof on the Google Drive docs. I updated those links so they should be public now

@ZhuDaHai
Copy link
Author

So, just for grins, I tried it with OctoPrint in Safe Mode.
I thought it would just blow past the M600 commands as those are handled by Plugins, and Safe Mode is supposed to disable ALL plugins - or so I thought.
But it still paused, parked and unloaded the filament on layer 10 - just as before. And refused to do anything further.
So I guess the 'Action Command Notification Support' and Action Command Prompt Support' plugins are special as they are Bundled with OctoPrint so always enabled?

Anyway, here's the Serial Log of that non-event. Looks the same as when OctoPrint running in Normal Mode (not Safe Mode).
Hope it helps anyway.

serial.log.2020-08-22_14-18-00.log

@foosel
Copy link
Member

foosel commented Aug 22, 2020

The problem is that the printer signals to OctoPrint that it currently won't except commands as it's busy. In that scenario OctoPrint must not send commands to the printer as it could flood buffers. So your confirmation of the dialog gets enqueued but can never be sent as the emergency parser isn't enabled according to the firmware capabilities. Try enabling that in your firmware and test then. If it doesn't work then I'll look into it when I'm back from my break in early September.

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 22, 2020

Bummer. Still no joy. I enabled this in Marlin configuration_adv.h, compiled, uploaded and init-ed EEPROM and it still behaved the same:

#define EMERGENCY_PARSER // DaHai : Enabled to allow responses to M600 Action Requests

I will enable the serial logging and capture the results again and post them here. Hopefully it will provide more clues.

P.S. Enjoy your break.

@ZhuDaHai
Copy link
Author

Here's the serial log from the latest test.
I doubled-checked that I had 'Emergency Parser' enabled through M115:
Recv: Cap:EMERGENCY_PARSER:1

Still not working as described.
I don't see anything different in the logs, but then again, I don't know what exactly to look for...

serial (2) (1).log

Thanks for everyone's help!

@ZhuDaHai
Copy link
Author

Am I supposed to add M601 and M602 to the Emergency Commands list in the 'Serial Connection Octoprint settings???

@ZhuDaHai
Copy link
Author

This is driving me batty. I can't figure out why its not working.
I've look through the Action Command Prompt and the Action Command Notification plugin source and I can't figure out why its not sending back an 'M876'

In the Action Command Prompt Settings in OctoPrint:

  1. M876 set in Dialog Command.
  2. Enable Support: 'If detected' and 'Always' have been tried
  3. 'Enable force sending' is checked
  4. 'Enable signaling' is checked

In the dialog boxes created on behalf of the //action:prompt_button that item is indexed with a '0'

My Printer reports:

Recv: Cap:EMERGENCY_PARSER:1
Recv: Cap:PROMPT_SUPPORT:1

OctoPrint Sends:
Send: M876 P1

To tell the printer it can handle M876 prompts.

The Action Command Prompt Plugin / _answer_prompt should be creating a M876 S0 command to be queued based on my clicking of the first and only button. and its gcode_queuing_handler should be force sending it to the printer as it is an M876 gcode command.

What am I missing?!?!?

@jneilliii
Copy link
Contributor

jneilliii commented Aug 23, 2020

I think this PR might fix this issue? Looking at the current Marlin 2.0.6 release it appears the change was included, but not sure if that change made it into your specific fork or not.

MarlinFirmware/Marlin#18785

@ZhuDaHai
Copy link
Author

I think this PR might fix this issue?

MarlinFirmware/Marlin#18785

I have that fix in my code. Just checked at it was there already:
Marlin/src/feature/pause.cpp

  #endif
  TERN_(HOST_PROMPT_SUPPORT, host_action_prompt_end());

  return true;

Plus, I don't have an LCD hooked up, and so can't dismissed the message on it instead of OctoPrint.

Thanks anyway! I do appreciate it!!

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 23, 2020

Best as I can determine at this point, OctoPrint won't send the M876 Sx because the printer is reporting busy

But I think it should send the M876 Sx because the state is actually busy: paused for user as it is waiting for the response from the action:prompt_ commands.

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 23, 2020

OK, so I disabled LCD everything in Marlin (my plan was to put in a hybrid LCD / Graphical Display, but currently have nothing attached anyway).

So, I disabled all display types in Marlin thinking that without a display to provide input from the M600 prompts, it might change the behavior over USB to OctoPrint and allow it to send M876 Sx commands in response to its Action Prompts.

Short Answer: No. Still broken

I captured a Serial Log, but there does not appear to be any differences from before.

So, again, I really think OctoPrint is supposed to send M876 Sx commands when the printer is giving a status of busy:paused for user - otherwise this cannot ever work.

Then again, I could be totally wrong and not have a clue what I'm talking about...(highly probable)

serial (2) (2).log

@ZhuDaHai
Copy link
Author

Ok, this is really odd:

I disabled the busy protocol in Marlin as Gina said OctoPrint would never send anything back to the printer if it was 'busy'.
But it still didn't work. No M876 commands were ever sent (attached is the serial log).

But I noticed I could send M108 commands to do things like Reheat the nozzle when it prompted me to do so.

But I could NOT send any M876 command myself through the Terminal Tab. OctoPrint just ate them.

So I added M876 to the Emergency Commands in Serial Connection -> Firmware & Protocol :

M112, M108, M410, M876

Saved, Rebooted, tried again.

Still would NOT let me send M876 commands from the Terminal Tab!

WTH is going on?

FYI: All the M108 commands you see in the serial Log are manually entered by ME. OctoPrint sent Nothing back:
serial.log.2020-08-23_17-54-32.log

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 23, 2020

And....IT WORKS!!!

But I not going to tell you what I did!
(Just Kidding)

https://docs.octoprint.org/en/master/bundledplugins/action_command_prompt.html

States:

If the user clicks the button, assuming a selection_command of M876 S{choice} is configured, OctoPrint will send back M876 S0 (0-based index).

Note that above that is states:

command: The command to send to the firmware on choice, defaults to M876.

So I assumed selection_command was the same as command and entered M876 S{choice} into that field of Printer Dialogs > Action Command Prompt Settings > Dialog Command

So, why would that field be defaulted to something that doesn't work?
As the documentation on the linked web page above states basically you must enter M876 S{choice} in order for it to work properly.

Further, in action_command_prompt > _init_.py

There is this function:

	def _answer_prompt(self, choice):
		if self._enable == "never" or (self._enable == "detected" and not self._cap_prompt_support):
			return

		self._close_prompt()
		if "{choice}" in self._command:
			self._printer.commands([self._command.format(choice=choice)])
		else:
			self._printer.commands(["{command} S{choice}".format(command=self._command,choice=choice)])

Which looks like if the {choice} strings is NOT in the self._command (which is read from the above Printer Dialogs), that if "{choice}" in self._command would fall through to the else and put it in anyway. But it doesn't

There's a bug in there somewhere, I'm just not smart enough to see it...

@ZhuDaHai
Copy link
Author

ZhuDaHai commented Aug 23, 2020

P.S. But ONLY if M876 is entered into the Serial Connection -> Firmware & protocol -> Emergency Commands:

M112, M108, M410, M876

Does not matter if the Busy protocol is enabled or not in Marlin.

Last serial log attached.

serial (3).log

Summary:
Serial Connection -> Firmware & protocol -> Emergency Commands: M112, M108, M410, M876
Printer Dialogs -> Advanced Options -> Dialog command: M876 S{choice}

@jneilliii
Copy link
Contributor

Printer Dialogs -> Advanced Options -> Dialog command: M876 {choice}

So this doesn't have the S in the M876 command, is that what made this work or is the S suppose to be there?

Based on the if statement above if the S isn't there, then {choice} would still be detected and the command would end up being M876 # (# representing the number of your choice) instead of M876 S#. I wonder if that was a change on the dialog prompt support in Marlin if that is the case. Looking through your last serial.log it appears that is does have the S in the command, but just wanted to verify.

I also find this part of your serial.log interesting.

2020-08-23 19:43:20,664 - Send: M876 S{choice} P1
(removed the bit in-between)
2020-08-23 19:43:20,689 - Recv: M876 Responding PROMPT_UNKNOWN STATE

It looks like it happened during startup and I'm wondering if the command being sent to the printer to tell it the host supports prompts is not correct in action command startup code maybe.

@ZhuDaHai
Copy link
Author

Printer Dialogs -> Advanced Options -> Dialog command: M876 {choice}

So this doesn't have the S in the M876 command, is that what made this work or is the S suppose to be there?

OUCH! My Bad that should have the 'S' in there. I updated my comment above to include that now. Sorry!

Printer Dialogs -> Advanced Options -> Dialog command: M876 S{choice}

Based on the if statement above if the S isn't there, then {choice} would still be detected and the command would end up being M876 # (# representing the number of your choice) instead of M876 S#. I wonder if that was a change on the dialog prompt support in Marlin if that is the case. Looking through your last serial.log it appears that is does have the S in the command, but just wanted to verify.

Thanks for finding that! So, yes, I needed to put M876 S{choice} in the dialog to make it work

I also find this part of your serial.log interesting.

2020-08-23 19:43:20,664 - Send: M876 S{choice} P1
(removed the bit in-between)
2020-08-23 19:43:20,689 - Recv: M876 Responding PROMPT_UNKNOWN STATE

It looks like it happened during startup and I'm wondering if the command being sent to the printer to tell it the host supports prompts is not correct in action command startup code maybe.

What should be sent to the printer is M876 P1
And if the dialog contained the original gCode of just M876 it would have sent the proper code. So the plugin is apparently just reading what's in that field and appending P1 to it and sending it to the printer.

So, yeah, the interesting part is that it appears the code is written such that if just M876 is in the dialog field it should detect that, append S{choice} and fill in {choice} with what the button ID the user selected on the pop-up. But that does not appear to be happening. So when I replace the dialog field with M876 S{choice} so that dialog responses would get sent, that inadvertently broke the initial command to tell the printer that OctoPi can handle firmware dialogs:

2020-08-23 19:43:20,664 - Send: M876 S{choice} P1
(removed the bit in-between)
2020-08-23 19:43:20,689 - Recv: M876 Responding PROMPT_UNKNOWN STATE

@foosel
Copy link
Member

foosel commented Sep 3, 2020

So problem appears to be twofold.

  1. Outdated documentation that's still referring to a no longer existing selection_command that had a different expected format including the choice parameter. That's an easy fix.
  2. Code supposed to create and send the actual selection command from the default of M876 apparently not properly working for some reason. I have managed to get a reproduction of that via a modified virtual printer so that I can debug on both ends, investigating.

@foosel foosel added bug Issue describes a bug and removed triage This issue needs triage labels Sep 3, 2020
@foosel foosel added this to the 1.5.0 milestone Sep 3, 2020
@foosel foosel changed the title M600 Not Working M876 not being force-sent while printing Sep 3, 2020
foosel added a commit that referenced this issue Sep 3, 2020
foosel added a commit that referenced this issue Sep 3, 2020
@foosel
Copy link
Member

foosel commented Sep 3, 2020

Fixed on maintenance, will be released with 1.5.0.

If you want, you can checkout the maintenance branch and give this a whirl. It should now work with the default setting of M876 as configured command (no S{choice} please, that's a left-over from an earlier iteration of the plugin before it supported the P parameter).

@foosel foosel added the done Done but not yet released label Sep 3, 2020
@ZhuDaHai
Copy link
Author

ZhuDaHai commented Sep 4, 2020

Thank you!!!

I will try it out soon! 👍👍👍

@foosel foosel added the approved Issue has been approved by the bot or manually for further processing label Oct 8, 2020
@GitIssueBot
Copy link

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/m600-in-octoprint-how-to/23349/10

@arut16
Copy link

arut16 commented Oct 21, 2020

@ZhuDaHai Think I have same issue as yours before. As you I did this changes :

Serial Connection -> Firmware & protocol -> Emergency Commands: M112, M108, M410, M876
Printer Dialogs -> Advanced Options -> Dialog command: M876 S{choice}

image
image

Do I need also uncomment this fonctions in marlin code ? Think yes but not sure now :

#define HOST_ACTION_COMMANDS          // DaHai : Enabled for OctoPrint M600 Support
#if ENABLED(HOST_ACTION_COMMANDS)
  #define HOST_PROMPT_SUPPORT         // DaHai : Enabled for OctoPrint M600 Support
#endif 

Is there a way to activate host_action_commands with a gcode/without recompile all Marlin code... ?

Thanks for your help !

@chrstrvs
Copy link

chrstrvs commented Nov 8, 2020

Hey all!

I'm having problems with M600 and Octoprint, which lead me to this thread.

I'm using Marlin 2.0.5.3 and I have HOST_ACTION_COMMANDS and HOST_PROMPT_SUPPORT enabled.
In Octoprint I downloaded Printer Dialogs, because that wasn't installed by default. In Dialog command I entered M876 S{choice}. In Emergency commands I have M112, M108, M410, M876.
Still nothing happens when I press the buttons that shows up. Did I miss anything?

I have a BTT TFT70 and sure, I could wire up the EXP1 and EXP2 and use the Marlin mode in the screen, but I'd rather not and it would be cool to get it to work.

Regards,
Christian

@cp2004
Copy link
Member

cp2004 commented Nov 8, 2020

It might be that you need to wait for the fix to be released in OctoPrint 1.5.0 (starting RC shortly) - I am not sure that it was working properly without the fixed implementation

@chrstrvs
Copy link

I have no problems with waiting, but I thought that if Da Hai was able to get it to work so would I.

@jneilliii
Copy link
Contributor

1.5.0rc1 is out, so you could change your release channel to maintenance RCs and then update to the new version and see.

@chrstrvs
Copy link

Yeah, I saw that. I'm going to upgrade and see if it works and hope the rc is stable enough for use.

@chrstrvs
Copy link

So I updated to 1.5.0rc1 and it still will not work. Maybe it has not been implemented yet or there is something that I am missing or have done wrong.

@cp2004
Copy link
Member

cp2004 commented Nov 14, 2020

@chrstrvs What is in the box of the dialog command to send? It should just be M876, no parameters.
I will test this with the virtual printer, to make sure it is solved at some point.
image

Edit: Seems to work against virtual for me. Let me know what you have in the box.

@chrstrvs
Copy link

I changed to M876 S{choice} as that is what worked for Da Hai, but I will change back to just M876 and see if that works.

@chrstrvs
Copy link

chrstrvs commented Nov 16, 2020

Nope, still doesn't work for me after changing Dialog command from M876 S{choice} to just M876.

@cp2004
Copy link
Member

cp2004 commented Nov 16, 2020

@chrstrvs Could you enable serial.log, restart printer connection and then reproduce the issue, and upload the serial log? Might be interesting to see whether OctoPrint is sending the right things, wrong things or the firmware is getting upset.

@foosel
Copy link
Member

foosel commented Nov 17, 2020

For the record, cannot reproduce, M876 sends fine over here while the printer is reporting as busy.

Will not be able to look into this unless I get a serial.log of a reproduction, as outlined by @cp2004.

image

2020-11-17 10:19:57,706 - Recv: Cap:EMERGENCY_PARSER:1
2020-11-17 10:19:57,712 - Recv: Cap:PROMPT_SUPPORT:1
2020-11-17 10:21:34,456 - Send: N3830 M600*29
2020-11-17 10:21:34,458 - Recv: //action:paused
2020-11-17 10:21:34,458 - Printer signalled that it paused, switching state...
2020-11-17 10:21:34,459 - Changing monitoring state from "Printing" to "Pausing"
2020-11-17 10:21:34,464 - Recv: //action:prompt_end
2020-11-17 10:21:34,465 - Recv: //action:prompt_begin Heater Timeout
2020-11-17 10:21:34,466 - Recv: //action:prompt_button Reheat
2020-11-17 10:21:34,467 - Recv: //action:prompt_show
2020-11-17 10:21:34,470 - Recv: echo:busy paused for user
2020-11-17 10:21:36,472 - Recv: echo:busy paused for user
2020-11-17 10:21:38,475 - Recv: echo:busy paused for user
2020-11-17 10:21:40,488 - Recv: echo:busy paused for user
2020-11-17 10:21:41,845 - Send: N3831 M876 S0*80

@chrstrvs
Copy link

Sure, I can log the serial communication and post it here.

Is EMERGENCY_PARSER required to get this to work? I don't think that is supported for STM32 yet, which I have.

@foosel
Copy link
Member

foosel commented Nov 17, 2020

Is EMERGENCY_PARSER required to get this to work?

Yes. Without it signaled as available, OctoPrint must not send commands to the printer when it is busy.

@chrstrvs
Copy link

chrstrvs commented Nov 17, 2020

I was wrong, EMERGENCY_PARSER is available for STM32. I will try to upload a log later this week if it still doesn't work.
Thanks for all the help so far!

@chrstrvs
Copy link

Okay, so when M600 i sent I get the option to load new filament and press Continue. This works and the new filament gets loaded, but when I press Purge more the printer resets.
The serial log is attached.
serial.log

@cp2004
Copy link
Member

cp2004 commented Nov 17, 2020

That sounds to me, like a FW bug. Since OctoPrint is sending the right thing (M876 S0 for PurgeMore), and then the printer crashes. Is it mainline Marlin, or other? Doesn't look like there's much we can do for that one from OctoPrint's end, since it is sending then right things - the first prompt even worked OK.

@chrstrvs
Copy link

That sounds to me, like a FW bug. Since OctoPrint is sending the right thing (M876 S0 for PurgeMore), and then the printer crashes. Is it mainline Marlin, or other? Doesn't look like there's much we can do for that one from OctoPrint's end, since it is sending then right things - the first prompt even worked OK.

I totally agree that this is due to the printer firmware.
Yes, I'm running Marlin 2.0.7.2. I will open a bug report if no one else has already done so.

@GitIssueBot
Copy link

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/octopi-disconnect-when-changing-filament/19374/6

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Issue has been approved by the bot or manually for further processing bug Issue describes a bug done Done but not yet released
Projects
None yet
Development

No branches or pull requests

7 participants