Cura: wait for user errors

[ahlonnae]

Application Version
3.5.0

Platform
windows 10

Printer
prizua i3

Steps to Reproduce
just printing

Actual Results
wait for user error---27 times in 4 hours

Expected results
just print uninterrupted

Additional Information

[rburema]

Hi @ahlonnae,
Keep in mind, if this happens during printing, it _might_ not be a Cura issue. Can you print with other versions, or with 'raw' gCode (perhaps from another source) just OK?
If it is, though: Does this only happen with 3.5? Is there anything in the logs? Does this happen for one model, or more? If only one or a few, could you perhaps send us the model?
cheers, Remco.

[fieldOfView]

Probably a duplicate of https://github.com/Ultimaker/Cura/issues/3994

[ahlonnae]

It only happened with the previous 2 versions from time to time, with the
SD card a couple of times, with the new version of Cura 3.5.1 it happened
27 times!
Every 3-5 minutes.
Last night with the SD card not 1 time.
Different models from the net:
Trying to print InMoov Humanoid Robot and Anet A2 upgrades.
What else could cause such a problem.
Anything in settings?
Using Prusai3 setting.
I saw that some people were saying something about the g -code and a M109
code telling the printer to stop and wait.
So I don't know if it is a firmware problem or something else.
If no one else is having a problem than maybe it's something else.
Open to suggestions that you might have.
Have you heard of anything else that could be at fault?

[rburema]

If I understand the issue linked by @fieldOfView correctly, it's a combination of certain firmware and Cura not playing nice with each other. To test if this is the issue you suffer from, you could try release 3.3.1, and see if it works. If so, that would increase the chance of this issue affecting you. Then, if all of this is the case, there is a ticket in the system right now that will fix the issue, which will _hopefully_ be in 3.6

[fieldOfView]

@ahlonnae you mention that this happens when printing from SD. Could you tell me if you have the USB cable connected, and you have Cura running while printing from SD when the printing is interrupted?

[diegopradogesto]

It seems to be related and here is the fix https://github.com/Ultimaker/Cura/pull/4487.

It should work in the 3.6 version that we will release next week.

[rdoyle1978]

This is still occurring with CURA 3.6 on a stock Ender3. I am connected via USB and the print stops every few MINUTES (I just did it 3 times in 20 minutes) with a "Wait for user input" message. This occurs only on certain prints, but I have not found anything common to them except that they appear to all have very long X-axes

[ahlonnae]

Hello, I despertly need Your HELP---My 64 bit computer just died & i'm
using a 32 bit machine do you have a Cura version that I can use?
Trying to change stl to g-code.
HELP!

On Sat, Mar 9, 2019 at 7:36 AM rdoyle1978 [e-mail] wrote:

This is still occurring with CURA 3.6 on a stock Ender3. I am connected
via USB and the print stops every few MINUTES (I just did it 3 times in 20
minutes) with a "Wait for user input" message. This occurs only on certain
prints, but I have not found anything common to them except that they
appear to all have very long X-axes

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Ultimaker/Cura/issues/4590#issuecomment-471190468,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APt9YSD8hR826o5PYCnjAKLbvj963UF6ks5vU9T8gaJpZM4Xg5e4
.

[rburema]

@rdoyle1978

• What firmware version are you on? The last few messages in https://github.com/Ultimaker/Cura/issues/3994 suggest that it could have something to do with that as well.
• This is a bit of a shot in the dark, but, you could try the new 4.0-BETA-2, which had a bug fixed where on large prints, no G92 0 commands where sent to periodically reset the position to negate floating point innacuracies. I doubt that's it though.
• If all else fails, could you send us any gcode that causes lots of these pauses?

@ahlonnae
Please see here for a list of older versions, some of which are 32-bits compatible (scroll down if you use mac, or even further for linux): https://ultimaker.com/en/products/ultimaker-cura-software/list

[rdoyle1978]

I believe I’m on Marlin 1.18, but I’m going to upgrade so I can add auto-levelling. I also verified no Gcode pauses are being sent - no M226, M25, M0, M1, etc are present in the code, so i think the theory about the USB overflow may be correct. The stl printed fine using the SDCard

[Ghostkeeper]

We have no way of debugging this ourselves without having an Ender 3 printer here. We'll need someone with that printer that is able to debug this, or a good suggestion for a theoretical improvement that we can make to the code.

[rdoyle1978]

Thanks for reopening. Is this still only occurring on Ender3? I will upgrade to the latest Marlin and see if that helps resolve it

[Ghostkeeper]

It's not occurring on the Ultimaker 2, in any case. I haven't tried any others.

[thioroup8]

Hi,

I am also concerned by this issue.

I tested following versions:

• 3.2.1: OK
• 3.4.1: OK
• 3.5.1: OK
• 3.6.0: NOK
• 4.0.0: NOK
• 4.1.0: NOK
• 4.2.0-BETA: NOK

OS: Ubuntu 18.04.2 LTS

Since 3.6.0, I am unable to achieve a print on my Creality CR-10 300.
"Wait for user" message appears during print of first layer. As a consequence, layer is damaged with PLA melted: absolutely unusable at all.

I provide you an archive with STL file and gcode files for each Cura versions.
archive.zip

Maybe it could help...

[rdoyle1978]

This issue drives me crazy. I have found that it is caused by prints that require large areas of straight printing - like a really large raft under a model, for example.

I have found that if I rotate the model prior to slicing, the issue pretty much goes away. I just finished a 20 hour print that was stopping every 15 minutes “wait for user”. I rotated it in CURA and re-sliced, and it printed continuously.

-Rob Doyle

On Jul 28, 2019, at 3:12 AM, thioroup8 [e-mail] wrote:

Hi,

I am also concerned by this issue.

I tested following versions:

3.2.1: OK
3.4.1: OK
3.5.1: OK
3.6.0: NOK
4.0.0: NOK
4.1.0: NOK
4.2.0-BETA: NOK
Since 3.6.0, I am unable to achieve a print on my Creality CR-10 300.
"Wait for user" message appears during print of first layer. As a consequence, layer is damaged with PLA melted: absolutely unusable at all.

I provide you an archive with STL file and gcode files for each Cura versions.
archive.zip

Maybe it could help...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thioroup8]

Yes it is very frustrating :(

I have chance to reproduce the issue during print of first layer.
I prefer a print failure sooner than later.
A print failure after 10 hours... Argggggggh!!!

@rdoyle1978 did you try versions I mentioned OK?
I know it is not the solution but just to give some clues...

[Ghostkeeper]

Could you guys try this:

Add a post-processing script in Cura, a search-and-replace script. As the search term, use this:

;MESH:.*\n

Leave the replace parameter empty. Then check "Use Regular Expressions".

This will remove the mesh type comments from the g-code. It was the only difference I could see in the g-code itself except for the coordinates that the printer was moving to and the number of lines in the first layer.

Try to print with that in Cura 4.1 or higher (in older versions the post-processing scripts were not properly applied when printing via USB apparently).

[rdoyle1978]

Will try when I get a chance, thank you!

I did not try any other versions yet - I am running Cura 4.5 but it has happened in the previous version I installed as well. I am not sure about 4.0, I can’t recall if I had this issue that far back.

-Rob Doyle

On Jul 29, 2019, at 8:41 AM, Ghostkeeper [e-mail] wrote:

Could you guys try this:

Add a post-processing script in Cura, a search-and-replace script. As the search term, use this:

;MESH:.*\n
Leave the replace parameter empty. Then check "Use Regular Expressions".

This will remove the mesh type comments from the g-code. It was the only difference I could see in the g-code itself except for the coordinates that the printer was moving to and the number of lines in the first layer.

Try to print with that in Cura 4.1 or higher (in older versions the post-processing scripts were not properly applied when printing via USB apparently).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thioroup8]

@Ghostkeeper I just finished the test with 4.1 version and your suggested post-processing script.
Sadly, it failed with same symptoms :(

[Ghostkeeper]

I don't know what change could cause your printer to pause then. The difference between the 3.6 g-code and the 4.0 g-code that was posted earlier only has the ;MESH comments and a difference in the actual locations and extrusion moves.

Could it be that the printer triggers a pause when it's commanded to move outside of the build volume? Is that happening?

[rdoyle1978]

I don't think this is what is happening in my case.  There are clearly no pause commands being sent in the gcode - but the Ender3 specifically seems to have this issue. 
Again, it is very predictable in prints that have long sections of straight lines, like a raft under a large object.

[thioroup8]

I made some additional USB tests:

• gcode file generated by Cura 3.2.1 but print with Cura 4.1.0: OK
• gcode file generated by Cura 4.1.0 but print with Cura 3.2.1: NOK

We can see above the print failure with drop of melted PLA on the bottom left corner.

And here data about CR10 printer.

I noticed the different printing strategies of Cura versions.
Cura 3.2.1 prints rectangles smaller and smaller until reach center of the print.
Cura 4.1.0 draws lines from top left corner until (probably) bottom right corner.

In the second strategy, last printed line measure more than 190 mm for a rectangle of 172x138 mm. Maybe it could be linked with @rdoyle1978 comment...

I also take care about USB auto-suspend. I blacklisted my CR10 in the /etc/default/tlp file. This technique operate well with my 2D scanner.
I also monitored udev and dbus activity to try to detect some suspect behavior. I didn't notice anything weird.

Maybe an interesting URL:
https://www.reddit.com/r/3Dprinting/comments/4qbi1s/waiting_for_user_pause_in_print/

[Ghostkeeper]

If 4.1.0 g-code doesn't print through Cura 3.2.0 but 3.2.0 g-code does print, that rules out anything regarding the USB connection or anything. It must be the g-code then. Interesting result.

The rectangles vs. lines is a setting called Top/Bottom Pattern, or perhaps Bottom Pattern Initial Layer for just the first layer. If you set it to "concentric" the pattern will be rectangles going inside (or rather from inside to outside). If you set it to "lines" the pattern will be lines. As far as I know that pattern has always been lines by default on pretty much all profiles.

What happens if you reduce the printing temperatures? Looking at /u/kakarotoks' comment in that Reddit thread, it might reduce the chance of this bug happening.

[rdoyle1978]

Interesting!! I will try a lower temp. I think I print at 190F right now.

-Rob Doyle

On Aug 1, 2019, at 10:00 AM, Ghostkeeper [e-mail] wrote:

If 4.1.0 g-code doesn't print through Cura 3.2.0 but 3.2.0 g-code does print, that rules out anything regarding the USB connection or anything. It must be the g-code then. Interesting result.

The rectangles vs. lines is a setting called Top/Bottom Pattern, or perhaps Bottom Pattern Initial Layer for just the first layer. If you set it to "concentric" the pattern will be rectangles going inside (or rather from inside to outside). If you set it to "lines" the pattern will be lines. As far as I know that pattern has always been lines by default on pretty much all profiles.

What happens if you reduce the printing temperatures? Looking at /u/kakarotoks' comment in that Reddit thread, it might reduce the chance of this bug happening.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thioroup8]

This issue exists also in Cura 3.2.1. To reproduce issue on Cura 3.2.1, simply apply following settings:

• Default Printing Temperature 200°C
• Build Plate Temperature 60°C
• Top/Bottom Pattern Lines
• Bottom Pattern Initial Layer Lines

Following above @Ghostkeeper suggestion, I tried with lower temperatures:

• Default Printing Temperature 190°C
• Build Plate Temperature 50°C
• Top/Bottom Pattern Lines
• Bottom Pattern Initial Layer Lines

Lowering temperatures gives a successful print.

Just as a reminder, I produced this issue with Cura 4.2.0-BETA which has following default settings:

• Default Printing Temperature 200°C
• Build Plate Temperature 50°C
• Top/Bottom Pattern Lines
• Bottom Pattern Initial Layer Lines

So, lower Build Plate Temperature from 60°C to 50°C is not enough. We also need to lower Default Printing Temperature too. Anyway, it's interesting to notice Cura developers reduced Build Plate Temperature in Cura 4.2.0-BETA default settings.

It seems sequence of gcodes produced with Pattern Lines in combination with PLA default temperature saturate serial buffer of some 3D printers. Some gcodes seem to be truncated to M0 and/or M1 which are gcodes for pause after the last movement and wait for the user to continue.

Lowering temperatures seems to reduce pending gcodes in serial buffer of CR10 printer. It's a good point but it's not enough to be totally confident before running a print.
How can I monitor serial buffer occupation Vs capacity?
With an occupation around 10%, I will be more confident than with 90%...

Another consideration, printing with ABS material will be at least difficult.

[Ghostkeeper]

Anyway, it's interesting to notice Cura developers reduced Build Plate Temperature in Cura 4.2.0-BETA default settings.

This is a bug actually, that we also noticed just yesterday. By default Cura now chooses a newly added material called imade3d_generic_pla, instead of the normal generic_pla. That's also why your objects appear green instead of yellow. It'll be back at 60 degrees/yellow next release (hopefully).

[Ghostkeeper]

Is there anything that Cura can do to fix this, apart from changing the temperatures?

[thioroup8]

I hope so...
If you need someone to test a candidate fixed version, feel free to ask.

[fmaestre69]

Bug is there in Cura 4.2.1 , worse than even (I was on Cura 3.5.1 before).
Happening on a Stock CR10 S5 .
This bug exists since years guy, could a company like your just buy the very popular CR10-S and debug that ... it's taking ages.

[Ghostkeeper]

Yes, but a company like Ultimaker also ONLY develops Cura in order to support Ultimaker's printers. They are not going to spend time and/or money on debugging different printers. It's by the grace of the Cura developers' heart for free software that we are helping out. If I ask the department head he'd want me to stop responding at all, most likely. I cannot justify buying a printer on company funds and spending an afternoon or two to debug this. Only if I do that in my own time, and even then someone would need to review my fix on company time.

[rdoyle1978]

It’s REALLY appreciated that you are working on it at all - CURA is pretty amazing, not to mention it’s free software ! There’s at least a workaround at this point

-Rob Doyle

On Sep 5, 2019, at 8:02 AM, Ghostkeeper [e-mail] wrote:

Yes, but a company like Ultimaker also ONLY develops Cura in order to support Ultimaker's printers. They are not going to spend time and/or money on debugging different printers. It's by the grace of the Cura developers' heart for free software that we are helping out. If I ask the department head he'd want me to stop responding at all, most likely. I cannot justify buying a printer on company funds and spending an afternoon or two to debug this. Only if I do that in my own time, and even then someone would need to review my fix on company time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thioroup8]

Hmmm... There is no general workaround here. There is only a partial workaround to address specific scenario.
If we need to raise temperature, for any reasons (ABS, ...), issue will appear again. :(

However, Cura developers consideration for free software generates a lot of good things for all Cura users (Ultimaker's printers buyers and others). I agree with @rdoyle1978 comment on this point. At all Cura developers, many thanks for your work. I am also software developer so I have a good vision about developer daily activities and consequences on motivation due to negative comments.
Cura contains a certain amount of bugs like any other software in the world but it is also a really helpful sofware and pleasant to use which help a lot so many users everywhere. Respect for everyone making this possible and many thanks.

[fmaestre69]

I am also part of a programming company, I program videogames for nearly 28 years now, games like Assassin's Creed (ok you've guessed which company it is).

Distributing software , tools for free is good for everybody, we do it too, Epic Games open sourced it's game engine and never had that much feedback and benefits from that.

Actually even Cura is opened to extensions, plug-ins and it is good too for you too. One day someone might do a killer add-on that you will want to embed.
Thus,
Why not having a real look at that bug that happens since 3.5.1 to the most popular, very cheap printer ? What is the point of not spending 200$ buying one and really sort this out ? it's a win-win operation.

At least if the answer is "how you know, our focus is just the Ultimaker machine" then why won't we , at Ubisoft , say , sorry we don't support AMD graphics cards , buy an NVidia please...
If you have a business development guy reading those lines , I hope he understand that being a closed software solution actually is the worse thing to do... Instead , having "dedicated" features for your hardware would be very understandable.

Yes, but a company like Ultimaker also ONLY develops Cura in order to support Ultimaker's printers. They are not going to spend time and/or money on debugging different printers. It's by the grace of the Cura developers' heart for free software that we are helping out. If I ask the department head he'd want me to stop responding at all, most likely. I cannot justify buying a printer on company funds and spending an afternoon or two to debug this. Only if I do that in my own time, and even then someone would need to review my fix on company time.

[rdoyle1978]

The workaround I was referring to was just in rotating the model on the build plate prior to slicing. That works for me every time

-Rob Doyle

On Sep 5, 2019, at 2:31 PM, thioroup8 [e-mail] wrote:

Hmmm... There is no general workaround here. There is only a partial workaround to address specific scenario.
If we need to raise temperature, for any reasons (ABS, ...), issue will appear again. :(

However, Cura developers consideration for free software generates a lot of good things for all Cura users (Ultimaker's printers buyers and others). I agree with @rdoyle1978 comment on this point. At all Cura developers, many thanks for your work. I am also software developer so I have a good vision about developer daily activities and consequences on motivation due to negative comments.
Cura contains a certain amount of bugs like any other software in the world but it is also a really helpful sofware and pleasant to use which help a lot so many users everywhere. Respect for everyone making this possible and many thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[thioroup8]

@rdoyle1978 Ok, thank you for this clarification.

[nallath]

At least if the answer is "how you know, our focus is just the Ultimaker machine" then why won't we , at Ubisoft , say , sorry we don't support AMD graphics cards , buy an NVidia please...

The main difference is, Ubisoft sells the game, not the hardware. We're not selling the software but the hardware. So it's a bit more like asking AMD to update their drivers to work better for NVidia.

[fmaestre69]

At least if the answer is "how you know, our focus is just the Ultimaker machine" then why won't we , at Ubisoft , say , sorry we don't support AMD graphics cards , buy an NVidia please...

The main difference is, Ubisoft sells the game, not the hardware. We're not selling the software but the hardware. So it's a bit more like asking AMD to update their drivers to work better for NVidia.

Sorry but we do sell hardware too, Guillemot Corporation is part of Ubisoft group and sells products under the Thrusmaster, Hercules brands,

[nallath]

Sure, you're technically right. But I still think that the reason you guys support multiple hardware configurations is primarily because you would sell less software if you didn't.

I understand the frustration, but we have to draw a line as to where we stop supporting something and that line is with actively developing things that only benefit third party hardware. So we will give advice, review that code and test if it doesn't break anything else, provided that someone else contributes it.

[javy39]

Hello ,
Having same " waiting for user " problem
I've had my ENDER 3 Pro using CURA for about 6 months with GREAT success .
Last time I downloaded a file to print from Thiniverse , a window popped up to upgrade CURA 4.2.1
, I downloaded and now
When I download to my card and insert it in my printer , printer says "wait for user ..." ???
I did notice after downloading files to my SD card , files are .gcode.gz instead of just .gcode ??
If I want to print files from SD card downloaded from CURA 4.0 , they print fine .
Ever since I updated CURA 4.2.1 , having problems .
I tried uninstalling 4.2.1 and installing 4.0 but same problem .
I've tried contacting Ultimaker but no response
thanks
Javier

[Ghostkeeper]

I don't know how you tried to contact Ultimaker but generally support questions have to go through your reseller first. Ultimaker doesn't answer questions about non-Ultimaker printers.

[rdoyle1978]

Javier -

Rotate your mode 90 degrees on the print bed and try again.

-Rob Doyle

On Sep 17, 2019, at 5:53 AM, javy39 [e-mail] wrote:

Hello ,
Having same " waiting for user " problem
I've had my ENDER 3 Pro using CURA for about 6 months with GREAT success .
Last time I downloaded a file to print from Thiniverse , a window popped up to upgrade CURA 4.2.1
, I downloaded and now
When I download to my card and insert it in my printer , printer says "wait for user ..." ???
I did notice after downloading files to my SD card , files are .gcode.gz instead of just .gcode ??
If I want to print files from SD card downloaded from CURA 4.0 , they print fine .
Ever since I updated CURA 4.2.1 , having problems .
I tried uninstalling 4.2.1 and installing 4.0 but same problem .
I've tried contacting Ultimaker but no response
thanks
Javier

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[fieldOfView]

I did notice after downloading files to my SD card , files are .gcode.gz instead of just .gcode ??

That could be a clue. A .gcode.gz file is a compressed gcode file and your printer probably does not know what to do with that.

Could you try to save the gcode with File -> Export, and select "G-code file (*.gcode)" to save the gcode to your SD card? It would be interesting to know if after you have done that once Cura still prefers .gcode.gz over normal gcode files if you save them through the regular method.

[Ghostkeeper]

Trying that myself, but for me it saves a normal .gcode file to the SD card after slicing for the Ender 3. In the Ender 3 definition it also says that it prefers g-code.

[javy39]

THANK YOU Ghostkeeper ,Solved my problem , when I updated Cura , printer I entered Ultimaker 3 INSTEAD of Creality Ender 3
Usually issues like mine are operator error , Right ?
Again , thank you for your help !!Javier

[Ghostkeeper]

:smile: Yeah I think the bug is somewhere between the keyboard and the chair there.

However the original issue of "wait for user" is still not resolved. Let us know if there is anything we need to change in Cura's behaviour to fix it for those printers.

[javy39]

Very well said LOL
"wait for user errors" is no longer an issue for me .Apparently my Creality Ender 3 does not read .gcode.gz (compressed) filesSpencer Priddy from Ultimaker support solved my problem but also said the following ," However, I do need to mention that we won't be able to assist in troubleshooting your machine directly, as only the Ultimaker series of printers are officially supported by Ultimaker with the use of the Cura software "BUT Ultimaker printers are way out of my price range !
thanksJavier

[javy39]

Very well said LOL
"wait for user errors" is no longer an issue for me .Apparently my Creality Ender 3 does not read .gcode.gz (compressed) filesthanksJavier

[fmaestre69]

Still there in USB mode (CR10 5S)

[FSDataAnalysis]

Hello all.

One problem sometimes is the connection of the motor. If it is slightly loose the signal is not sent properly. If many errors are received by the motor, there will be this error and the printer will stop. Press the cables well into the motor. This solves the problem when it is motor related and signal related.

[kolokoklol]

https://www.myminifactory.com/ru/object/3d-print-107986

just remove the buzzer and use this fix

[enceegee]

I realise this is an old thread but hopefully someone is still reading it and can help me. This issue (wait for user...) is driving me mad! It has only occured since 'upgrading' to Cura 4.4.1. I have printed out loads of objects before the upgrade, all OK, and I have printed out quite a few different objects since the upgrade, all work fine - except 1 - which was fine before the upgrade.
It always stops in exactly the same place 64%, which is layer 40 out of 66. I have tried all the above suggestions i.e. change temp, turn object, etc. All of which make no difference.
I have examined the Gcode and I can see that between the layer 40 text and the layer 41 text there is about 20 lines of extra text that does not appear anywhere else in the program. (see below)
I have edited out the 13 lines above 'layer 41' (the five lines above that were already edited out) and it works fine.

So my question is:- why does Cura add these extra lines here and how do I stop it doing it?

This is a tiny object but still takes up 43 pages of text, so anything bigger could take up 100's if not 1000's of pages which I do not want to have to search through looking for obscure code before I print anything!

Part of the code with the offending lines:- (It is the lines immediately above ";LAYER:41")

;LAYER:40
;MESH:Balcony Chair.stl
G0 F9000 X157.49 Y176.553 Z4.92
;TYPE:WALL-OUTER
G1 F600 X156.473 Y175.622 E50.9925
G1 X154.755 Y174.636 E51.03203
G1 X152.528 Y173.705 E51.0802
G1 X150.002 Y172.913 E51.13303
G1 X147.419 Y172.336 E51.18585
G1 X145.024 Y172.029 E51.23404
G1 X143.719 Y172.025 E51.26008
G1 X143.764 Y171.859 E51.26351
G1 X145.138 Y171.902 E51.29094
G1 X147.48 Y172.238 E51.33816
G1 X150.027 Y172.819 E51.39029
G1 X150.696 Y173.025 E51.40426
G1 X152.434 Y166.54 E51.53824
G1 X159.775 Y168.507 E51.68991
G1 X159.685 Y168.845 E51.69689
G1 X152.682 Y166.969 E51.84157
G1 X151.031 Y173.129 E51.96884
G1 X152.521 Y173.589 E51.99996
G1 X154.723 Y174.47 E52.04729
G1 X156.394 Y175.368 E52.08514
G1 X157.359 Y176.171 E52.1102
G1 X157.49 Y176.553 E52.11826
;TIME_ELAPSED:272.161952
;TYPE:CUSTOM
;added code by post processing
;script: PauseAtHeight.py
;current z: 5.04
;current height: 5.04
M83 ; switch to relative E values for any needed retraction
G1 F300 Z6.04 ; move up a millimeter to get out of the way
G1 F9000 X190 Y190
G1 F300 Z15 ; too close to bed--move to at least 15mm
M104 S0 ; standby temperature
M0 ; Do the actual pause
M109 S190 ; resume temperature
G1 F300 Z6.04
G1 F9000 X157.49 Y176.553
G1 F300 Z5.04 ; move back down to resume height
G1 F2700 ; restore extrusion feedrate
M82 ; switch back to absolute E values
G92 E52.11826
;LAYER:41
;MESH:Balcony Chair.stl
G0 F9000 X157.49 Y176.553 Z5.04
;TYPE:WALL-OUTER
G1 F600 X156.473 Y175.622 E52.14577
G1 X154.755 Y174.636 E52.1853
G1 X152.528 Y173.705 E52.23347
G1 X150.002 Y172.913 E52.2863
G1 X147.429 Y172.338 E52.33891
G1 X145.024 Y172.029 E52.3873
G1 X143.719 Y172.025 E52.41334
G1 X143.764 Y171.859 E52.41678
G1 X145.138 Y171.902 E52.44421
G1 X147.468 Y172.236 E52.49118
G1 X150.027 Y172.819 E52.54356
G1 X150.696 Y173.025 E52.55753
G1 X152.434 Y166.54 E52.69151
G1 X159.775 Y168.507 E52.84318
G1 X159.685 Y168.845 E52.85016
G1 X152.682 Y166.969 E52.99484
G1 X151.031 Y173.129 E53.1221
G1 X152.521 Y173.589 E53.15322
G1 X154.723 Y174.47 E53.20055
G1 X156.394 Y175.368 E53.23841
G1 X157.359 Y176.171 E53.26346
G1 X157.49 Y176.553 E53.27152
;TIME_ELAPSED:278.037430

Please,please, please, any help would be gratefully appreciated.
Thanks

[rburema]

@enceegee Take a look at these lines:

;added code by post processing
;script: PauseAtHeight.py
;current z: 5.04
;current height: 5.04

This means that you've got a post-processing script 'on'. You can easily see that if there's a little extra icon next to the slice-button area. If you remove/disable the post-processing script everything should be fine.

[enceegee]

Brilliant, you are a hero, thank-you so much.

Now, out of curiosity, after having deleted that script, the little icon has dissapeared. Should I be daft enough to want to play with scripts in the future, how do i get the icon back?

[enceegee]

OK, I just found it on the menu bar.
Thanks again.

[rburema]

@enceegee You're welcome :-)

Haha, I was just writing this reply, so if anyone else needs this, here it is:
You can play with post-processing scripts by the menu. Just select 'Extensions > Post Processing > Modify GCode'. A window will appear with a button to 'Add a script'. Select the appropriate script for your situation (or curiosity). Each script will have a number of parameters you can change/play with. Careful though! They stay on between slices and even between restarts of Cura!

[rdoyle1978]

I can’t help as to why the code is being added, but I found that a lot of times the issue went away when I simply rotated my stl 90 degrees on the print bed.

-Rob Doyle

On Feb 17, 2020, at 6:54 AM, enceegee [e-mail] wrote:


I realise this is an old thread but hopefully someone is still reading it and can help me. This issue (wait for user...) is driving me mad! It has only occured since 'upgrading' to Cura 4.4.1. I have printed out loads of objects before the upgrade, all OK, and I have printed out quite a few different objects since the upgrade, all work fine - except 1 - which was fine before the upgrade.
It always stops in exactly the same place 64%, which is layer 40 out of 66. I have tried all the above suggestions i.e. change temp, turn object, etc. All of which make no difference.
I have examined the Gcode and I can see that between the layer 40 text and the layer 41 text there is about 20 lines of extra text that does not appear anywhere else in the program. (see below)
I have edited out the 13 lines above 'layer 41' (the five lines above that were already edited out) and it works fine.

So my question is:- why does Cura add these extra lines here and how do I stop it doing it?

This is a tiny object but still takes up 43 pages of text, so anything bigger could take up 100's if not 1000's of pages which I do not want to have to search through looking for obscure code before I print anything!

Part of the code with the offending lines:- (It is the lines immediately above ";LAYER:41")

;LAYER:40
;MESH:Balcony Chair.stl
G0 F9000 X157.49 Y176.553 Z4.92
;TYPE:WALL-OUTER
G1 F600 X156.473 Y175.622 E50.9925
G1 X154.755 Y174.636 E51.03203
G1 X152.528 Y173.705 E51.0802
G1 X150.002 Y172.913 E51.13303
G1 X147.419 Y172.336 E51.18585
G1 X145.024 Y172.029 E51.23404
G1 X143.719 Y172.025 E51.26008
G1 X143.764 Y171.859 E51.26351
G1 X145.138 Y171.902 E51.29094
G1 X147.48 Y172.238 E51.33816
G1 X150.027 Y172.819 E51.39029
G1 X150.696 Y173.025 E51.40426
G1 X152.434 Y166.54 E51.53824
G1 X159.775 Y168.507 E51.68991
G1 X159.685 Y168.845 E51.69689
G1 X152.682 Y166.969 E51.84157
G1 X151.031 Y173.129 E51.96884
G1 X152.521 Y173.589 E51.99996
G1 X154.723 Y174.47 E52.04729
G1 X156.394 Y175.368 E52.08514
G1 X157.359 Y176.171 E52.1102
G1 X157.49 Y176.553 E52.11826
;TIME_ELAPSED:272.161952
;TYPE:CUSTOM
;added code by post processing
;script: PauseAtHeight.py
;current z: 5.04
;current height: 5.04
M83 ; switch to relative E values for any needed retraction
G1 F300 Z6.04 ; move up a millimeter to get out of the way
G1 F9000 X190 Y190
G1 F300 Z15 ; too close to bed--move to at least 15mm
M104 S0 ; standby temperature
M0 ; Do the actual pause
M109 S190 ; resume temperature
G1 F300 Z6.04
G1 F9000 X157.49 Y176.553
G1 F300 Z5.04 ; move back down to resume height
G1 F2700 ; restore extrusion feedrate
M82 ; switch back to absolute E values
G92 E52.11826
;LAYER:41
;MESH:Balcony Chair.stl
G0 F9000 X157.49 Y176.553 Z5.04
;TYPE:WALL-OUTER
G1 F600 X156.473 Y175.622 E52.14577
G1 X154.755 Y174.636 E52.1853
G1 X152.528 Y173.705 E52.23347
G1 X150.002 Y172.913 E52.2863
G1 X147.429 Y172.338 E52.33891
G1 X145.024 Y172.029 E52.3873
G1 X143.719 Y172.025 E52.41334
G1 X143.764 Y171.859 E52.41678
G1 X145.138 Y171.902 E52.44421
G1 X147.468 Y172.236 E52.49118
G1 X150.027 Y172.819 E52.54356
G1 X150.696 Y173.025 E52.55753
G1 X152.434 Y166.54 E52.69151
G1 X159.775 Y168.507 E52.84318
G1 X159.685 Y168.845 E52.85016
G1 X152.682 Y166.969 E52.99484
G1 X151.031 Y173.129 E53.1221
G1 X152.521 Y173.589 E53.15322
G1 X154.723 Y174.47 E53.20055
G1 X156.394 Y175.368 E53.23841
G1 X157.359 Y176.171 E53.26346
G1 X157.49 Y176.553 E53.27152
;TIME_ELAPSED:278.037430

Please,please, please, any help would be gratefully appreciated.
Thanks

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Ghostkeeper]

I can’t help as to why the code is being added, but I found that a lot of times the issue went away when I simply rotated my stl 90 degrees on the print bed.

That's most likely because the original height at which it was pausing is then above the highest layer of the print.

I'll close this issue then, since it seems that the printer is just being paused by the pause at height script. The printer is then waiting for the user to press "continue" after he did whatever he needed to do during the pause. The pause at height is added to Cura by the user, most likely for a previous print.

[Ghostkeeper]

Reading other forum threads on Thingiverse, Reddit, etc. it seems that this is most likely a firmware bug. Geeetech seems to have this problem too and there's one guy here that has a decent analysis of why it could be happening: https://www.reddit.com/r/3Dprinting/comments/4qbi1s/waiting_for_user_pause_in_print/d4s4oft/

His analysis is that the g-code stream from the source (being SD card, Octoprint or USB cable) is interpreted before it's all arrived. As a result, commands like M104 S200 (heating up nozzle) can be interpreted before they're complete, as M1. M1 is a command to pause the print.