Fine Homing on X doesn't work
-
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.4 (2022-10-20 16:17:41) running on Duet WiFi 1.0 or 1.01 + DueX5
Board ID: 08D6M-95AK9-NG3SD-6JKDJ-3S46J-96R9X
Used output buffers: 1 of 26 (15 max)
=== RTOS ===
Static ram: 23860
Dynamic ram: 76532 of which 0 recycled
Never used RAM 11616, free system stack 124 words
Tasks: NETWORK(ready,14.0%,237) HEAT(notifyWait,0.1%,333) Move(notifyWait,0.0%,306) DUEX(notifyWait,0.0%,24) MAIN(running,85.8%,438) IDLE(ready,0.2%,30), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:10:14 ago, cause: power up
Last software reset at 2022-11-12 23:57, reason: User, GCodes spinning, available RAM 11688, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 10.0, current 19.5, max 19.9
Supply voltage: min 24.4, current 24.6, max 24.8, 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 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10:
Driver 11:
Date/time: 2022-11-13 12:20:29
Cache data hit count 4294967295
Slowest loop: 11.24ms; fastest: 0.17ms
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 1.2ms, write time 0.9ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 214299ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 33, completed 33, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 13], 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
Heater 0 is on, I-accum = 0.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
=== DueX ===
Read count 1, 0.10 reads/min
=== Network ===
Slowest loop: 29.24ms; 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.27
WiFi MAC address 5c:cf:7f:2c:27:b3
WiFi Vcc 3.34, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24056
WiFi IP address 192.168.1.142
WiFi signal strength -46dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0 -
@Stevtommo said in Fine Homing on X doesn't work:
M92 X200.00 Y200.00 Z1600.00 E30.578 E5273.00:5273.00 ; set steps per mm
You've got E twice, but no U. Not that that would have an impact on your X homing.
Can you try copy and paste your homeall.g commands into the console one line at a time and see if it still has the same problem with the second move?
-
@Stevtommo Hmm, that's an odd one and I don't see anything wrong with your files. The fact that fast homing works fine but slow homing does not, also indicates that your configuration must be sound. You are sure that you corrected the H4 to be H1 yes? You haven't inadvertently typed HI (capital "I" instead of the number "1")?
Other than that, it looks like you have the switches wired normally closed so they must go open circuit to trigger. One possibility is that the switch is "sticky" so the longer fast move triggers the switch but it remains triggered when you back off. Then when you do the slow move, the switch is already triggered so the move stops immediately. That would manifest itself itself if there was no movement in X when doing the slow homing move, but not if there is some movement. Still, it might worth backing off say 20mm instead of 10mm just in case there is too much mechanical hysteresis in the switch. Another possibility might be a bad crimp or other wiring issues which causes the firmware to "see" an open circuit prematurely. But it's difficult to see how that could be the case given that fast homing works reliably and repeatedly. Still it might be worth checking for a bad connection somewhere.
One other possibility is that the end stop inputs have a pull-up resistor. If that was weak of faulty then the input might "float" and cause miss triggering. Again, that doesn't stack up with the fact that fast homing is always reliable but it might be worth trying a different end stop input if you have one available.
-
@Phaedrux - great catch, thank you for the U-axis catch.
- I added a dwell (G4 P2000) between each command so I could see what was being done and also reported, and I've also done as you say with the console.
- The issue is definitely the second move, which ends abruptly, and seemingly randomly.
-- H1 X-100 F360
@deckingman - Thank you for weighing in, I really appreciate it.
- I've definitely changed the H4 back to H1 (Checked it for 1 vs I, and yep I'm good there too)
- I've checked the switches for hysteresis, and they're all lightning quick (I've just been manually tripping them to fool the homing process when the head's nowhere near. Wherever the head is on the bed, it acts the same way
- I've been watching the 'object model' to see if/when the stops get triggered, and they (X,Y) DO for the first move, but only the Y gets triggered for the second.
- I've swapped the X and Y stops on the board and remapped them, and I have the same behavior.
- I've just checked the wiring again, and it all looks solid.
-
And it's definitely not a grub screw slipping on the motor pulley?
-
Apologies I meant to add to this earlier. I've checked all the grubscrews, and they're rock-solid.
I'm frankly amazed how much torque the NEMA17's have in this COREXY configuration. I've tried to stall them by holding onto the carriage but they pull right through.
-
Can you show some photos of the printer and/or a video of the homing in action?
-
@Stevtommo said in Fine Homing on X doesn't work:
,,................I've been watching the 'object model' to see if/when the stops get triggered, and they (X,Y) DO for the first move, but only the Y gets triggered for the second.
That could be significant. If the G1 H1 X-n move gets executed, what should happen is that the carriage moves until the endstop triggers. If the endstop never triggers, then the carriage would continue to move after it had crashed into the frame. So logically, the only possible explanation for the endstop not trigggering and carriage not crashing into the frame, is that the G1 H1 X-n move does not get executed. Suggest you delete that G1 H1 X-n move and re-type it in case there is a hidden character which is screwing things up. Or you could add M400 after the Y axis move which would wait for that move to complete before doing the X axis move (although that shouldn't be necessary).
-
@Phaedrux , good idea
I've hosted them here, along with videos showing some wierd behaviour - more on that below... Google Drive@deckingman - 100% agree. Why does executing the same command not elicit the same response? I 'feel like' the machine is holding onto a guess of where 0,0 is after rough homing and is trying to predict it rather than use the stops.
Retyping the line didn't make a difference, nor did the use of M400 between commands.
What I discovered this evening that does seem to 'work' is the following, and I can't make heads or tails of it...
- Rough pass X,Y similtaneously (Always triggers the stops):
G1 H1 X-425 Y-365 F1800 ; move quickly to X or Y endstop and stop there (first pass) G1 H1 X-425 ; home X axis G1 H1 Y-365 ; home Y axis- Trying to fine tune the X position (Always fails):
G1 H1 X-100 F360 ; move slowly to X axis endstop once more (second pass)- Going for a Y home (Always triggers):
G1 H1 Y-365 ; then move slowly to Y axis endstop- Then doing X again (mostly triggers):
G1 H1 X-100 F360 ; move slowly to X axis endstop once more (second pass)- Doing X again-again (99% sure this is capturing all)
G1 H1 X-100 F360 ; move slowly to X axis endstop once more (second pass) -
@Stevtommo On a CoreXY, this command G1 H1 X-425 Y-365 F1800 will move both the X and Y axis until one or other end stop switch triggers (that's why it must always be followed by individual X and Y axis moves).
So it could be that the Y axis always triggers which stops further movement of both axes but the X axis does not trigger. i.e, it could be simply that there is something "flaky" with X axis endstop. You could test that theory by positioning the carriage such that it is a long way away from the Y end stop but fairly close to the X end stop, then doing that combined XY H1 move. If the X end stop doesn't trigger, then the carriage should hit the frame in the X direction and attempt to continue that move.
Do you have another microswitch that you could try?
-
I don't see anything obvious from the videos.
Can you try this? Rename your current homeall.g to make a backup. Then create a new macro file and name it homeall.g. In there just have
G28 X
G28 Y
G28 ZThat will call your other homing macros.
Same behaviour?
If you watch the X axis endstop light on the board (if your board has the LED, not all do I think) does it light up when homing X?
-
This post is deleted! -
@deckingman - good idea
I did already swap in other X end-stop switches to no avail. Given the switches have a 100% success rate in catching the rough-passes, I can't see how it's anything electro-mechanical at this point.To your other point, the system is failing to execute the latter X-move when both axes have just been successfully homed and positioned at X,Y:10,10. It fails when only one axis is being asked to move, namely
G1 H1 X-100 F360So...what I'm finding is (and I fully appreciate that this looks odd) that if I repeat the request multiple times in a row, while splitting up the drive it's addressing, seems to be catching the error every time (I've done 30 home cycles and it's 'jerky' but it works.
G1 H1 X-100 F360 G1 H1 Y-100 F360 G1 H1 X-100 F360 G1 H1 Y-100 F360 G1 H1 X-100 F360 ... -
Hey there @Herve_Smith,
Thanks for the suggestion, I tried this out. My printer fails exactly in the same place, the fine-homing move. It just stops somewhere along the axis (does not show activation of XStop in object-model, light on the board does not light up as the circuit remains closed, and it then merrily executes the next line...
G1 H1 X-455 F360 ; Slowly move to the X axis endstop once more (Fine Adjustment)
-
@Phaedrux, same bad behavior... G28 X is the problem.
The below sometimes solves it, but it's not repeatable... Appreciate your thoughts.
Without lines 9,10,11 in there, the X-axis just refuses to engage the end-stop.
G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-325 F1800 ; move quickly to X axis endstop and stop there (first pass) G1 X10 F6000 ; go back a few mm G1 H1 X-325 F360 ;try fine-homing (fails) G1 H1 Y-0.1 F360 ; jiggle the y-axis one way G1 H1 X-325 F360 ; try to fine home X axis again (seems to always succeed) G1 H1 Y0.1 F360 ; jiggle the y-axis back G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning -
@Stevtommo God this is weird.... Clutching at straws here but is the carriage nice and free to move in the X direction? If your belts are too tight it can put too much side load on the motor bearings. Perhaps there is some sort of "sticktion" which a high feed rate can overcome but for some reason a slow feedrate cannot? Like I said, I'm clutching at straws but I note that your motor current is only 800mA which is on the low side. Are you able to increase that? If the motors are rated at say 1Amp, you could push the current up to say 950mA just to see if that helps. If it does, then maybe more powerful motors might be the answer and/or eliminate or reduce any "sticktion".
I might be useful to know if there is a sweet spot for feedrate for the fine homing move. You could try doing the slow homing at the same feedrate as the course homing, and if it homes reliably then progressively reduce it until you run into problems again.
I've no idea if this is significant but on a Core XY, both motors are employed for pure X or pure Y moves, but the direction of one motor is reversed. I can't think of any reason why that would be significant to your problem but I'll keep thinking about it. -
This post is deleted! -
Have you tried increasing the length of the second move from 100mm to at least the length of the axis?
