Posts made by Terry

@chrishamm Ah, I see. Yes, good plan.

@chrishamm Yes, I was reporting because it isn't fixed in v3.4-rc2 as implied in the notes, so wanted to be sure that something hadn't been left out of the imminent release.

Just updated a Duet 3 / RPi system with apt update+upgrade from 3.4-b5 to 3.4-rc2 and spotted the following error in the output:

Unpacking duettools (3.4-rc2) over (3.4-b5) ...
Preparing to unpack .../024-duetpimanagementplugin_3.4-rc2_armhf.deb ...
Error:
  An assembly specified in the application dependencies manifest (PluginManager.deps.json) was not found:
    package: 'runtimepack.Microsoft.NETCore.App.Runtime.linux-arm', version: '6.0.2'
    path: 'System.Net.Quic.dll'
Unpacking duetpimanagementplugin (3.4-rc2) over (3.4-b5) ...

Installation appeared to proceed normally.

Good, that seems to confirm that it's an issue with the 3HC firmware.

Just as a legacy of testing that machinePosition and userPosition were the same, which they are in this instance.

Axis setup is:

M569 P1.1 S0
M584 V1.1
M208 V0:100
M92 V400
M350 V16 I1	
M566 V400
M203 V10000
M201 V6000
M906 V1500
M574 V2 S1 P"1.io1.in"

Test macro is:

M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1

M117 {move.axes[4].userPosition}

Same bug is present on 3.2.2

Just found G38.2, which appears to be more suitable.

After testing with

M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1

I get the same problem! There appears to be a bug where the machine and user positions are always updated to be equal to the requested destination move, even though the move was interrupted by an endstop or probe trigger.

Ideally, what is needed is a generic probing command that supports motion on any axis. This would be necessary for a 3 degrees of freedom probe mounted in a spindle if you wanted to touch off on a workpiece in X, Y and Z, in any case.

For clarity, I home in the positive direction (but physically downwards) for my axis and reference this as the highest axis distance. I then swap out the high end endstop for the low end endstop and probe in the negative direction (physically upwards) until the switch hits the tool.

This recalibrates the axis position to the target value that was in the move command, losing the information about how far I have actually moved in the original coordinate system.

This will only be visible if you are testing against an endstop that is different to the one you referenced from in your homing move...

But did your machine and user position for that axis also change?

G60 would store a position relative to the calibration referenced against the fixed endstop. Any move detecting the mobile endstop will cause the axis to re-reference against that position. Any subsequent G2 R would return to a saved position relative to the new calibration, so not the original absolute position in the machine framework.

@fcwilt Triggers can't stop motion in a controlled manner, so at best you can call an emergency stop and lose system calibration. This is why endstop circuitry needs to exist inside the motion control loop - the endstop triggers need to be interrupts that can cancel motion at very low latency without losing position.

@fcwilt G60 wouldn't work because calibration is lost.

With both G1 H3 and G1 H4, the machine and user positions are overwritten as soon as the switch is triggered. In absolute mode, the axis value is set equal to the destination value that was commanded in the move. In relative mode, the axis position value is set to 1.

So, for example, starting at machine coordinate V=50 and commanding G1 H4 V2, the axis will move towards V=2 but if the switch is pressed before it gets there, motion will stop and the current position of V will be declared to be V=2, changing the calibration.

On a typical CNC platform, I would expect at least 3 triggers per axis.

Endstops would be min and max travel indicators and would be continuously active unless explicitly disabled so they could stop motion before a physical collision (the machine may also include emergency stop cutouts at the physical limits to cut power in a runaway controller scenario). It should be possible to detect unexpected over-travel as a result of lost steps and recover by re-homing.

One or more reference triggers should also exist, for accurate and efficient homing. These should be inboard of the travel limits to avoid harm to the machine during homing operations and may sit in the middle of the travel range to enable efficient re-calibration during long operations. Typically they would only be active during reference operations.

Endstops need to be active during homing in case the assumed start position or travel direction is wrong.

Single active endstop-as-home-reference is a cost-saving hack that is acceptable for a $500 3D printer but can result in injury or physical damage to the machine in larger and more powerful setups, so it would be nice if we could support best practice in the future?

Thanks. I am on 3.2.0 currently and this axis and switches are on a Duet 3 Expansion 3HC board.

H3 appears to do the same as H4, but also changes the min travel extent value.

I think this maybe a bug as that isn't the expected behaviour.

@Veti Not able to test yet for this specific manufacturer, but there are commercial machines that use these switches for this purpose, so I expect it to be as repeatable as a microswitch.