Working ZenXY configuration for FluidNC Pen/Laser Controller

Software / Firmware Jackpot Board / FluidNC
41

Yeah, I trigger the endstops then back in real nice and cozy.

42

Ok. So I looked closely at the homing code, and I don’t see a path forward for homing with one $H command, and the current size/shape of the optical flags.

This is where I ended up though, which is getting most of what I want from my ZXY:

pulloff_mm: This needs to be larger than the amount of travel it takes to go from the physical minimum, to clear the endstop. Given the size/shape of the flags on the ZXY, I determined how far the machine needs to move away from its absolute physical limit to clear the endstop.

  • For Y, 3mm seems to be enough. When the trucks are touching the front corner, it takes 3mm of movement to clear the optical endstop.
  • For X, 13mm seems to be enough. From the position where the gantry is touching the left truck, it takes between 12 and 13mm of movement before the optical endstop is cleared.
  • The easiest way for me to test this was to set each endstop pin to NO_PIN. I could then jog the machine around wherever I wanted, and watch the green LED on the endstops turn off.

Homing Sequence:

FluidNC goes through these stages during homing:

  1. PrePulloff: Moves away from the endstop, until it is no longer triggered, or it has reached pulloff_mm. If it can’t get the endstop to stop triggering before it reaches pulloff_mm, it will error out and stop, raising an alarm. This is why we have to set the pulloff distances to something reasonable.

  2. Fast Approach: Moves towards the endstop at the seek_mm_per_min speed, until it sees the triggered endstop. If it goes more than max_travel * seek_scaler, it will throw an error. If you have your max travel set correctly, the seek scaler doesn’t need to be adjusted.

  3. Pulloff0: Moves away from the endstop pulloff_mm.

  4. Slow Approach: Moves back towards the endstop at feed_mm_per_min. It moves at most pulloff_mm * feed_scaler. So if your pulloff was 3.0mm, and your feed scaler was 1.1, it would move at most 3.3mm (but it should only be 3mm away. That is as far as it pulled away). It stops when it sees the triggered endstop. If it reaches the distance limit, another alarm/error.

  5. Pulloff1: It moves away from that endstop again, by pulloff_mm. There doesn’t seem to be any way to keep it from doing this.

  6. Pulloff2: This is only for machines with auto squaring. It does the extra pulloff to adjust the two motos independently. My ZXY doesn’t do this.

So at the end of $HY, the Y position is pulloff_mm away from the place where the optical endstop triggered. Since we set that to 3mm, it has to move 3mm more negative to get the endstop to trigger. If I want the 0 location for Y to be beyond that, 2mm past where the endstop triggered, I can do that with mpos. But it only affects where the Y axis is right now.

mpos_mm: This sets the value of the axis after the homing sequence is finished. Since it always does that pull off, this is what value you want the triggered location, plus pulloff to be defined as.

  • I want the Y axis zero to be 2mm into the optical endstop. This is a good fit for my table, and I know the X endstop will trigger if Y is there.
  • I set the y:motor0:mpos_mm to 5.0. I want the zero to be 2mm behind the trigger point, and the homing sequence moved 3mm after homing. 2.0mm + 3.0mm = 5.0mm.
  • I want the X axis zero to be 12mm into the optical endstop. This is where the ball touches the corner.
  • I set the x:motor0:mpos_mm to be 25.0mm. 12mm for moving into the endstop and 13mm for the pulloff distance.

Homing Code

So now, the X and Y locations are sufficiently in the corner. But I do have to use a 3 line script to home:

$HY
G0 Y0
$HX

I could add something like G0 X10 Y10 to sit in a comfy location after the home (and I might do that).

1 Like
43

I am glad I didn’t miss something obvious.

Zen 3 needs a different endstop adjustment.

44

I like that the adjustment is in software. I am sure we could fix this by editing the firmware a little. I would like to add some more custom homing feature that would work better for optical endstops. Like one of these:

  1. Move to a specific position after homing, without changing what pulloff or mpos do
  2. Allow a custom script for home all. Something where we could set home_all_script: "$HY; G1 Y0 F500; $HX".
  3. Have a specific parameter for homing that is something like: require_y_position: 0.0.

I have no idea what feature FluidNC would be willing to swallow. Or maybe there is a better way and I am just not seeing it.

I think you could fix it with different physical sizes and positions of the optical endstop flags. But it is really tricky. You need to have a different physical stop position that is closer to where the endstop is triggered. But that gets tricky when you have variability in builds. Still, I think there is a perfect 1mm or so where it would work. If the Y pulloff distance was 1mm, and the X could still trigger its endstop when Y=1, then you could do the double home with a pulloff of 1mm.

45

RRF and Marlin both have a setting for the endstop location, or rather what the machine limits are.

This is usually used to set the limit in negative space, where (for example) a print head is permitted to move further than the bed.

Does GRBL (and by extension FluidNC) have such a thing? Can we say that the home position is at about X=10? That would allow something like sandify to still have the range of X from 0 to whatever…

Alternatively, I guess we could define the table to Sandify to have a minimum of -10 I suppose, and let it generate patterns that go into negative space.

46

I think I have a good grasp of how to make the origin of the machine wherever I want. What I can’t do is force the Y to be 0, whenever I am homing X.

Setting mpos to wherever the machine is after the pulloff distance works. You can set it to +10 or -10 or 0. Whatever you want. But it is where the gantry ends up after doing the pulloff.