Jump to content

Bug in SDCard Stop Print?


anon4321

Recommended Posts

Posted · Bug in SDCard Stop Print?

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?

 

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    > 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).

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    I never seen those so far.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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.

     

  • Link to post
    Share on other sites

    Posted · Bug in SDCard Stop Print?

    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?

     

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.7 stable released
        Cura 5.7 is here and it brings a handy new workflow improvement when using Thingiverse and Cura together, as well as additional capabilities for Method series printers, and a powerful way of sharing print settings using new printer-agnostic project files! Read on to find out about all of these improvements and more. 
         
          • Like
        • 7 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...