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

    Minor problem with access to object model after G1... commands

    Scheduled Pinned Locked Moved
    General Discussion
    2
    3
    157
    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.
    • hlwerschnerundefined
      hlwerschner
      last edited by

      I just switched to 3.50-rc1 from previous 3.46 release and followed needed changes in my macros (change to macro parameters...) until I again was able to start my 3d printer.

      But some spurious abort in a few macros (home*.g, G32 ...) forced me to look closer into my code to isolate a new behaviour in the (MB6HC in SBC mode with a PI 3B):
      In several macros a use of a G1 move command for any axe(s), followed by a M400 command to wait for the movement completion and directly follwed by an access to the object model variables to check for the recorded coordinates was not always OK. The code looks something like:

      G1 H1 Z{var.totalZ} F300           ; slowly touch again
      M400                               ; wait for command completion
      var currentZ = move.axes[var.axis].machinePosition
      

      In Rel 3.46 (and before) this code worked fine and "currentZ" did reliably hold the actual coordinate (assuming that no hardware error had happened).

      In the new release, the use of M400 obviously does NOT suffice to allow a secure access to the correct synchronized values in the move.axes[*].machinePosition values!
      A workaround was to add another "G4 P500" after the M400 command to wait for another 500msecs (a guess which worked) ... but this is akward and just a strange workaround.

      My questions:
      1/ is this behaviour of 3.50 something that is already known and worked on?
      2/ is there a solid and secure solution to access the machinePosition programmatically AND RELY on the correct value?
      3/ if there is not a ready-to-use solution, is it feasible to look/wait for another command line M400/G4 (or a variant of it with special parameter(s)) that allows to "wait for the objectmodel to be in sync"?

      I expect that some of you do not see the need for a solution to this behaviour of the software but believe me, I discovered that most of my problems to achieve good printing results were solved when I assured that the power up, initialisation and CALIBRATION of my printer were done with checking all possible missbehaviour in start-up macros and hardware-wrong-use/processing until EVERYTHING was checked and running properly. I may be a bit overcautious with my macro coding and error handling but more than 45 years of software development have proven me that this is the only way to have software that has a looooong lifetime and works as required. As long as the object model provides an access within the macro coding and is not only a documentary help to clearify how the RRF may work, a reliable access to its values is mandatory (or at least an indicator/semaphore flag should show if the model is in sync with the board/hardware or when it is not). I do understand that the RRF software is a multitasing thing where the object model is somehow handled independently fromt kernel GCode processing, but this is nevertheless something that can be handled properly!

      I hope for some positive feedback 🙂

      dc42undefined 2 Replies Last reply Reply Quote 0
      • dc42undefined
        dc42 administrators @hlwerschner
        last edited by dc42

        @hlwerschner thanks for your report. Does the following also give you incorrect results:

        G1 H1 Z{var.totalZ} F300           ; slowly touch again
        M400                               ; wait for command completion
        echo move.axes[var.axis].machinePosition,var.totalZ
        

        i.e. does it sometimes echo two different values, assuming no tool Z offset or workplace coordinate offset?

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • dc42undefined
          dc42 administrators @hlwerschner
          last edited by dc42

          @hlwerschner I confirm this is a problem. The Z axis machine position reported in the object model is out of date during a move that includes Z. It's also not updated to the final position until a short time after the move is completed. I will investigate it.

          Edit: created https://github.com/Duet3D/RepRapFirmware/issues/921 and https://github.com/Duet3D/RepRapFirmware/issues/922.

          dc42 created this issue in Duet3D/RepRapFirmware

          closed Machine Z axis position report incorrect #921

          dc42 created this issue in Duet3D/RepRapFirmware

          closed Axis machine position is not reported live when using an expansion board #922

          Duet WiFi hardware designer and firmware engineer
          Please do not ask me for Duet support via PM or email, use the forum
          http://www.escher3d.com, https://miscsolutions.wordpress.com

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