5bar scara Problem configuring z probe using fsr switch
-
@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
-
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
-
@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 It will work but would be like skipping the problem. I want to make the homing work properly as intended.
Gianmarco
-
@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:
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
-
@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 -
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
-
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. -
Sorry it is taking so long.
In your homing file at the end you have
G1 X0 Y0 S2Why the S2?
Frederick
-
@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
-
@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
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
Can you send M122 in the gcode console and share the results?
-
@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
-
@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
-
@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 -
Here are the last three lines from the most recent homing code:
G90
G1 X0 Y0 F300 S2 ;move hotend to the center
G30As I recall you said the S2 (which should be H2 according to the docs) is needed.
But if the previous two G1 H1 commands worked the X and Y axis should be homed and the S2 (H2) should not be needed.
Now the G30 is the probing command and it is not going to work since it needs the Z axis to be homed.
And there is nothing in your homing file that tries to home the Z axis.
To help clarify something try this, please:
- remove the S2 from the last G1 command
- remove the G30 command
- test homing now
Yes, I know that Z axis will not be homed but I am not worried about that.
What worries me is the need for the S2.
Thanks.
Frederick
-
@fcwilt I’ve done as you said, this is the error I get:
G0/G1: insufficient axes homed -
@Phaedrux this is what I get from m122:
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.5 (2022-11-30 19:36:12) running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9P6M2-NWNS0-7JKDD-3SN6S-1U0BJ
Used output buffers: 1 of 26 (11 max)
=== RTOS ===
Static ram: 23836
Dynamic ram: 74172 of which 68 recycled
Never used RAM 14004, free system stack 184 words
Tasks: NETWORK(ready,13.4%,242) HEAT(notifyWait,0.0%,333) Move(notifyWait,0.0%,363) MAIN(running,84.1%,446) IDLE(ready,2.5%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:37 ago, cause: power up
Last software reset at 2023-10-19 21:58, reason: User, GCodes spinning, available RAM 13692, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 29.8, current 33.2, max 33.4
Supply voltage: min 12.5, current 12.5, max 12.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5:
Driver 6:
Driver 7:
Driver 8:
Driver 9:
Driver 10:
Driver 11:
Date/time: 2023-10-24 17:39:02
Cache data hit count 1374063136
Slowest loop: 6.81ms; fastest: 0.18ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 2.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Network ===
Slowest loop: 15.77ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 98
ac:20:cb:ca
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25824
WiFi IP address 192.168.178.109
WiFi signal strength -54dBm, mode none, reconnections 0, sleep mode modem
Clock register ffffffff
Socket states: 0 0 0 0 0 0 0 0 -
@gnmrc_ said in Problem configuring z probe using fsr switch:
@fcwilt I’ve done as you said, this is the error I get:
G0/G1: insufficient axes homedI should have asked - exactly what are you/it doing when this message appears - during the homing file execution?
Thanks.
Frederick
