First homing attempts failing.
-
I've sent you a PM.
If you send the commands in the homey.g file manually (the ones that I gave you earlier), one by one, does the Y axis home properly?
-
Hello again. I noticed sending command manually to home y that the machine does not move intailly. However after a few seconds the head position indicators on web interface changes around 300 or mm to the neg direction. Than the machine move the wrong way
-
I have placed bare n/c switches wired in series at both ends of x and y to eliminate improper dir of homing from preventing the travel to stop.
-
The machine does not stop. The endstop state does indicate the switch stuck during a manual command. From not stopped to stopped. Machine fails to actually stop with S1 command clearly written in all homing files
-
The endstop state does indicate the switch stuck during a manual command. From not stopped to stopped.
I'm sorry, I don't understand - what do you mean by "stuck" ?
-
The fact that the measured readout changes before travel takes places indicates a bug of sort to me. I can't see how the measured value can reflex a travel the firmware has not yet performed. This is contrary to the idea the steps per or any movement setting could be the cause. The printer moves exactly the correct distance and speed, also dry print runs files correctly, with a plotter pen used to sample motion. This on works with G28 removed from the print code. With G28 it's a non starter. G0 y-100 S1 F3000 and it stopped at switch. G1 or G28 it doesn't. G0 also does not change measured reading until moves happen. G1 and G28 displays changes than move happens. Sometime the wrong way, but not always
-
Struck or hit, meaning switch has be activated in software and physically hit
-
I mean struck not stuck
-
I monitor the switch states at axes endstop location and see the leds change from lit to unlit. Web interface machine property tab show not stopped before switch is hit, than stop when bed hits the switch. machine does not stop. The fact that there are series wired switches at both ends and both work tells me it doesn't matter if the motor direction is wired wrong. switch still works, and files still contain S1 command. It is just ignoring it's commands
-
OK, let's start with X homing.
First I want you to test X motion at various speeds, including low speeds. Send G91 to select relative movement. Then send G1 S2 commands such as:
G1 S2 X50 F1000
That should move the head 50mm in the +X direction at 1000mm/min. If you change the X50 to X-50, it should move in the reverse direction.
If that works, send the same commands but with F100 instead of F1000. Is the movement still correct, and still smooth?
Also, please confirm which firmware version you are running. To find out, look on the Settings->General page of DWC, or send M115.
-
Is there any diagnostic info to record when homing fails that provides more information to help me. Or is there a better version of firmware that doesn't do this that works with bltouch smart still?
-
Your post crossed with mine.
-
Yes
-
sorry It does both 1000 and 100
-
smooth and correct distance
-
it even handles F10 as a feed rate. Extremely slow but made the correct dir and distance
-
Firmware Name: RepRapFirmware for Duet Ethernet
Firmware Electronics: Duet Ethernet 1.0
Firmware Version: 1.19.2 (2017-09-01)
Web Interface Version: 1.19 -
OK, so X motion is working correctly. What do you have in your homex.g file? If you send the commands in homex.g manually, one at a time, does it home X correctly?
-
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time)G91 ;relative moves
G1 z5 F3000 ; move head up
G1 X-295 F1500 S1 ;move -310 mm stop at switch
G1 X5 F1000 : move back slowly
G1 X-295 F360 S1 ;Move -310 stop at switch
G92 X0 ;tell firmware where we are
G90 ;absolute move
G0 X0 Z2.5 F1500 ; move to X to center z upno it performs g91 g1 z5 f3000 fails at g1 x-295 f1500 s1. i tried moving the s1 to the front, no change. with s2 it moves not with s1
-
s1 command limit checking not working. however switches are in good standing. insulated, tested responding in web interface and from m119 call, all check correct. something internal with this s1 checking is bad
