Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Real Time Position

    Duet Hardware and wiring
    m114 motion
    8
    17
    542
    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.
    • featheryjam2
      featheryjam2 last edited by

      Hi,
      I'm wondering if there's a way (gcode) to get real time position of the tool head? At the moment, I'm using M114, but that only gives the position of the last completed motion.

      1 Reply Last reply Reply Quote 0
      • Phaedrux
        Phaedrux Moderator last edited by

        It's not a closed loop system so I don't think you can get actual Real Time Position, just last commanded position as displayed on the PanelDue or DWC.

        Z-Bot CoreXY Build | Thingiverse Profile

        arhi 1 Reply Last reply Reply Quote 0
        • baird1fa
          baird1fa last edited by

          Wouldnโ€™t there be something? If you pause a print it stops where it is and reports the coordinates of where it stopped. Or does it have to complete a move before it stops?

          Phaedrux 1 Reply Last reply Reply Quote 0
          • Phaedrux
            Phaedrux Moderator @baird1fa last edited by

            @baird1fa I believe it has to complete the current move. Which is usually pretty short. Same goes for power loss recovery.

            Z-Bot CoreXY Build | Thingiverse Profile

            baird1fa dc42 2 Replies Last reply Reply Quote 0
            • baird1fa
              baird1fa @Phaedrux last edited by

              @Phaedrux that is good to know. I have the ability to print some pretty long moves almost 400mm. So it would suck to need to pause midway.

              Phaedrux 1 Reply Last reply Reply Quote 0
              • Phaedrux
                Phaedrux Moderator @baird1fa last edited by

                @baird1fa You're in a good position to test what actually happens then.

                Z-Bot CoreXY Build | Thingiverse Profile

                baird1fa 1 Reply Last reply Reply Quote 0
                • baird1fa
                  baird1fa @Phaedrux last edited by

                  @Phaedrux Iโ€™ll give it try next time I have the opportunity.

                  1 Reply Last reply Reply Quote 0
                  • arhi
                    arhi @Phaedrux last edited by

                    @Phaedrux said in Real Time Position:

                    It's not a closed loop system so I don't think you can get actual Real Time Position, just last commanded position as displayed on the PanelDue or DWC.

                    Dunno if RRF can report the current position (real-time), but RRF certainly knows where it is even in the middle of the move :). It is just a question if we can extract this info somehow ๐Ÿ˜„

                    Dunno why I'd need that info on a 3D printer where moves are rather quick (both fast and short) but it is something rather useful on a CNC where moves take time (as they are both long and slow). If you look at GRBL driver (or for e.g. smoothieware running in GRBL mode) it will real time report position during a move (both on the LCD and streamed trough serial port). It is rather useful when operating a CNC.

                    Looking at the status data during a long move

                    /rr_status:

                    5faac625-4a20-45ba-8d9f-99f23ce63f73-image.png

                    eb9dcdaf-f7fb-432e-884b-c311eb635d5a-image.png

                    So as you can see you can read "current real-time" position of the axes in coords.machine[axisnumber] ๐Ÿ™‚

                    now if you quickly refresh it it does not update non stop, only every x seconds, probbly web interface is caching something dunno, I'm sure dc42 can add more details ๐Ÿ™‚ but looks like data is already available. You can fetch model using G-code too (something like M409 F"v,n,d3" K"move.axes[0]" ) but the problem is that the G-code will have to wait for existing move to finish to return result so not very useful

                    bot 1 Reply Last reply Reply Quote 0
                    • dc42
                      dc42 administrators @Phaedrux last edited by

                      @Phaedrux said in Real Time Position:

                      @baird1fa I believe it has to complete the current move. Which is usually pretty short. Same goes for power loss recovery.

                      A normal pause waits for the current move to complete, but a power loss pause doesn't.

                      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 1
                      • bot
                        bot @arhi last edited by

                        [...] RRF certainly knows where it is even in the middle of the move [...]

                        Is this the case, though? It seems like the problem of quantum physics observing the speed and location of a particle: if you know the speed, you can't know for sure the position, and if you know the position, you can't know for sure the speed.

                        In an open-loop system, you can know generally kinda what's going on, but to "ask" for the position of the stepper at a certain time in the middle of a move seems impossible. By the time your question has reached the "ears" of the machine, the time you were asking about has long passed. If the machine told you the position for whatever moment it happened to be, by the time it replied to you it would be incorrect.

                        Though, it could probably be close enough. ๐Ÿ˜›

                        *not actually a robot

                        arhi 1 Reply Last reply Reply Quote 0
                        • arhi
                          arhi @bot last edited by

                          @bot said in Real Time Position:

                          In an open-loop system

                          It does not matter if it's open or closed loop, you know where you want to be and where the system is if no steps are lost. Each step signal you send you know exactly where you are. If steps are lost the whole system becomes "unknown" and you will not know the position at the end of the move too.

                          bot 1 Reply Last reply Reply Quote 0
                          • bot
                            bot @arhi last edited by bot

                            @arhi Yeah, I was mostly making a joke.

                            It would be possible to get a close-enough position, but it would never be EXACTLY correct. That's fine.

                            However, implementing the feature to interrupt everything in order to probe position might be problematic. AFAIK, the way the code works, it's not as simple as "monitoring" for the position, you'd have to be like "hey sorry to bother you, but can you stop what you're doing for a moment and tell me where you are. Thanks!" And so that's probably a lot of effort for relatively little gain.

                            *not actually a robot

                            arhi 1 Reply Last reply Reply Quote 0
                            • arhi
                              arhi @bot last edited by

                              @bot dunno how the movement part is organized and if you can see externally what's going on there or not.... and yes, imo not very useful for fast short moves as we have with 3d printing but it is something quite expected on the cnc. I do not have enough experience to say how that's done normally, does linuxcnc/grbl/tormach..split the long slow move into shorter pieces and report position between them or it is done differently... but I see RRF in the rr_status have split the position of "named axes" (xyz) and "real position" (machine), it is just a question how often the real position is updated and how to retrieve the updated version (as it looks like rr_status caches this value for quite some time)

                              bot 1 Reply Last reply Reply Quote 0
                              • bot
                                bot @arhi last edited by bot

                                IMO, and I know next to nothing, so take this with ten kilos of salt, the easiest approach would be to approximate the position of the axis for display. Alongside the calculation of the steps, you could do some calculations which use the same accel/constant speed/decel parameters as the step generation to display a changing value on a display. So, you'd have to "segment" the display into three parts. First, approximate the time to go from starting position to the end of accel phase. Then, approximate the time to go to the decel phase, then approximate the decel time. During those times, "animate" the value of the position over the given phase time.

                                *not actually a robot

                                1 Reply Last reply Reply Quote 0
                                • 3DOeste
                                  3DOeste last edited by

                                  Industrial cnc systems show real-time position of the movements. What I donโ€™t know is if that position shown is read from the encoders or generated from the gcode. The control definitely knows encoder position off all axis and can make corrections.

                                  1 Reply Last reply Reply Quote 0
                                  • Lem
                                    Lem last edited by

                                    Can we read real position of tool in new RRF? Is it possible?

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

                                      @Lem you can read near real time machine position in RRF 3.5.

                                      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