Jump to content
UltiMaker Community of 3D Printing Experts

Why mixing up axes?


Dim3nsioneer
 Share

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
     Share

    • Our picks

      • Here it is. The new UltiMaker S7
        The UltiMaker S7 is built on the success of the UltiMaker S5 and its design decisions were heavily based on feedback from customers.
         
         
        So what’s new?
        The obvious change is the S7’s height. It now includes an integrated Air Manager. This filters the exhaust air of every print and also improves build temperature stability. To further enclose the build chamber the S7 only has one magnetically latched door.
         
        The build stack has also been completely redesigned. A PEI-coated flexible steel build plate makes a big difference to productivity. Not only do you not need tools to pop a printed part off. But we also don’t recommend using or adhesion structures for UltiMaker materials (except PC, because...it’s PC). Along with that, 4 pins and 25 magnets make it easy to replace the flex plate perfectly – even with one hand.
         
        The re-engineered print head has an inductive sensor which reduces noise when probing the build plate. This effectively makes it much harder to not achieve a perfect first layer, improving overall print success. We also reversed the front fan direction (fewer plastic hairs, less maintenance), made the print core door magnets stronger, and add a sensor that helps avoid flooding.
         

         
        The UltiMaker S7 also includes quality of life improvements:
        Reliable bed tilt compensation (no more thumbscrews) 2.4 and 5 GHz Wi-Fi A 1080p camera (mounted higher for a better view) Compatibility with 280+ Marketplace materials Compatibility with S5 project files (no reslicing needed) And a whole lot more  
        Curious to see the S7 in action?
        We’re hosting a free tech demo on February 7.
        It will be live and you can ask any questions to our CTO, Miguel Calvo.
        Register here for the Webinar
          • Like
        • 10 replies
      • UltiMaker Cura 5.3.0-Alpha 🎄 Tree Support Spotlight 🎄
        Are you a fan of tree support, but dislike the removal process and the amount of filament it uses? Then we would like to invite you to try this special release of UltiMaker Cura. Brought to you by our special community contributor @thomasrahm
         
        We generated a special version of Cura 5.2 called 5.3.0 Alpha + Xmas. The only changes we introduced compared to UltiMaker Cura 5.2.1 are those which are needed for the new supports. So keep in mind, this is not a sneak peek for Cura 5.3 (there are some really cool new features coming up) but a spotlight release highlighting this new version of tree supports.  
          • Like
        • 16 replies
      • New here? Get ahead with a free onboarding course
        Hi,
         
        Often getting started is the most difficult part of any process. A good start sets you up for success and saves you time and energy that could be spent elsewhere. That is why we have a onboarding course ready for
        Ultimaker S5 Pro Bundle, Ultimaker S5, Ultimaker S3 Ultimaker 2+ Connect.   
        They're ready for you on the Ultimaker Academy platform. All you need to do to gain access is to register your product to gain free access. 
        Ready? Register your product here in just 60 seconds.
          • Like
        • 14 replies
    ×
    ×
    • Create New...