Bug in SDCard Stop Print?

[anon4321 16]

Has anyone else seen this behavior: You are printing from the SD Card and need to abort the print. So you click Stop Print on the UltiController. However, the print doesn't stop and instead the extruder goes in some random direction and crashes into something.

This is particularly noticeable when using the leveling circles gcode from:

http://umforum.ultimaker.com/index.php?/topic/5951-calibration-utility-leveling-ringsgcode/

I was looking for the reason in the firmware and as near as I can tell, the Stop Print routine discards the planned moves but it doesn't discard any cached commands. Based on the default buffer size, there could be 3 commands in the buffer from the SD file. For things like the leveling circles where one command could represent a a lot of moves, using stop print can really screw things up.

Can anyone confirm?

 

[zoev89 73]

I have also seen that, when you stop you have to wait until it actually stops (buffer runout as you also have seen in the code) and if you stop again (being inpatient) the head crashes into the sidewall so you quickly powercycle.

 

[pm_dude 27]

Is this happening only on the UMO?

I haven't seen this on the UM2. It does take some time before aborting to clear the buffer of commands but I can't abort the print more than once.

 

[anon4321 16]

I can't speak to the UM2 as I don't own one.

What I can say about the UM1 is the code definitely discards preplanned moves in an attempt to stop the print. However, I think that cached gcode isn't cleared properly.

So for example when printing the circles from the SD, clicking stop print immediately causes the next circle to start printing often in a way that causes it to be printed offset until the endstops are hit.

 

[zoev89 73]

> causes it to be printed offset until the endstops are hit.

I guess that is what has happened to me a couple of times. And since the right and back endstops are software in my case it just bangs the sides (only have the homing endstops).

 

[anon4321 16]

Part of the problem appears to be in the implementation of the G2/G3 commands for arcs. It leaves the main loop and generates tons of tiny moves to approximate the arc. Within this loop, it isn't checking for the stop even though the stop discards some planned moves. Changing the code to check is going to be ugly....

Worse yet, I think that this loop doesn't process the endstops which explains why stopping the print during the arcs causes the extruder to crash into the endstops.

Does anyone know if the Cura slicer uses the G2/G3 gcodes? If not, I don't think it's worth the trouble to fix it.

 

[pm_dude 27]

I never seen those so far.

 

[anon4321 16]

I pinged Daid and he says no it does not use the arc gcode commands.

So I'm not sure it's worth the effort to fix.

 

[drayson 75]

Has anyone else seen this behavior: You are printing from the SD Card and need to abort the print. So you click Stop Print on the UltiController. However, the print doesn't stop and instead the extruder goes in some random direction and crashes into something.

This is particularly noticeable when using the leveling circles gcode from:

http://umforum.ultimaker.com/index.php?/topic/5951-calibration-utility-leveling-ringsgcode/

I was looking for the reason in the firmware and as near as I can tell, the Stop Print routine discards the planned moves but it doesn't discard any cached commands. Based on the default buffer size, there could be 3 commands in the buffer from the SD file. For things like the leveling circles where one command could represent a a lot of moves, using stop print can really screw things up.

Can anyone confirm?

 

Can confirm this behavior but not at circles - happened at my UMO twice last weekend...

printed an angle so no circles at all...

Beside this, on abort, the z-stepper is not released in some cases so it makes it difficult to move the platform down manually - anyone discovered this too?