5bar scara Problem configuring z probe using fsr switch
-
@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
-
@fcwilt It’does nothing the arm stays in his homed position
Gianmarco
-
@gnmrc_ said in Problem configuring z probe using fsr switch:
@fcwilt It’does nothing it stops the movement.
When does that happen?
When trying to execute the homing file?
After that?
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
-
I assume you're working from this?
https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_five_bar_parallel_scara
-
@fcwilt, no the arm homes itself, then when it should do the x0 y0 move it stops
-
@Phaedrux yes, I’m using that and I used some other forum post from 2019 I think.
-
@gnmrc_ said in Problem configuring z probe using fsr switch:
Try to be more precise - I am not there seeing what you are seeing - need to help fill in the gaps of my knowledge. Thanks.
no the arm homes itself, then when it should do the x0 y0 move it stops
Are you referring to the move to X=0 Y=0 at the end of the homing file?
That is when you get the error message about un-homed axes?
Correct?
IF that is what is happening then the G1 H1 moves are NOT homing the axes. If they were being homed the move to X=0 Y=0 would work.
When a homing move fails, that is it reaches the end of the specified travel (in your case 200) without activating the endstop switch, there is no error message - it just stops moving and the axis is still not homed.
So remove the move to X=0 Y=0 (if it is still there), re-boot the machine and click on the HomeAll button in the DWC Dashboard.
Once the movement in both axes stops. check if the X and Y home buttons have changed to indicate they are homed.
Thanks.
