First homing attempts failing.
-
No the code you had me use doesn't work. Machine didn't move. I did change the g91 to g90 and the g1 to go and it did it. However it didn't change the measurement to reflex a homing completetion. It won't take relative gcode at all. Shudders back and fourth then stops. Absolute moves, and there no problem. That means the total hardware package is in good standing. It's in the code that way on this one. This is the message I got after running what you provided in my homey.g
m120
g91
g1 y-1 f6000
m121now I have no idea why this came up, but instead of homing failed thats what came back. And no it didn't make the moves.
When I hit the yellow homing buttons on the interface, that is the use of my homing files right?
I'm sorry for the delayed response, it's very busy here at the moment with lots of new developments in progress.
It looks like debugging has become enabled. That could be the cause of the problem, because of the volume of debug output that is produced by the Duet if you use full debugging. How are you sending the commands? Are you using Repetier Host? If so, Repetier has a habit of enabling debug because they appropriated the M111 P parameter for their own use; so you need to either turn off all the echo and debug features in Repetier, or use a different program to send commands. The recommended way of sending commands to the Duet is through the web interface. Pronterface is also mostly OK.
If you are already sending the commands through the web interface, check that you don't have a M111 S1 command in config.g. You can use M111 S0 to turn debugging off.
HTH David
-
I'm only using the web interface at the moment. M111 S0 written in file. I am having an issue with step per unit. This problem has happened using both internal and external drives. The steppers are in series. 2 per axis on either end. If you want call them high end and low end motors. They are handed, or faces the same direction. They are belted pulley to pulley with equal tooth/ diameter each. So mechanically they are perfectly balanced.
The steps per mm are correct no matter how I calculate. 1/16 with interpolate or 1/128 without. I mean the measure of the travel from a manual gcode command like G1 X150 will be exactly that distance configured each way. This is with both drive systems. However if I home the machine the controller does something different when it makes the movement happen and produces error. It responds with much slower lower power movement that isn't high or stable enough to move the head or table to the switch. It will however move the wrong way with ease.
Another issue is after it fails at homing, how is it able to assess an distance reading and clear the requirement for homing for the when it never stuck a switch?
Now a little info from my stapple program for milling. My mill uses uccnc from cnc drive, palgardi designs. This system uses machine coordinates and work offset coordinates. G54-G59 and has to home to work. Homing and actually sticking a switch for all axis is like God to that mill. Nothing ever happens without that process happening. If a switch isn't hit it refuses to jog or run a file. If a switch is disabled it will try to back off thinking it's at a switch traveling a short distance and stops if it doesn't reset. A detailed list of reports will flash on the screen instructing me to check the switch state. When I move that machine via command I can simple type in the MDI window x10 and it goes. Y-123 and it goes. This is because there are 2 coordinates systems. Why are printers not handled like the proven systems that came before it? Also if a switch is ever struck outside of the homing command run that machine slams to a stop with run shaking power. It will not proceed in the face of uncertainty. And to respond to some of the comments other have made on the forum before. You should not have to build machines that can tolerate endstop collison. This is impossible on a mill. I use nema 42 4200 oz steppers with 5mm lead ball screws. Thats over 2300 lbs of force required to mill heated stainless and inconel. End stop will be instantly destroy this way. Switches most work. And software soft limits are used where switches are only use single per axis.
-
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?
