Real Time Position

[Phaedrux]

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.

[baird1fa]

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]

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

[baird1fa]

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

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

[baird1fa]

@Phaedrux I’ll give it try next time I have the opportunity.

[arhi]

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

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

[dc42]

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

[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