Firmware 1.22 doesn't allow me to move axes for homing
-
M564 H0 to be precise.
-
Thanks for your replies dc42 and deckingman. Unfortunately the G/M mix up was only in my post here as the line in my config.g file is "M564 H0 ; CS addition". Any other ideas?
-
What is the exact error message?
If you send M564 with no parameters, what does it report?
-
Starting the Huxley from power up with the line "M564 H0 ; CS addition" in the config.g I issue "M564" and get "Movement outside the bed is not permitted"
Any attempt at moving X, Y or Z gets "G0/G1: insufficient axes homed"
Pressing "Home X" reports "Homing failed".
"G92 X0" results in the "Home X" button on the web interface turning blue and the "The following axes are not homed" warning message below loses it's "X". In that state a "G0 Xnnn" command fails silently. -
@csambrook said in Firmware 1.22 doesn't allow me to move axes for homing:
One other uncertainty in my mind is that I installed file "RepRapFirmware.bin" from "https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease/1.21RC3" as I believe that's the correct file. Did I get that right or have I mis-understood the github structure and inadvertently installed the wrong thing?
No, stable (and most beta/RC) releases are at https://github.com/dc42/RepRapFirmware/releases. RC3 did not support the M564 H parameter.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Thank you so much for that, it's a real step forward
I now have M564 reporting that "Movement outside the bed is not permitted, movement before homing is permitted" and indeed the Z axis now homes nicely and the Z axis then moves on command.Sadly my X axis still refuses to move. When I try to home it I get a message "G28 X has returned an error: Homing failed". If I issue "G92 X0" the web interface "Home X" button goes blue indicating it's homed but G0/G1 X moves silently fail. Interestingly the Machine Status report for the X position in the top right instantly changes to any new X position I command but the physical hardware does not move.
This feels so close now...
-
Are you still not able to jog the X and Y axes? If so, that's probably a wiring or configuration error.
Start by testing raw X and Y motor moves. Send G91 to select relative mode, then after that G1 S2 X10 should move the X axis in the +X direction by 10mm (even if movement before homing isn't allowed).
-
More progress! Your suggestion of raw moves worked, I can jog the X in either direction (Y has always been OK).
So I guess the question is what's the difference between pressing a web interface X-move button and a raw move?
Also, what does "S2" do in that usage? I can find it referenced in the wiki G-code list but not explained. -
@csambrook said in Firmware 1.22 doesn't allow me to move axes for homing:
More progress! Your suggestion of raw moves worked, I can jog the X in either direction (Y has always been OK).
So I guess the question is what's the difference between pressing a web interface X-move button and a raw move?
Also, what does "S2" do in that usage? I can find it referenced in the wiki G-code list but not explained.S2 means do a raw motor move, ignoring the homed status. On a Cartesian printer it's the same as S1 except that it doesn't stop when the homing switch is triggered.
If G1 S2 moves are working, then G1 S1 moves should work too as long as the homing switches are being read correctly. Use M119 to check.
Does your Huxley use a microswitch to home the X axis, or does it use the IR sensor like the Ormerod does?
-
Ah ha, this sounds like it...
G1 S2 works but G1 S1 does not.
M119 reports "Endstops - X: at min stop, Y: not stopped, Z: at min stop, Z probe: not stopped". And it reports that whereever the X carriage is and even though the IR probe is reporting a very low value (ie. it's not seeing the X-stop-marker).
My Huxley uses the IR sensor for X as well as Z, Omerod style I believe. -
Thinking about it a bit more, I can't see anything in the config.g file which tells the firmware that X uses the Z-probe or what values to associate with that to mean "got there". On the other hand there were never any such things in dc1.04's config.g as far as I can tell either...
-
Sounds like you need two separate M574 commands in config.g. M574 X1 S2 to say that X homes to the low end using the Z probe sensor, and M574 Y1 S1 to say that Y homes to the low end using an active high endstop switch. Same as for an Ormerod 2.
In older firmware versions, the information that the Z probe is used to home X was included in the M558 command.
-
I'm afraid that made no difference. I now have:
M574 Y1 Z0 S1
M574 X1 S2
in config.g and the behaviour is the same.X can certainly move OK as it now homes just fine. Y and Z move completely OK. But when I command X to move it instantly reports the new position on the DWC but doesn't make any attempt to actually move. Just in case it was a DWC issue I made a test gcode file which only moves the X and Y positions around and that behaves the same way so it certainly appears to be within the scope of the firmware.
It doesn't appear to be that the fw thinks it's at an endstop as I can fake the X-stop reading by putting paper under the sensor and so get M119 to report either "X at min stop" or "X not stopped" at will but in either case the X won't move.I'm a softie myself doing embedded stuff at work and playing arduino and ESP at home so quite happy to grub around in the code (at least in a look but don't touch way as I'm not set up to change it at the moment) but I'm finding it quite hard to find my way around it (!). Would you care to give me a hint of a good place to start looking for the handling of moves like this?
-
As X now homes OK, it has to be a configuration issue. Please share your latest config.g and homing files.
When you attempt an X move and it fails, are there any messages on the GCode Console page of DWC afterwards?
-
Bingo!
I'll explain the detail ina moment but I wanted to stop you doing anything else on this as it's now fixed. -
Thanks dc42 for all your help with this, it's really very much appreciated.
Prompted by your request for the files I went through the config.g again in "forensic mode", partly to tidy it up so you could see the wood for the trees and I came across a line
M563 P0 X19 D0 H1 ; Define tool 0. CS added X19 to account for temp fix to use 2nd extruder mounting position
which I now realise is totally wrong and was telling the fw to map the X movements to an axis numbered 19. I now know that the correct way to do what I was trying to do, offset the X carriage, is G10 P0 X19 Y0 Z0. RTFM!The background to this is that I recently set about servicing my Huxley, print quality had deteriorated and it turned out to be that the X carriage plate was disintegrating on one side. RRP Huxley X carriages have two mounting positions for the hot end, the second meant for a 2nd extruder, so as a temporary work around I switched to using that but it is 19mm further left. I misread the wiki page and tried to offset the carriage using M563 when I should have used G10.
Of course I'm now kicking myself for breaking the basic rule of only change one thing at a time. 30 odd years doing this sort of thing and I still fell for that one!Once again, thanks so much for your help, I've learned a lot in the process and I'm looking forward to using the new mesh bed leveling to fix my long standing issues with a slightly warped Huxley bed...
