Jump to content

Why mixing up axes?


Dim3nsioneer

Recommended Posts

Posted · Why mixing up axes?

Due to some tests I did today for checking a faster way of the retraction and priming procedure (cf. http://umforum.ultimaker.com/index.php?/topic/4094-raised-edges/page-2&do=findComment&comment=33433) I had a look into the Marlin planner (planner.cpp).

Maybe I got it wrong... is it true that there is only one velocity (I'm aware of nominal speed vs. initial speed vs. final speed of the block) calculated per block for all four axes (X,Y,Z,E)?

What kind of strange reason is there to prevent parallel independent actions of e.g. the x/y axes and the extruder?

If you use a G0 or G1 with both X/Y and E specified, the lower jerk value (which is the one of the extruder) slows down the x/y movement!

If I look at this part of the Marlin code I get the impression it is somehow a bit crappy difficult to understand (edited due to inadequate wording). It definitively has not the same level (also in terms of documentation) as other parts of Marlin which are well commented und well structured.

I.m.h.o. blocks (the trapezoids respectively) should be calculated individually for each of the four dimensions X,Y,Z,E with a coupling between X and Y. But to implement this properly, it would need quite some effort I fear...

 

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    It is VERY IMPORTANT for the X,Y,Z,E axis to all 4 move linearly. In a straight line. If the extruder ran max speed for a block it would finish early and you would get overextrusion for the begining and zero extrusion for the end of every line segment.

    One way to think of this is that all moves are in a straight line in all 4 dimensions.

    Even the acceleration is matched in all 4 axis so that it is a straight line even during acceleration and deceleration.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    By the way there are many contributors to Marlin including some very smart people. That code you looked at has been looked over by me and probably 100 other people. It seems strange at first but it is pretty well done. It even looks 12 segments/blocks ahead of time so that it doesn't have to stop. For example if printing a circular path the old firmware (before marlin, before sprinter) would come to a complete stop at every vertex. The new software hardly slows down at all due to the "jerk" setting which isn't jerk but more maximum instantaneous velocity change at a vertex.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    I appologize if I offended anyone... :oops: I didn't mean to...

    I see the way it is written has some serious background. But some more comments in the last third of planner.cpp (they are really great in the first two thirds) might make it a bit easier for a stubborn Marlin-greenhorn like me to understand...

    So, maybe I can get along with tweaking the jerk settings. Otherwise retraction and priming along travel movements look not very nice. Thanks and sorry again!

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    One of the reasons the code is as it is, is because it was derived from grbl. Which had only 1 acceleration setting for all axis.

    Also, you need a coupling between X/Y and E for printing. As you want a certain amount of material evenly spread over a line.

    What you want, is retraction/prime independent of X/Y. A way to properly implement that would be to make a difference between G1 and G0, where G1 has the axis coupled, and G0 not.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    One of the reasons the code is as it is, is because it was derived from grbl. Which had only 1 acceleration setting for all axis.

    Also, you need a coupling between X/Y and E for printing. As you want a certain amount of material evenly spread over a line.

    What you want, is retraction/prime independent of X/Y. A way to properly implement that would be to make a difference between G1 and G0, where G1 has the axis coupled, and G0 not.

     

    I fully agree! Thank you for this nice formulation.

    I'll have to do some homework checking how Marlin comes from the G0/G1 command to the planner routine. This will take some time, I guess.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    These gcodes are from long before 3d printers existed. G1 is supposed to be linear I believe and G0 is just supposed to move the axes in any order (uncoupled). But for Marlin it just does them both the same way. But Cura seems to sometimes use G0 and sometimes G1 as needed.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    These gcodes are from long before 3d printers existed. G1 is supposed to be linear I believe and G0 is just supposed to move the axes in any order (uncoupled). But for Marlin it just does them both the same way. But Cura seems to sometimes use G0 and sometimes G1 as needed.

     

    At least for the last few versions I had the impression Cura uses quite strictly G1 for printing and G0 for travelling. Daid might prove me wrong.

    So the task would be to write a routine for G0 separately... quite a big task.

     

  • Link to post
    Share on other sites

    Posted · Why mixing up axes?

    At least for the last few versions I had the impression Cura uses quite strictly G1 for printing and G0 for travelling. Daid might prove me wrong.

     

    Yes, but that's mostly to increase readability of the GCode. There is no technical reason to do so right now.

     

  • 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

      • 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
      • Ultimaker Cura 5.6 stable released
        Cura now supports Method series printers!
         
        A year after the merger of Ultimaker and MakerBotQQ, we have unlocked the ability for users of our Method series printers to slice files using UltiMaker Cura. As of this release, users can find profiles for our Method and Method XL printers, as well as material profiles for ABS-R, ABS-CF, and RapidRinse. Meaning it’s now possible to use either Cura or the existing cloud-slicing software CloudPrint when printing with these printers or materials
        • 48 replies
    ×
    ×
    • Create New...