• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

Error: in file macro line 7: G1: insufficient axes homed

Scheduled Pinned Locked Moved Solved
General Discussion
2
6
200
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    Joel
    last edited by Joel 5 Apr 2024, 14:53 4 May 2024, 02:23

    Hi,

    I'm getting this error at the end of every print,

    Error: in file macro line 7: G1: insufficient axes homed

    I am not sure where it is coming from. I made a very simple gcode file,

    G90
    G1 Z10 X175 Y175 F6000
    M84

    It does its thing and then gives me the same error.

    Any ideas where I should look?

    Thanks
    Joel

    undefined 1 Reply Last reply 4 May 2024, 06:04 Reply Quote 1
    • undefined
      OwenD @Joel
      last edited by 4 May 2024, 06:04

      @Joel
      What is in your stop.g?

      undefined 1 Reply Last reply 4 May 2024, 14:28 Reply Quote 0
      • undefined
        Joel @OwenD
        last edited by Joel 5 Apr 2024, 14:31 4 May 2024, 14:28

        @OwenD

        There is a G1 move at line 7 but I thought stop.g was only called when you cancel a print, not at the end of a print.

        This is a new behavior for 3.5.1.

        OK - I renamed my stop.g to something else and the error went away. I'm not sure how to fix this. Why is this now being called at the end of a print when in 3.4.x it seemed not to be ( never saw this error before )?

        undefined 1 Reply Last reply 4 May 2024, 14:43 Reply Quote 0
        • undefined
          Joel @Joel
          last edited by 4 May 2024, 14:43

          OK, I think I found more stuff wrong in the way I'm doing things. My slicer is set up to move the head to where I want it after a print, then I turn off the steppers. I found that turning off the steppers is causing the issue.

          What I will do is remove the ending moves from my slicer and let stop.g do it.

          Still not sure why I did not see this in 3.4

          So far about every update exposes an issue, so far it has been things I have set up that are not quiet right.

          So now 4 printers later and numerous clean ups ( each new printer started with the previous printers files ), I think my scripts and setups are zeroing in on being right.

          Thanks
          Joel

          undefined 1 Reply Last reply 4 May 2024, 20:20 Reply Quote 1
          • undefined Joel marked this topic as a question 4 May 2024, 14:52
          • undefined Joel has marked this topic as solved 4 May 2024, 14:52
          • undefined
            OwenD @Joel
            last edited by 4 May 2024, 20:20

            @Joel

            You need to read the change logs before doing any update
            In this case
            When a print file completes normally then file stop.g is run automatically even if the print file did not end with a M0 command

            https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-351-stable-changes-since-346

            undefined 1 Reply Last reply 4 May 2024, 23:47 Reply Quote 1
            • undefined
              Joel @OwenD
              last edited by 4 May 2024, 23:47

              @OwenD

              That's easy enough to say, the change lists are sometimes quite long. Unless you have something in mind or it happens to pop in your head while "browsing" through those lists that something might affect you...

              Basically, you don't know, what you don't know.

              In any case, your pointer was right and I was able to sort it out.

              Thanks!

              1 Reply Last reply Reply Quote 1
              1 out of 6
              • First post
                1/6
                Last post
              Unless otherwise noted, all forum content is licensed under CC-BY-SA