Object mode: machinePosition or userPosition?

zapta

The object model shows two position fields per axis, machinePosition and userPosition? Is there a difference between them and which one should I use?

I want to have a condition like this one for my Clicky probe macros:

if y > 180
  move y to 180

fcwilt

@zapta

As I understand it machinePosition is the current position and userPosition is the requested position.

But I could be wrong.

Should be easy enough to test.

Frederick

zapta

Thanks @fcwilt. I think I understand the distinction now, and it seems that userPosition is the right choice for my use case, the condition can be evaluated before the machinePosition got stabilized on the previous move and the program will take the wrong route.

Does this make sense?

fcwilt

@zapta

Well I wouldn't think the userPosition would be changed to the next requested position until the machinePosition matched the userPosition when the move was complete.

But I have only used machinePosition in situations where I knew nothing was in motion.

Frederick

zapta

@fcwilt said in Object mode: machinePosition or userPosition?:

Well I wouldn't think the userPosition would be changed to the next requested position until the machinePosition matched the userPosition

I see, the userPosition may follow the machinePosition.

Does anybody know if there is any specification of this aspect of the object model? This page does not even mention machinePositon https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware

fcwilt

@zapta

Well you could create a daemon.g file to output both values.

But since that would only run ever 10 seconds you would have to command a very slow move to obtain a suitable number of readings.

Frederick

zapta

@fcwilt, yes, that's a good idea, testing it with slow movements. Maybe even examining the values in the DWC object model plugin.

Would be nice though to find the official documentation, to understand the intentions behind these two values and their recommended use cases. For time being, I will just add M400 before the conditions and use userPosition.

fcwilt

@zapta said in Object mode: machinePosition or userPosition?:

Maybe even examining the values in the DWC object model plugin.

I suggested using the daemon.g file so you would not have to take any actions to obtain the readings.

Just get the daemon running and command the slow move.

Would be nice though to find the official documentation, to understand the intentions behind these two values and their recommended use cases.

@dc42 should know.

Frederick

JoergS5

I like looking into source code to understand the values, https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Platform/Platform.cpp tells

{ "machinePosition", OBJECT_MODEL_FUNC_NOSELF(reprap.GetMove().LiveCoordinate(context.GetLastIndex(), reprap.GetCurrentTool()), 3), ObjectModelEntryFlags::live },

{ "userPosition", OBJECT_MODEL_FUNC_NOSELF(reprap.GetGCodes().GetUserCoordinate(context.GetLastIndex()), 3),

LiveCoordinate() is documented in Move.h:
float LiveCoordinate(unsigned int axisOrExtruder, const Tool *tool) noexcept; // Gives the last point at the end of the last complete DDA

So in my interpretation machinePos is taken from the last completed move and userPosition from G-Code file.

Some of the values of the object model are in the kinematic files also.

It would be easier to have documentation at one place, I agree. But nobody likes documentation and quickly becomes outdated. I saw "Doxygen setup and use.md" in the Core2NG project, which is for documentation generation from source comments, maybe it's possible to generate documentation of the source automatically. Doxygen seems to be used in Core2NG only (maybe it was a test), but a document generation tool for all projects could be a possible solution to have documentation automatically in the future.

dc42

@joergs5 said in Object mode: machinePosition or userPosition?:

So in my interpretation machinePos is taken from the last completed move and userPosition from G-Code file.

That's correct. Field userPosition is the position in user coordinates (the ones specified in GCode) at the end of the last GCode movement command that has been completely or partially queued for execution. It is the starting position for the next GCode movement command. Therefore it is suitable for use in e.g. layer change scripts.

zapta

Thanks @dc42.

I followed @fcwilt suggestion and run a test using slow single line moves and daemon.g (code below) and this is what I found.

userPosition is updated when a move is queued with the end position of that command.
machinePostion is updated when a command is completed, with the end position of that command. No intermediate move values.
The DWC dashboard displays the x/y/z of userPosition.

BTW, I would think that it's more intuitive to have both the dashboard and machinePosition reflecting the actual momentary position of the head. Also, renaming userPosition to queuedPosition or programPosition or gcodePosition may better reflect its nature.

Anyway, I am set now and using userPosition as recommended seems to work well. I may even remove the M400 down the road.

=============

In daemon.g

echo "User: " ^ {move.axes[1].userPosition} ^ ", machine: " ^ {move.axes[1].machinePosition}

In test macro file:


g1 X10 Y10 F5000


g1 X11 Y11 F360
echo "Move 1.1"
g1 X201 Y201 F360
echo "Move 1.2"

g1 X12 Y12 F360
echo "Move 2.1"
g1 X202 Y202 F360
echo "Move 2.2"

g1 X13 Y13 F360
echo "Move 3.1"
g1 X203 Y203 F360
echo "Move 3.2"

echo "Moves done"

fcwilt

@zapta

Did the moves take, say, 60 seconds to complete?

With the daemon only running every 10 seconds you would need enough time to verify if the machinePosition was updated during the move.

Frederick

zapta

@fcwilt, yes, moves where ~300mm at 360mm/min so about 50 secs per move.

fcwilt

@zapta

OK then that would seem to confirm that the firmware is not updating those values during the move, only before and after.

So that is good to know.

Frederick

T3P3Tony

@fcwilt @zapta AFAIR the position reported is only updated at the end of each segment. So for a kinematics that does not segment moves by default it is only updated at the end of each move. You can choose to segment moves in M669, that might give more granularity to the reported position in the OM.

fcwilt

@t3p3tony

Thanks.

Something I will test.

Frederick