@dc42 said in step count from object model:

move.axes[].stepPos"

Fantastic !! thanks

@dc42 Is the adding of the stepcount as a object model, something you are planning for the near future.
Or would the scara develpment team be interested in adding an additional axle on the tip of the distal arm?

Is there an object model that gives me the stepcount?
I am building a scara, and when you give the M114 command, some of the values are the axis step counts.
I need to get these, to do some calculations on the angles that the P and D arm are currently in.

For example, picture the scara arm is holding the bed and the stationary part is the nozzle. The bed is on rotational axle A, on the tip of the distal arm.
To keep the bed in the same orientation( to ground) as it was before, we need to have the angle of X and Y to calculate angle A.

Or is ther a better solution for additional rotational axis on a scara setup?

We are not building a printer, so for our setup it does not matter that the A move is done after the X/Y move

@Phaedrux that is a really interesting approach.
I guess we can not send other commands while that homing is in progress?

Is there an ETA on the feature @dc42 mentioned

When a drive gets stalled you get a popup on the screen that tells you which drive stalled.
Then you can run the rehome.g file.
Is there a way to query which drive stalled in the rehome.g file, so we can do things to the specific drive.
some thing like:

if stall_drive_0.1 is true
do something
if stall_drive_0.2 is true
do something else

We configured a dual carriage system with X an U axis.
all is calibrated and working well, but...
When we tell X to go to 100mm, and then tell U to go to 100mm, it will actually try to do this and then end up crashing in to each other.
Shouldn't there be some sort of failsystem that counter acts "stupid" moves?
Like an offset of the U versus the X of 100mm. so the U axis cannot come closer then 100mm of the X carriage.
Or have we just missed that feature?

We have a configuration where we have 2 motors on Y axis.
We also have 2 enstops on Y axis max.

M584 Y1.1:4.1
M208 Y300 S0
M574 Y2 S1 P"1.io0.in+4.io0.in"

But the 2 enstops are not physicaly at the same max position, there is a 0.2mm difference.
So where one is at 300.0mm , the other is at 300.2mm.
Is there a way to make this known, and tell the motor that is at 300.2 , to come back to 300, when finished homing?

Installed 3.4RC2 and it now works as it should

Thanks for the tips

@dc42 we updated to 3.4RC2 but now the pi will not connect to it.
DCS is not started.
sudo journalctl -u duetcontrolserver gives: invalid protocol version 6

went for unstable release

@dc42
RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)

Also on the expansion boards