Random wait for user input

Has anybody experienced a problem where the TAZ5 will randomly pause the job and “wait for user input”. The job resumes from the LCD panel, however while it is waiting it just sits there and melts a spot in the model. There is no M00 or M01 in the gcode and no plugins are enabled. I can run the same model over again with different results. It may do it zero, one, or more times. It is happening more and more frequently and occurs most often on the first layer. I am wondering if it is getting some erroneous sensor value that is causing it to wait for input?

I am not doing anything special. I have stock firmware for a single extruder. I am printing with cura using the stock ABS medium profile. I see it most often on big models where it should have been printing overnight, but instead is just sitting there.

Are you printing from the SD card or computer using USB? If its from the computer make sure all the power saving features are turned off. Is it connected to the internet? If so try disabling the wireless or wired connection while you are printing.

I am printing from the PC, but it is not going to sleep. Besides, it doesn’t just stop. It actually displays waiting for user input on the LCD.

I am curious and wondering if its losing communication? Flaky or poor connections on the USB cable, I’d swap it out first or before that remove and re-install Cura. What version did you say you are running?

Thanks, I suspect you are right. The same gcode prints reliably from the sd card. So I will try replacing the cable and running it from a different machine.

I am having the same problem. I just got the TAZ 5 last week. I am using CURA. My first few prints went fine. Then yesterday the machine stopped midway through printing but kept drooling filament in place. It seemed to be “paused”. I noticed that the LCD control screen said “WAIT FOR USER”. I pressed the control knob and the print resumed. This has occurred more and more frequently since then. This morning I started a print and within 15 minutes it paused while still laying down the brim. It seems to me to be some sort of a hiccup in the processing of the g-code rather than a wiring or mechanical issue.

I am having the same issue with my Taz 5.
I have been a programmer for many years.

Thoughts:

  • I have a very fast, 3.6GHz quad-core Windows 10 PC with 16GB RAM, so I don’t think it related to a system bottleneck.
  • When getting the “Waiting for User Input” message, pressing the control button continues the print.
  • I’ve printed lots of stuff without a problem - over a hundred hours.
  • The message only occurs on large X,Z axis prints - like a flat portrait. For example, it happened twice on a 14cm x 16cm print. Interestingly, it happened during the first couple layers while drawing the longest diagonal lines. This is consistent with a previous user’s comment: “I see it most often on big models where it should have been printing overnight, but instead is just sitting there.”

My theory is this: While drawing these long diagonal lines, the TAZ 5 does not receive communication over the USB, a waiting period expires and the TAZ incorrectly interprets that as a printing having been paused by the user. This problem does not occur when using the SD card because a USB waiting period is not used.

Thoughts?

Is your computer power management setting set to “High Performance” under control panel? The default is “Balanced” which allows the system to power down USB ports it thinks are unused. Sometimes it doesn’t puck up serial communication over those USB ports and powers them off. If you set the power settings to High performance or set “USB ports never enter sleep mode” under the advanced settings, it may improve that particular issue

Windows 10 has issues with USB ports. Even if you are printing off the SD card if the USB cable is still plugged in it can still control the printer, happens even on Win 7.

In response to piercet and the suggestion to set “USB ports never enter sleep mode”:

It won’t hurt anything, but I don’t think this will fix the problem.

The computer’s USB port only enters “USB Selective Suspend” by request of the device driver.
http://answers.microsoft.com/en-us/windows/forum/windows_vista-hardware/what-does-usb-selective-suspend-mean/71fa747b-914f-4d17-b476-cf4bb1bb783c?auth=1

The Taz uses the standard serial driver rather than its own driver:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx?f=255&MSPPError=-2147217396

The standard serial driver does not appear to make USS requests:
http://www.osronline.com/showThread.CFM?link=203044

So… I suppose it’s worth a try, but I suspect that another mechanism is causing the “wait for user input” problem.
Does anyone know the specific TAZ firmware mechanisms that prompt that message?

Yes. This message is stored in MSG_USERWAIT, and the only way to call it is a M0 or M1 command without a time argument. If you can’t find a M0 or M1 in gcode and it only happens when printing over USB with Cura, there is a high chance it’s a bug in Cura…

I can confirm the observations of biscutx. The pause for user input happens on long diagonal lines. The machine has all power saving features turned off. I have tried it with 2 different cables and 2 different windows machines. I see the problem with all combos, although it is still fairly random. I have switched to printing large prints from the SD card to avoid the issue, but that is a bit of a hassle.

Did you also try printing with pronterface or only with cura?

cura only.

As I said before, I bet it would run fine with pronterface. If somebody give this a try conforming this, you may describe the problem in one of the cura development threads here.

I agree, it looks like a Cura problem. My model pauses twice and there are two instances of “M1” in the g-code. There’s no reason for that code to be in there. I’d say it’s a bug.

I recently experienced this for the first time. I was using CURA on a relatively large print turned 45 degrees from square aka diagonal. I started the print over though and it worked fine the next time.

I registered just to chime in.

I am using simplify 3d as my slicer and I having the same issue. I was just about to try using an SD Card.

Such a frustrating mess. Some parts get farther than others.

I am about to investigate power saving features as a culprit but I doubt that is the case. It has only been doing this on very long and wide flat prints.

After post edit: I already have the USB configured properly. I am going to mess with Flow Control of the Rambo driver in device manager. I used to have a modem back in the old days that would have connection quality issues if flow control was set to off. I will try with hardware first then software or I will just change the UART. http://www.moxa.com/resource_file/509820091121333.pdf

Keep me posted on your own findings guys.

Hi everyone,
I am a new Lulzbot user and I am experiencing this same problem. I have a stock Taz5 running Marlin 2015Q3 and Using Cura Lulzbot edition 18.03 connected with a USB cable to a computer running Windows7. I have not tested with any other slicer or printer host software.

I have been printing round the clock, without major problems since I received the printer about 7 weeks ago. The first time I experienced this was on a part 250mm long in the x-axis, the printer stopped on infill of the first layer, just after finishing a long x-axis run. I then turned the part 90 degrees and it printed fine. Today, printing a similar part, also 250mm long, this time in the y-axis, it stopped on infill of the fourth layer, just after finishing a long y-axis run. After reading this forum today, I checked the g-code and there are no M0 or M1 commands.

Can anyone tell me if this problem has been solved?

In “http://download.lulzbot.com/Software/Cura/Packages/ “there is a version 18.04-67db. Should I install this version of Cura?

Lastly I am just speculating on something I really know nothing about: Since the Cura Lulzbot edition is based on the Ultimaker version, and the Ultimaker has a printbed that is smaller than 250mm. Can there be any relation to this problem?

You say long movements. Maybe it’s some kind of timeout - the printer is not responding during the move. Cura may think there is a connection problem and closes the serial connection?

To test this, you may reprint your big part. Before you start the print, send “M111 S8” to you printer. This way it will not actualy extrude and you don’t need to feed it with filament or heat up something.
When the printer stops, try to send commands to it. If the connection is broken, the printer will not respond. If the printer is responding, Cura is simply not longer sending code lines…
You might use “G1 X10” for your test, this moves the X axis 10mm before the endstop.