Timelapse Enforce Position issue with 0.91

Hi there,
I was super happy to read about the enforce position feature in the 0.91 update.
So immediately gave it a shot! Put position to 150x150 and started printing. After first layer the printhead moved to the position, stayed there a bit and moved back to the part to print. But then suddenly the extruder reversed a good 10cm before it started to print. 
This happened on every layer until I cancelled. Printer moved to picture position, and back and then the extruder reversed the filament out of the printhead at full speed....

does not happen if I do normal timelapse for each layer without enforcing position...

any ideas? Any details I can provide you with?

Keep up the good work with Repetier Server! Love this software :) the enhancements to the touch ui are very nice!

Kind Regards

Comments

  • I have an idea and just hope you have entered bad values where I think. To prevent oozing there are in deed retractions and undo retractions send. The distances are defined in printer configuration->Extruder->General Extruder Parameter. So if you have there 100mm that would be correct.
  • I have Retraction Distance of 3mm and Retraction Distance Long of 40mm (not sure what this is for?) I try change them and see if it helps. Currently still printing w/o timelapse...
  • Can you enable logging when testing. Then you can post the code that gets send at snapshots. Search for  @excludeTimeOn to find an example. Make sit easier to say why extrusion is so high.


  • did not help, I set both retraction distances to 0 to make sure.
    It goes to Photo position, returns to print part, retracts about 50mm and then resumes printing. Any other ideas?
  • Checked the code. When distance is set to 0 it will not add any extrusion move, so gcode as proposed would be helpful to see why firmware thinks there is a retraction. In my head I do not see it so seeing what is in your code around the problem might make it clearer, like a unexpected G92 E0 setting extrusion position to wrong position.
  • I have exactly same issue? Long retraction and undo lenghts are set to 6mm but in real life filament is retracted about 40 to 50 mm's..? I hope that someone finds a solution/ explanation for this.
  • My Ultimaker 2 printer also has this problem with timelaps.
  • We found one reason. In absolute extrude position mode the E value is restored wrong causing next extrude to retract. Slicing with relative coordinates are a temporary solution until we offer a fixed solution.
  • I can confirm that with relative extrusion enabled (checkbox in S3D) the new timelapse function works like a charm.

    https://www.youtube.com/watch?v=ckbzS5plnw0
  • I can confirm that with relative extrusion enabled (checkbox in S3D) the new timelapse function works like a charm.

    https://www.youtube.com/watch?v=ckbzS5plnw0
    I tried relative extrusion and on my Ultimaker 2 the nozzle stops for a second in the specified coordinates
  • edited February 2019
    Alexey said:
    I can confirm that with relative extrusion enabled (checkbox in S3D) the new timelapse function works like a charm.

    https://www.youtube.com/watch?v=ckbzS5plnw0
    I tried relative extrusion and on my Ultimaker 2 the nozzle stops for a second in the specified coordinates
    Thats the idea. For each snapshot the head will be moved to the given coordinates , snapshot is taken and then moves back to where it was to resume printing. Thats how you get the consistant timelapse effect.
  • edited February 2019
    Alexey said:
    I can confirm that with relative extrusion enabled (checkbox in S3D) the new timelapse function works like a charm.

    https://www.youtube.com/watch?v=ckbzS5plnw0
    I tried relative extrusion and on my Ultimaker 2 the nozzle stops for a second in the specified coordinates
    Thats the idea. For each snapshot the head will be moved to the given coordinates , snapshot is taken and then moves back to where it was to resume printing. Thats how you get the consistant timelapse effect.
    In addition to the problem with the nozzle stop, my video came out as usual, with a moving head.
    Coordinates are given in the center of the bed. When the nozzle stops, the plastic melts and there are defects on the model  https://youtu.be/Prqz9_XzSis


  • IF you use snapshot position, the position must be selected outside the print to prevent the melting. For ultimaker it is not really required as object stays where it is. Prusa like printers with moving y axis are more the target of the feature. Or if you want no head motions in print. Here webcam has 0.7 seconds to send image to server as then motion starts again. Next release will have it 0.8s. Maybe I make it a variable for webcams reacting slower or faster.
  • Repetier said:
    IF you use snapshot position, the position must be selected outside the print to prevent the melting. For ultimaker it is not really required as object stays where it is. Prusa like printers with moving y axis are more the target of the feature. Or if you want no head motions in print. Here webcam has 0.7 seconds to send image to server as then motion starts again. Next release will have it 0.8s. Maybe I make it a variable for webcams reacting slower or faster.
    My server is installed on a Ubuntu server with an Intel Atom processor and a discrete video chip and fast action- camera. On previous versions of the server there was no problem with delayed recording. Maybe I need to disable FFMPEG?
  • This is not ffmpeg related. We query the jpg url after sending 24 times M400 to be sure printer has stopped moving. Then start making snapshot in separate thread and send firmware to wait 700ms G4 P700. Can you verify if both commands do what is expected on ultimaker? You said there is a pause, so G4 seems to work.

    To test M400 send some long slow moves and then
    M400
    M114

    If you see coordinates in log before move is finished M400 was ignored.

    We send 24 M400 to flood input buffer so if we receive a ok we know moves are through. This means ultimaker buffer must be smaller then 24 * Nxxx M400*23 which will be at least 13 byte so 24*13 = 312 byte. Not sure how much Ultimaker buffers, but marlin does normally only 127 byte in input queue. Also it is more important that host would not send them according to his queue size, so guess size is not the problem. Only if M400 does wait for end of moves or not. More exactly server checks marlin.xml and sends this command

    <command type="waitEndOfMoves">M400</command>
    so you can even modify it if does not work. 

  • Hello, i just have mount my ender 3 pro and try a time laps with repetier and fixed position. I got the same issue : extruder reversed a good 10cm before it started to print.

    Just to say that switch to relative position help a lot thx :)

Sign In or Register to comment.