Real Time Position

dc42

@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.

bot

[...] 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.

arhi

@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

@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.

arhi

@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

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.

3DOeste

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.

Lem

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

dc42

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

willv

@dc42 How so?

dc42

@willv see this post earlier in this thread https://forum.duet3d.com/post/166688