<p><em>This is not an answer/explanation per se, but it might help you track down the cause.</em></p>

<hr>

<p>It <em>might</em> be worth <a href="http://marlinfw.org/docs/gcode/M928.html" rel="nofollow noreferrer">enabling logging</a> <code>M928</code> to the SD card (ensure that the R/W tab on the SD card is set appropriately), so that (after this has happened a few times) then you can look through the log to see what the command preceding the abort was, and if it is consistently the same (sequence of) commands that cause this to happen. </p>

<pre><code>M928 filename
</code></pre>

<p>If that doesn't throw up anything obvious, then, in conjunction with logging, you could enable debugging, see <a href="http://marlinfw.org/docs/gcode/M111.html" rel="nofollow noreferrer"><code>M111</code> Debug level</a>. For example:</p>

<pre><code>M111 S7 ; ECHO, ERRORS, INFO
</code></pre>

<p>Then run through the long print again. As before, after a few of the <em>click to resume print</em> messages, then go back and check the log for anything that might indicate why this is happening.</p>

<p>To subsequently disable the debugging:</p>

<pre><code>M111 S0
</code></pre>

CC BY-SA 4.0
2018-10-23T23:06:58.773Z
I'm curious to know whether this error is reported, nice addition!
0scar
CC BY-SA 4.0
2018-11-04T09:36:18.483Z
unfortunately, logging does not work. When executing the M928 command, it shows the filename in the display, nothing else happens. When resuming the print, manually, the printer hangs. The resulting file on the sd card is empty.
Till B
CC BY-SA 4.0
2018-11-04T11:25:29.150Z
@TillB - Hmmm, that doesn't sound right...
Greenonline
CC BY-SA 4.0
2018-11-04T11:41:12.217Z
I put the M928 into the gcode right at the beginning. Is that correct? Or should I rather put it somewhere later or send it via USB? currently it is executed right after preheating
Till B
CC BY-SA 4.0
2018-10-23T19:18:57.583Z
2018-10-24T11:24:52.960Z
2018-10-24T11:24:52.960Z
Greenonline
<p>For your information, this problem has occurred for me with Cura 3.6.0 (yesterday and 2 days ago)</p>

<p>I thought the problem was occurring with Marlin since 1.8.</p>

<p>My Marlin version is 1.3 (... just discover that because of that issue!)</p>

<p>As my printer works perfectly with 1.3, I'd prefer not to upgrade.</p>

<p>I had the 'click to resume' problem twice. </p>

<p>I've printed tons of ABS models without problem, two days ago, I've printed PLA models and had this issue. (70&nbsp;°C 200&nbsp;°C).</p>

<p>For sure if the problem occurs again, I'll upgrade to Marlin 1.9 (or even 2.0 even if still in beta) because it seems that you <em>have</em> found the problem and already solved it; I was surprised to read that it was fixed in Cura 3.6 since I had the problem with that version.</p>

<p>My printer is a Tevo Tarentula (modified, I've removed the pseudo bed leveling options because I prefer to level manually (no z move while printing)).</p>

<p>One more information is that in parallel, I've decided to print the first layer at a very low speed (adhesion problems).</p>

<p>I've changed from 30&nbsp;mm/s (ABS with big adhesion problems) to 10&nbsp;mm/s with PLA + Cura 3.6 and went into this bug (yes one could argue that I may print faster etc., but that's not the point here). Maybe I have the problem because I'm printing the 1st layer at a this slow speed (thus making the full buffer problem more critical).</p>

<p>The bug does not occur each time I print, even when printing the same model with same parameters...</p>

<p>@HuguesDug reported the <a href="https://github.com/Ultimaker/Cura/issues/3994" rel="nofollow noreferrer">same problem 14 days ago</a> and
@Leeb answered him that running with Marlin 1.9 solved the problem.</p>

CC BY-SA 4.0
2018-12-01T02:53:35.683Z
This seems more like a bug report (or me too answer) and not an actual answer with a solution - would that be a correct analysis?
Greenonline
CC BY-SA 4.0
2018-12-01T09:54:16.273Z
You're right Greenonline, I wanted not to bug report since I have an old version of marlin and was imho too soon to report anything without searching more by myself. More again, the bug has been 'solved' and the reason was clear to me so reporting the same bug again would have been imho a waste of time for developpers. I've edited my post few minutes ago to answer myself : upgrade to marlin 1.9 should solve the problem. If not, then I'll open a report. Anyway, feel free to remove my post if that's sounds to you as noise :-D
HSaturn
CC BY-SA 4.0
2018-12-01T11:18:07.433Z
Me-Too reports that don't contain an answer are not what we try to strive for on the stack. Open a new question, if you have a similar problem, make an answer, if you solved your similar problem.
Trish
CC BY-SA 4.0
2018-12-01T14:24:42.727Z
Thanks for providing the update. The answer makes more sense now, thanks. Also, Hi and welcome to SE.3DP, BTW. :-)
Greenonline
CC BY-SA 4.0
2018-11-30T23:08:18.990Z
2018-12-01T14:31:20.863Z
2018-12-01T14:31:20.863Z
HSaturn
<p>Tonight I had faced the same problem.</p>

<p>I've read somewhere (can't find the source now) that this is a Cura bug that has been fixed in Cura 3.6 beta</p>

CC BY-SA 4.0
2018-11-06T02:54:31.370Z
If you can find the link, that would make your answer very useful. Maybe search your browser history?
Greenonline
CC BY-SA 4.0
2018-11-06T03:04:33.590Z
According to [this page for 3.4beta](https://ultimaker.com/en/blog/52644-ultimaker-cura-34-beta-available-now), `For a full rundown of bug fixes, open Ultimaker Cura 3.4 beta and navigate to Extensions > Changelog > Show changelog.` The page for [3.6 beta](https://ultimaker.com/en/blog/52744-ultimaker-cura-36-beta-available-now) doesn't mention much, and I can't find the full list of fixes.
Greenonline
CC BY-SA 4.0
2018-11-06T07:24:20.597Z
@Greenonline It is an interfacing bug between Ultimaker Cura 3.4+ and 1.1.8+ Marlin, see [my answer](/a/7287/5740)
0scar
CC BY-SA 4.0
2018-11-07T17:02:45.013Z
@0scar - Ah ok, nice catch, well done :-)
Greenonline
CC BY-SA 4.0
2018-11-05T22:10:49.840Z
2018-12-01T11:18:54.947Z
2018-12-01T11:18:54.947Z
divest divest
<p>To answer your question directly, this action (<code>Click to resume...</code>) is triggered by a buffer overflow of the Marlin firmware that is caused by the repetitive sending of <code>M105</code> command by Ultimaker Cura (without checking the result).</p>

<p>This problem is a <a href="https://github.com/Ultimaker/Cura/issues/3994" rel="nofollow noreferrer">reported problem</a> and fixed in the next release of Ultimaker Cura (please do note that as of posting this answer, the 3.6 Beta release is available for <a href="https://ultimaker.com/en/blog/52744-ultimaker-cura-36-beta-available-now" rel="nofollow noreferrer">download</a>). It appears to be a communication problem between Ultimaker Cura 3.4+ and 1.1.8+ versions of the Marlin firmware and has to to with polling of the temperature (<code>M105</code>). The link above also states it is fixed in the 3.6 release (which is the next release) as the fix has been integrated in the main code base.</p>

<p>This describes the problem:</p>

<blockquote>
  <p>To update the temperatures in the monitor, Cura sends M105 pings every
  2 seconds. It seems that if this is done during a print without
  waiting for an <code>OK</code> from the printer, the serial buffer on the printer
  may still overflow eventually (causing Marlin to complain/pause).</p>
</blockquote>

<p>and this describes the solution:</p>

<blockquote>
  <p>During some operations, such as preheating, the printer responds to
  new commands with <code>echo:busy</code>. While it is busy, it does send
  temperature messages, but these are not prepended with an <code>ok</code>,
  because the <code>ok</code> is supposed to show that a command was received and
  executed. So the two patches I wrote do the following:</p>
  
  <ul>
  <li>the pattern matching no longer looks for <code>ok</code> messages, but looks for
  temperature updates (this fixes the temperature updating while the
  printer is preheating) </li>
  <li>once the printer has said that it is busy, stop
  asking for temperature updates until the next <code>ok</code> is received (this
  prevents the serial buffer overflowing while preheating)</li>
  </ul>
</blockquote>

<hr>

<p><em>Old answer centered around the firmware (based on the text of the OP, no photo with the actual error message was added yet):</em></p>

<p><strike>The text <code>click to resume print</code> cannot be found (with case insensitive search) in the latest sources of Marlin 1.1.9 down to Marlin 1.1.6. This means that you are using a different fork, an older version of Marlin or the message is not displayed as such.</p>

<p>The text message <code>Resume print</code> can be found, and is part of the message constant <code>MSG_RESUME_PRINT</code></p>

<pre><code>#define MSG_RESUME_PRINT                    _UxGT("Resume print")
</code></pre>

<p>But, this cannot be found in some sort of a concatenation using <code>MSG_RESUME_PRINT</code>!</strike></p>

CC BY-SA 4.0
2018-10-24T12:54:09.440Z
2018-11-06T09:52:17.223Z
2018-11-06T09:52:17.223Z
0scar
<p>I have a long print that keeps aborting. At some random point mid-print the printer says "Click to resume...". There is nothing in the G-code that asks for user confirmation. What could it be that triggers this? I noticed that sometimes (not every time) there is a blob of plastic in the way that should not be there.</p>

<p>On one occasion, after the "Click to resume...", the LCD showed the message <code>FY178.N16466</code> and again waited for a click.</p>

<p>The printer is an Anet A8 with Marlin 1.1.9. Slicer is Cura. I am printing via USB from Cura directly.</p>

<p>This is the error message:</p>

<p><a href="https://i.sstatic.net/QXdNc.jpg" rel="nofollow noreferrer" title="&quot;Click to resume...&quot; error message"><img src="https://i.sstatic.net/QXdNc.jpg" alt="&quot;Click to resume...&quot; error message" title="&quot;Click to resume...&quot; error message"></a></p>

CC BY-SA 4.0
2018-10-23T03:16:59.657Z
Do you have an M600 color change operation in your g-code?  An M600 will cause the extruder to eject the current filament by reversing the extruder motor for a distance, like 100mm, then it displays a message like yours waiting for you to load the new filament; after you click it advances the filament and resumes printing.
John Deters
CC BY-SA 4.0
2018-10-23T10:18:33.147Z
@JohnDeters No, that is not in the g-code
Till B
CC BY-SA 4.0
2018-11-05T12:03:05.917Z
I observed this too in 1.1.9 when a PC is connected via USB. I think this must be a bug.
dgrat
CC BY-SA 4.0
2018-11-06T03:08:57.940Z
I don't know if this helps but [Newbie issue](https://community.ultimaker.com/topic/24285-newbie-issue/) mentions the same issue
Greenonline
CC BY-SA 4.0
2018-11-06T07:19:29.243Z
It appears to be a problem between Ultimaker Cura 3.4+ and Marlin Firmware 1.1.8+, where Cura sends too many M105 commands (without waiting for an OK) causing the buffer of the printer to overflow, see my updated answer.
0scar
CC BY-SA 4.0
2018-12-03T18:53:31.237Z
Yes, I use Cura 3.6 already. I am now happy to say that the print lasts long enough to produce secondary problems (layer shifting, presumably due to overheating stepper drivers). I am working on it.
Till B
<firmware><troubleshooting>
What triggers Marlin's "Click to resume..."?
Till B
# What triggers Marlin's "Click to resume..."?

(Asked by: username_0 on 2018-10-21)

I have a long print that keeps aborting. At some random point mid-print the printer says "Click to resume...". There is nothing in the G-code that asks for user confirmation. What could it be that triggers this? I noticed that sometimes (not every time) there is a blob of plastic in the way that should not be there.

On one occasion, after the "Click to resume...", the LCD showed the message `FY178.N16466` and again waited for a click.

The printer is an Anet A8 with Marlin 1.1.9. Slicer is Cura. I am printing via USB from Cura directly.

This is the error message:

[![](https://i.sstatic.net/QXdNc.jpg)](https://i.sstatic.net/QXdNc.jpg)

**Tags:** firmware, troubleshooting
> **Comments:**
> **username_1**: Do you have an M600 color change operation in your g-code?  An M600 will cause the extruder to eject the current filament by reversing the extruder motor for a distance, like 100mm, then it displays a message like yours waiting for you to load the new filament; after you click it advances the filament and resumes printing.  
> **username_0**: @JohnDeters No, that is not in the g-code  
> **username_2**: I observed this too in 1.1.9 when a PC is connected via USB. I think this must be a bug.  
> **username_3**: I don't know if this helps but [Newbie issue](https://community.ultimaker.com/topic/24285-newbie-issue/) mentions the same issue  
> **username_4**: It appears to be a problem between Ultimaker Cura 3.4+ and Marlin Firmware 1.1.8+, where Cura sends too many M105 commands (without waiting for an OK) causing the buffer of the printer to overflow, see my updated answer.  
> **username_0**: Yes, I use Cura 3.6 already. I am now happy to say that the print lasts long enough to produce secondary problems (layer shifting, presumably due to overheating stepper drivers). I am working on it.  

---

## 4 answers

### Answer by username_4 on 2018-10-24. Score: 6 | Accepted answer

To answer your question directly, this action (Click to resume...) is triggered by a buffer overflow of the Marlin firmware that is caused by the repetitive sending of M105 command by Ultimaker Cura (without checking the result).
This problem is a reported problem and fixed in the next release of Ultimaker Cura (please do note that as of posting this answer, the 3.6 Beta release is available for download). It appears to be a communication problem between Ultimaker Cura 3.4+ and 1.1.8+ versions of the Marlin firmware and has to to with polling of the temperature (M105). The link above also states it is fixed in the 3.6 release (which is the next release) as the fix has been integrated in the main code base.
This describes the problem:

To update the temperatures in the monitor, Cura sends M105 pings every
  2 seconds. It seems that if this is done during a print without
  waiting for an OK from the printer, the serial buffer on the printer
  may still overflow eventually (causing Marlin to complain/pause).

and this describes the solution:

During some operations, such as preheating, the printer responds to
  new commands with echo:busy. While it is busy, it does send
  temperature messages, but these are not prepended with an ok,
  because the ok is supposed to show that a command was received and
  executed. So the two patches I wrote do the following:

the pattern matching no longer looks for ok messages, but looks for
  temperature updates (this fixes the temperature updating while the
  printer is preheating) 
once the printer has said that it is busy, stop
  asking for temperature updates until the next ok is received (this
  prevents the serial buffer overflowing while preheating)



Old answer centered around the firmware (based on the text of the OP, no photo with the actual error message was added yet):
The text click to resume print cannot be found (with case insensitive search) in the latest sources of Marlin 1.1.9 down to Marlin 1.1.6. This means that you are using a different fork, an older version of Marlin or the message is not displayed as such.
The text message Resume print can be found, and is part of the message constant MSG_RESUME_PRINT
#define MSG_RESUME_PRINT                    _UxGT("Resume print")

But, this cannot be found in some sort of a concatenation using MSG_RESUME_PRINT!


---

### Answer by username_3 on 2018-10-23. Score: 2

This is not an answer/explanation per se, but it might help you track down the cause.

It might be worth enabling logging M928 to the SD card (ensure that the R/W tab on the SD card is set appropriately), so that (after this has happened a few times) then you can look through the log to see what the command preceding the abort was, and if it is consistently the same (sequence of) commands that cause this to happen. 
M928 filename

If that doesn't throw up anything obvious, then, in conjunction with logging, you could enable debugging, see M111 Debug level. For example:
M111 S7 ; ECHO, ERRORS, INFO

Then run through the long print again. As before, after a few of the click to resume print messages, then go back and check the log for anything that might indicate why this is happening.
To subsequently disable the debugging:
M111 S0

> **Comments:**
> **username_4**: I'm curious to know whether this error is reported, nice addition!  
> **username_0**: unfortunately, logging does not work. When executing the M928 command, it shows the filename in the display, nothing else happens. When resuming the print, manually, the printer hangs. The resulting file on the sd card is empty.  
> **username_3**: @TillB - Hmmm, that doesn't sound right...  
> **username_0**: I put the M928 into the gcode right at the beginning. Is that correct? Or should I rather put it somewhere later or send it via USB? currently it is executed right after preheating  

---

### Answer by username_5 on 2018-11-30. Score: 2

For your information, this problem has occurred for me with Cura 3.6.0 (yesterday and 2 days ago)

I thought the problem was occurring with Marlin since 1.8.

My Marlin version is 1.3 (... just discover that because of that issue!)

As my printer works perfectly with 1.3, I'd prefer not to upgrade.

I had the 'click to resume' problem twice.

I've printed tons of ABS models without problem, two days ago, I've printed PLA models and had this issue. (70 °C 200 °C).

For sure if the problem occurs again, I'll upgrade to Marlin 1.9 (or even 2.0 even if still in beta) because it seems that you *have* found the problem and already solved it; I was surprised to read that it was fixed in Cura 3.6 since I had the problem with that version.

My printer is a Tevo Tarentula (modified, I've removed the pseudo bed leveling options because I prefer to level manually (no z move while printing)).

One more information is that in parallel, I've decided to print the first layer at a very low speed (adhesion problems).

I've changed from 30 mm/s (ABS with big adhesion problems) to 10 mm/s with PLA + Cura 3.6 and went into this bug (yes one could argue that I may print faster etc., but that's not the point here). Maybe I have the problem because I'm printing the 1st layer at a this slow speed (thus making the full buffer problem more critical).

The bug does not occur each time I print, even when printing the same model with same parameters...

@HuguesDug reported the [same problem 14 days ago](https://github.com/Ultimaker/Cura/issues/3994) and
@Leeb answered him that running with Marlin 1.9 solved the problem.

> **Comments:**
> **username_3**: This seems more like a bug report (or me too answer) and not an actual answer with a solution - would that be a correct analysis?  
> **username_5**: You're right Greenonline, I wanted not to bug report since I have an old version of marlin and was imho too soon to report anything without searching more by myself. More again, the bug has been 'solved' and the reason was clear to me so reporting the same bug again would have been imho a waste of time for developpers. I've edited my post few minutes ago to answer myself : upgrade to marlin 1.9 should solve the problem. If not, then I'll open a report. Anyway, feel free to remove my post if that's sounds to you as noise :-D  
> **username_6**: Me-Too reports that don't contain an answer are not what we try to strive for on the stack. Open a new question, if you have a similar problem, make an answer, if you solved your similar problem.  
> **username_3**: Thanks for providing the update. The answer makes more sense now, thanks. Also, Hi and welcome to SE.3DP, BTW. :-)  

---

### Answer by username_7 on 2018-11-05. Score: 1

Tonight I had faced the same problem.

I've read somewhere (can't find the source now) that this is a Cura bug that has been fixed in Cura 3.6 beta

> **Comments:**
> **username_3**: If you can find the link, that would make your answer very useful. Maybe search your browser history?  
> **username_3**: According to [this page for 3.4beta](https://ultimaker.com/en/blog/52644-ultimaker-cura-34-beta-available-now), `For a full rundown of bug fixes, open Ultimaker Cura 3.4 beta and navigate to Extensions > Changelog > Show changelog.` The page for [3.6 beta](https://ultimaker.com/en/blog/52744-ultimaker-cura-36-beta-available-now) doesn't mention much, and I can't find the full list of fixes.  
> **username_4**: @Greenonline It is an interfacing bug between Ultimaker Cura 3.4+ and 1.1.8+ Marlin, see [my answer](/a/7287/5740)  
> **username_3**: @0scar - Ah ok, nice catch, well done :-)  

---

