5bar scara Problem configuring z probe using fsr switch

gnmrc_

@fcwilt I tried your suggestion, I jogged the machine from a known position that would make the arm move theoretically in the right way, and the arm moved accordingly to my command so -y moved the arm only left +x forward and so on without having noticeable diagonal moves or incorrect ones. Then I started moving the arm until it reached its endstops, the position that I found was x: -161.1 y: -108.53, while the one that I had calculated using theoretical values was x: -162.67 y: -108.53.

Thank you for all the help that you are giving me!

Gianmarco

fcwilt

@gnmrc_

Did you do the set of steps to establish X=0 Y=0 at the center of the bed?

From that position can you reach an endstop switch moving on just one axis or does it require movement on both?

Homing usually involves a G1 H1 move where the H1 causes the movement to stop when the endstop is triggered and set the current position to the min/max value for that axis.

I suppose it is possible to have a G1 H1 Xnnn Ynnn move as long as it ends up triggering one of the endstop switches. It could still set the current position of the axis associated with the endstop switch that was activated. I guess it just ignore the other axis.

Thanks.

Frederick

gnmrc_

@fcwilt Yes, If I move first the left actuator than the right I can reach the zero position from the home position using only one actuator at the time with no problem.

If I understand correctly you are suggesting that after I reached the home position I rotate only one motor at the time to reach the zero position, right?
In this case I could also only move the arm using angular position.

Tell me if I understood everything correctly.

Thanks for the help,
Gianmarco

fcwilt

@gnmrc_

Considering a simple two-axis Cartesian printer where each axis, X and Y, can move independently.

The endstop switches for each axis are in known locations. When you power up the machine the location of the tool is unknown.

You issue the G1 H1 commands for one axis at a time. The movement is toward the associated endstop switch. When the endstop switch is triggered movement stops and the location for that axis is now known, as it sets the logical position based on the min or max value from M208, for that axis.

But If the values in M208 are wrong the logical position for that axis will not match the physical position.

I'm trying to figure out how that is done on a machine like yours where movement to any XY point seems to require moving both axes.

Starting from a unknown position is there a single G1 H1 Xaaa Ybbb command that can result in each endstop switch being triggered at some point in time?

Or do you use two commands, G1 H1 Xaaa and G1 H1 Ybbb?

The physical positions of the endstop switches that you posted, positions you verified mathematically and experimentally, don't match the values in the M208 in your config.g file.

Thanks.

Frederick

gnmrc_

@fcwilt, no it's not possible to home with a single G1 H1 command both axis, you have to home one axis at a time. After the homing arm procedure ends the arm knows its effector position (I also corrected the m208 line).
In the dashboard X and Y values after I get the error "failed to home Z" are correct.
If after the error I send a g92 z0 command and then g0 x0 y0 the arm behaves as it should.
Only if I send the g0 x0 y0 in the home5barscara.g file the arm does not behave properly.
I also took the videos of the 2 arm behaviors, but are too large to upload here, tell me if they could help.

Thanks for the help.

Gianmarco

fcwilt

@gnmrc_

Well it sounds like you are making good progress.

Why is Z not being homed? Z is usually easy.

As to the videos I would very much like to see them.

Can you upload them to YouTube?

Thanks.

Frederick

gnmrc_

@fcwilt, yes we are getting close to make it work perfectly.

I cannot home the z axis because I use the z probe as z endstop for homing.
Being my homing pos outside the bed I have to move the arm at a position inside the bed to complete the procedure but when I try to do so I get the overshooting problem.
That move it’s the only thing left to make everything work.

Yes I will post the videos as soon as possible.

Thanks for the help,

Gianmarco

fcwilt

@gnmrc_

Perhaps you could just add a micro switch or optical sensor to simplify homing Z?

Frederick

gnmrc_

@fcwilt It will work but would be like skipping the problem. I want to make the homing work properly as intended.

Gianmarco

fcwilt

@gnmrc_ said in Problem configuring z probe using fsr switch:

@fcwilt It will work but would be like skipping the problem. I want to make the homing work properly as intended.

Gianmarco

There is no "properly" - there are just several ways to achieve the desired outcome.

Consider this printer of mine using three Z steppers to achieve auto bed leveling:

Bed Leveling Demo

Now I purposely put the bed way out of level to demonstrate the auto bed leveling. It works because each Z axis has it's on endstop switch. It would not be possible with a typical Z probe to level the bed as it is.

Once the bed is level then I use the Z probe to run the firmware's bed leveling feature which fine tunes the result obtained from leveling with the endstop switches.

It's your printer and you can do anything you want but don't frustrate yourself thinking homing Z with a probe is "as intended".

Good luck.

Frederick

gnmrc_

@fcwilt Ok, I'm gonna do that way.
By the way I forgot to link the videos of the machine:
This is the overshoot that the arm does
This is the homing only of the 2 arms and after the g92 command followed by the G0 x0 y0.

Thanks,
Gianmarco

fcwilt

@gnmrc_

That is a fascinating machine.

Please post your most recent config.g file and the various homing files.

We are overlooking something simple - I think.

Thanks.

Frederick

gnmrc_

@fcwilt

This is the most recent config file: config (1).g
and this is the most recent homing file:home5barscara (2).g
(I left commented some workarounds that I tried)

Thanks for all the help that you are giving me,
Gianmarco.

fcwilt

@gnmrc_

Sorry it is taking so long.

In your homing file at the end you have

G1 X0 Y0 S2

Why the S2?

Frederick

gnmrc_

@fcwilt, do not worry about the time I’m not in a hurry.
I use S2 because it makes me move the arm even if it’s not homed, other h commands would not make it move, I do not know why.

Gianmarco

fcwilt

@gnmrc_ said in Problem configuring z probe using fsr switch:

@fcwilt, do not worry about the time I’m not in a hurry.
I use S2 because it makes me move the arm even if it’s not homed, other h commands would not make it move, I do not know why.

Gianmarco

What version of firmware are you using?

This is what the docs says about that for v3 firmware:

Snnn In RRF3, this parameter is used to set laser power, when switched into Laser mode (see M452); its use for defining move type is deprecated, use 'H' parameter instead. In RRF2.02 and later, when switched into Laser mode (see M452), this parameter sets the laser power. When not switched into Laser mode, and always in firmware 2.01 and earlier, it defines the move type (see the description of the H parameter).

Also the G1 H1 moves in the homing file, assuming they triggered the endstops, should have marked the axis as homed.

If that is not happening something is wrong with the code or the endstops (configuration, wiring, etc).

Frederick

Phaedrux

Can you send M122 in the gcode console and share the results?

gnmrc_

@fcwilt
So I’m using RRF3.
I’m going to re-test it but when I use the S2 command it gives me a warning message saying obsolete command, but still moves as the old s2 command so ignoring homing not completed.

Gianmarco

fcwilt

@gnmrc_ said in Problem configuring z probe using fsr switch:

@fcwilt
So I’m using RRF3.
I’m going to re-test it but when I use the S2 command it gives me a warning message saying obsolete command, but still moves as the old s2 command so ignoring homing not completed.

Gianmarco

Good to know. Often commands and command options, like S2, are deprecated but not yet gone.

But it still leaves the question of why the two H1 moves aren't marking the axes as homed.

I notice that you specify the movement distance as X200 and Y200.

Be aware that if the endstop swtiches are not activated by the time the distance has been moved the axis is not marked as homed.

Is 200 long enough to insure the endstop switches are reached?

Thanks.

Frederick

gnmrc_

@fcwilt Yes endstop are reached with no problems from any arm position.
Maybe the movement does not work because it needs to home every axis not only x and y for some reason, this would explain the problem with the movement and why the arm works correctly after a partial homing routine(homing only the arm) and then using g92 to home z and after that everything works as expected.

Let me know what you think.

Thanks,
Gianmarco