Marlin pauses and displays "wait for user..." after M190/M109

[qwertyharry 0]

I'm reposting this as a topic in Marlin, now that I have realised how the ulticontroller interfaces with Marlin. I'm using Marlin configured to use a heated bed via Daid's Marlin builder in December 2012.

I have been experimenting with print start gcode and put together the following to extrude a bucket of plastic in a nice fat line to ensure a properly primed print head.

When I load this file into pronterface and hit print, it works as expected, but if I load it onto the SD card and print from there, it pauses midway and displays "Wait for user..." on the Ulticontroller LCD until I press the button on the front, then it continues, just like if it had received an M0 or M1.

The point at which it pauses like this is sometimes when the bed reaches temp on the M190, sometimes after the M109, and sometimes it makes it to the next coommand after that (G1 Z1) and then pauses. Anyone have an idea of what could be causing this? I have never seen this before, even though I am only using the same commands which are normally spat out by Cura and Kisslicer without issue.

I have trawled through the Marlin source and the only reference to the "wait for user..." message is the lcd print in response to M0 and M1. Can't work out where these commands could be coming from???

M92 E880.000

G28 X0 Y0 ;home XY

G90 ;Absolute positioning

G21 ;set units to mm

G92 X0 Y0 E0 ;set axis positioning to X,y to 0, E to 0

G1 X120 ;move to x =120

G28 Z0 ;home Z

G92 Z0 ;reset Z value

;

;

;set temps

M190 S80 ;set bed temp and wait

M109 S230 ;set hotend temp and wait

;

;

G1 Z1 ;raise Z to 1

G1 X90 E6 F500 ;controlled movement using feed (F)

G1 X30 E20 ;controlled movement using feed (F)

;

G28 X0 Y0 Z0 ;home XYZ

G92 E0 ;reset extruder value to 0

 

[gr5 2,071]

I'm thinking the editor you are using is using multibyte character set.

Copy your gcode into the paste buffer, paste it into notepad, then save it from notepad. I don't think notepad supports multibyte characters hopefully.

What editor are you using? - most have the ability to convert to ascii 8 bit character set.

 

[Daid 304]

There is a bit of an odd behaviour in Marlin where it sees a "M" as a "M0" (same for a "G" as a "G0") this might be your cause. Not sure how, but it might help a tiny bit, as Marlin is seeing an M somewhere.

 

[qwertyharry 0]

Thanks for the replies guys.

After quite a lot of trial and error, then trawling through marlin code, then more trial and error, it seems it was caused somehow by the fact that I had the "watch" box ticked in pronterface. I have always done this before without problem, but somehow with my new prefix gcode I get the bug described above, every time.

Now that I am not "watching" with Pronterface, no problems.

 

[zoev89 73]

I have exactly the same problem when printing from SD card when the doodle3d is connected. After heating the hotend it is always displaying "wait for user..." Seems the error is still there. The question is, is it the doodle3d or a bug in the marlin software that is triggered somehow. Given this post above it looks like it is a marlin issue when the temperature is monitored. Unfortunately I can't turn off the doodle temperature monitoring... (to my knowledge)

See also my post

http://umforum.ultimaker.com/index.php?/topic/10278-doodle3d-and-starting-a-print/

 

[zoev89 73]

Ok I went into the code of Marlin and Daid was right, there is some weird behavior with the M0 and M1 commands. Actually they are not the cause but the commands that generate a wait for user message (actually the only ones if I am not mistaken). It is not in the M0,M1 commands but the handling of the M109 and M190 commands. Heated bed heating and extruder heating. I studied the main loop of the marlin code and during the M109,M190 calls the main tread is blocked by wait for the target temperature. This also means that the serial communication receive buffer is not emptied during that time. If there is a application requesting temperature status (M105 calls) these calls will not be executed untill heating is done. It means that the serial input buffer could overrun during that time causing miss interpretation of the received serial commands leading to strange behavior and in my case often M1 detection causing the user wait message. By studying the behavior of the Marlin (don't know if this is documented or where to look) I found that every serial command you give should be acknowledged with ok at which a new command can be transmitted. So the solution is that after heating you flush the receive serial buffer and then send the ok command. So this is my 1 line addition to the code of M109 (simular thing for M190):

LCD_MESSAGEPGM(MSG_HEATING_COMPLETE);

tarttime=millis();

previous_millis_cmd = millis();

MYSERIAL.flush(); // Eric remove received possible overflowing data

In my case this resolves the problem quite well. I can now print from wifi (doodle3d) and SD card while the doodle3d is connected. So how do I proceed to propose this change in the Marlin software?