First homing attempts failing.
-
Suggestions:
1. You are using external drivers for X and Y, but you have M350 X128 Y128. You should set X and Y to 16 in that M350 command, even if you are actually using higher microstepping on your external drivers. I'm not sure that using X128 Y128 in M350 will cause a problem, but it might. Leave your M92 steps/mm at 800 if that is correct for the microstep setting on your drivers.
2. What types of external drivers are you using for X and Y? You may need to extend the pulse width to more than 2us. Try T4 in your M569 P10 and M569 P11 commands until everything is working.
3. I suggest you test basic motion first. Send G91 to put the printer into relative coordinate mode. Then send these commands and check that the movement is as expected:
G1 S2 X50 F3000 ; should move the head 50mm in the +X direction
G1 S2 X-50 F3000 ; should move the head 50mm in the -X direction
G1 S2 Y50 F3000 ; should move the head 50mm in the +Y direction
G1 S2 Y-50 F3000 ; should move the head 50mm in the -Y directionHTH David
-
As I stated before, I am requesting answers in the most efficient manner to correct my issues. This benefits both of us. I have 2 years backround in cnc millturn 5 axis setup and control. I already calibrated the machine, once movement happened, by placing it on my mill and following the mills with a feed sensitive probe in spindle. The board produces exact move as advertised. The issue with 128 micro in M350 command much be that way. Otherwise I get 1/8 the travel distance. I know my setup well. this is the 3rd printer board I've tried. Smoothieboard lacked the drive flexibility. Arduino, well you no there limits. I like the Gcode on the fly. Printer worked with 3 other boards. The drivers are kl 5056d they come with software and serial port comm to pc for tuning and calibration. Nothing on my side is causing any of this action. My question is this. Regardless if i am right or wrong, asking someone to look at the files and confirm or direct me is actually a separate request than Diagnosing the total build. I just want to know that my config.g and homing files are in correct. I can play tag for weeks over hardware and calibration, but if it's in the files causing the issue, how many times am I going to check what I know already works. Please understand I total get the switches electrically, mechanically and the moves are spot on. It stops sometimes. Homes 1 axis correct, than doesn't other times. but never all 3 completely as a homeall.g or 1 after the next. I'm not even going to test probing until it's reliable first. To answer the request, I get 6.24903 reading from uccnc off the mill, and 6.25 on duet. again sensor to sensor spindle to nozzle test.
If I could just receive conformation that I have properly configured those homing files and that config.g is in order as it relates to homing of axis plains I would be very grateful. If I need to correct them I will receive any advice with much thanks!
-
…....................................
If I could just receive conformation that I have properly configured those homing files..........................No, you haven't. There is an inconsistency between the homing of Y in homeall.g and the homey.g file (clue - the homeall.g looks wrong). Also, if it were me, I'd home Z at the centre of the bed rather than 50mm from a corner but you seem to have far more experience than me so I'll not argue.
-
Ok I tested machine with on board drivers and it homed. This board doesn't work with x y z on external drivers like advertised
-
The Duet does work with external drivers for XYZ. However, the drive voltage available on the CONN_LCD connector is 3.3V, and your external drivers may require 5V.
-
what does that have to do with machine not stopping for the endstop switches? this post is about homing not drivers. It want home and you still haven't commented on the files I up loaded. I hit the home x button and slam. Hit home y and slam. S1 is is write in the file. I see the led go out everytime for the axes homing, but slam and stripping the belt. Please just tell me why that is?
-
; Course home X and Y
G1 X290 Y-290 F750 S1; Move away from the endstops
G1 X-10 Y-10 F1000; Fine home X and Y
G1 X290 Y-290 F250 S1This is wrong if your Y endstop is a minimum one then you are moving negative 290, then trying to move negative 10 it should be +10. As deckingman pointed out this is different in homeall.g from homey.g so you will get a different result depending on how you call homing.
Also you have a very different homeZ from homeall.g I would get the individual axes working homing by them selves, then copy those elements into the homeall.g
-
what does that have to do with machine not stopping for the endstop switches? this post is about homing not drivers. It want home and you still haven't commented on the files I up loaded. I hit the home x button and slam. Hit home y and slam. S1 is is write in the file. I see the led go out everytime for the axes homing, but slam and stripping the belt. Please just tell me why that is?
I have already commented on your files: i pointed out that using M350 to set microstepping on external drivers might be problematic. Ian and Tony have pointed out issues with your homing files.
Another issue I can see with your config.g file is that the maximum speed you have configured in the M203 command is much too high to be achievable, especially in view of your high steps/mm. But that shouldn't affect homing because the commanded speeds are much lower.
Please provide a link to the datasheet for the external drivers you are using, and tell us how you have connected them to the Duet.
-
wont home x not even attempting to move. instant error on screen with on board drivers. Lets forget external drivers, there are all off. Just the board and steppers now. I can jog and thats it. Used configurator to produce new homing files and tried to home. instant failure message. now m122 reports stand still stalled on x and z. this is as standard of a setup as it get. this board just doesn't work.
-
no external drivers. now its just duet! Failure to home still persist. IF type G1 S2 X100 F3000 machine says busy then nothing. Then 30 sec. later the distance reflects a move that didn't happen. Another 30 seconds and then it takes off and slams an endstop. Not even the axis I commanded. last time i tried, z went up then stopped and x went then stopped. the distance didn't change that time. that was a single linear request. This things just no good. Gonna need the warranty honored here.
-
You wanna know why real cnc companys don't have forum and support groups? Because they don't have 1000s of confused unhappy costumers. If there is an issue the fix it. But it's rare they fail. Look for a Haas machine forum, or a Hurco support group. They don't exist. Because they don't need em. want my money back
-
I think the many users of the Duet who have had complete success, are very happy with their purchase, and who enjoy the assistance given on this forum would disagree with you.
It seems clear from your posts that English is not your first language, so you may have misunderstood some of the Wiki instructions. For the same reason you may also not realize how rude your posts appear to an English speaker. David, Tony, and the other frequent posters here are the most helpful I’ve found on just about any forum. If you would work with them rather than arguing I’m sure you would get things worked out.
-
wont home x not even attempting to move. instant error on screen with on board drivers. Lets forget external drivers, there are all off. Just the board and steppers now. I can jog and thats it. Used configurator to produce new homing files and tried to home. instant failure message. now m122 reports stand still stalled on x and z. this is as standard of a setup as it get. this board just doesn't work.
What was the failure message: "Homing failed", or something else?
The motor stall indication is not reliable at low speeds, so the "stalled" indication doesn't matter.
Please share the new config.g and homing files that you are now using.
-
theres nothing but m105 info now. no esponce from the board at all. not usb or ethernet. sd card is good board is not. Like I said its defective hardware. Filastruder is putting the warranty claim issue on U. They except returns for 30 days. They are not going to honor a return due to warranty. The failures reacted every level of function the board has. There is now way Someone could install these thing T cause every function to behave wrong and than stop responding.
-
Ok I got it to move again. Had to reset, erase and reload firmware. Now I'm at a fresh start with all online config tool files. Machine jogs all 3 axis turns, axt power on/off heat on off, but when I try to home a single axis it moves 20mm or so the direction the file says, then back a few stops and reports error g28 yhoming failed. It does this on x,y,z. It's as if it's looking to come off a switch to reset it like my mill will do if the switch is hung up. But the switches checkout. I tried every position active high/ low both ends and a combination of them all. same problem. My homing files request -300 of travel to the switch, but it stops around 10 to 20mm every time. it's just not going far enough. When it does it won't stop "half" the time. I am using all on-board equipment at this point. The switches are just plain n/c contact with rolled lever. "raw switches" wired to the gnd and signal for the endstop connectors. Nothing one the 3.3v supply pin. M122 calls report good data for these switches and I see leds on according to the instructions for when not stopped using n/c and off when stopped. here is the homing file for "Y" I will send just 1 because I want to master 1 at a time.
; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time); Lift Z relative to current position
G91
G1 Z5 F6000
G90; Move quickly to Y axis endstop and stop there (first pass)
G1 Y-300 F1800 S1; Go back a few mm
G91
G1 Y5 F6000
G90; Move slowly to X axis endstop once more (second pass)
G1 Y-300 F360 S1; Lower Z again
G91
G1 Z-5 F6000
G90 -
I'm sorry to hear that you are still having problems getting homing to work.
You homing files look OK and your earlier config file looked OK too apart from the issues that I and other mentioned. So I am wondering whether your endstop wires are picking up inductive interference from the stepper motor cables, giving rise to false triggering. This is not common because the endstop circuitry on the Duet includes filtering circuitry, but it can still happen if the stepper motor wires and endstop wires run close to each other for a substantial distance, and you are not using twisted pair wiring for either the endstop wires or the stepper motor wires. Is your wiring like this?
If so, then to test whether this is the cause, I suggest that you make up a new temporary cable for one of the endstop switches, keeping it completely separate from the motor cable, and use it in place of the existing cable. Or, temporarily connect a spare microswitch or push button to the endstop switch connector instead of the cable to the endstop switch, and see if you can stop the homing move by pressing that switch.
If that fixes it, then you can still have the endstop switch wires running alongside the stepper motor cables if that is what you need to do, but you should use twisted pair for the endstop switch wires. Twisted pair is resistant to inductive interference pickup.
Also, please confirm that you have two wires running from each endstop switch direct to the outer two pins of the corresponding endstop connector, and you are not using a common ground wire or anything like that.
HTH David
-
This is what I used. 1 pair endstops. 3 pair version for stepper drives, when I had them external. 5 pair for a 4 channel relay optccoupler interfaced no longer connected. I assume any triggering of the switch sense curcuit would at least be seen or recorded, would it not? I think the larger issue is it doesn't move. I mean it very slowly lurches toward the switch, hesitates then back up a bit, stops and post an error. It's actually moving and behaving like it's scared to perform. I know it sound crazy, but something before it even tries to move isn't right. It's starting the g28 command on the wrong foot somehow. It also does it from Repitier host over usb, which I only connect to test and remove.
18AWG Instrumentation Cable - Overall Shield
Part Number
Number
of Pairs
AWG
18AWG Instrumentation Cable - Overall Shield Specifications
Conductor Gauge & Stranding
18AWG Class B 7 stranded bare copper per
ASTM B-3 and B-8
Print Legend*
CCI ROYAL 18 AWG XX SHIELDED PAIRS PVC/PVC TYPE
PLTC/ITC E176494 (UL) 105C SUN RES FT4/IEEE 1202
–- SEQUENTIAL MARKING
Voltage Rating
300V
Flame Rating
Passes FT4/EEE 1202 Flame Test
Passes IEEE 383 Flame Test (70,000btu)
Jacket Material
Sunlight resistant black PVC (polyvinyl
chloride)
Applicable Standards
UL Standard 13 Type PLTC
UL Standard 2250 Type ITC
EPA 40 CFR, Part 26, Subpart C, heavy metals per Table 1,
TCLP method
NEC Article 725 (Type PLTC)
NEC Article 727 (Type ITC)
Hazardous Locations:NEC Article 504 (Intrinsically Safe Systems)
Conductor Insulation
PVC
Pair Lay Length
1.25 twists per inch
Resistance
6.60
Ω
/1000’ @ 20°C per conductor
Conductor Markings
Black / White; Alpha-numeric print;
alternate & inverted @ 2.5 inch intervals
Temperature Rating
-30°C to 105°C (-22°F to 221°F)
Shield and Drain Wire
Overall aluminum polyester foil shield with
a tinned copper drain wire
Communication Wire**
22AWG PVC (orange)
Min. Bend Radius
10x diameter
18AWG Instrumentation Cable -
Overall Shield -
Endstop connections. Raw switch side N/C to pin 1 to J33 connector = x
to J32 connector = y
to J19 connector = z
Raw switch side com. to pin 3 to J33 connector =x
to J32 connector =y
to J19 connector =z -
I got it to home x and y partially, if before travels are the same direction. This means I have to move x homing switch, which I will. It won't complete the axis that doesn't hit it's switch first. So if x makes it to it's switch first y stops too. I separated the x and y lines to 2 separate g1 lines hoping if it performs 1 than the other. That failed to happen too. But now it's back to ignoring the switches altogether. The switches are still good. I know if it was stopping at the switches before, it's not them. motors are freed up and I get no other errors other than Homing failed G28 X or Y or Both. It's of an unstable non consistent nature. The way it refuses to complete the gcode isn't the same each time. The conditions aren't changing during a period of testing but the results are. There is nothing of the electromagnetic nature other than the 24 volt server pwr supply that the pc and board share. It's regulated for 3.3, 5, 12, 24 volt with 1 common ground from 120vac mains. 1 10ga copper ground to earth. All cables are shielded except power. I have to think there most be a fault in the ic path causing it to act this way. The last test I tried home x and y and it start heading 100mm y+ the wrong way. How is that possible if the file didn't change for it to actually make a directional mistake?
-
This is what I used. 1 pair endstops. 3 pair version for stepper drives, when I had them external. 5 pair for a 4 channel relay optccoupler interfaced no longer connected. I assume any triggering of the switch sense curcuit would at least be seen or recorded, would it not? I think the larger issue is it doesn't move. I mean it very slowly lurches toward the switch, hesitates then back up a bit, stops and post an error. It's actually moving and behaving like it's scared to perform. I know it sound crazy, but something before it even tries to move isn't right. It's starting the g28 command on the wrong foot somehow. It also does it from Repitier host over usb, which I only connect to test and remove.
OK so the first issue is inconsistent movement. From your post above, when you do a homing move, "it very slowly lurches toward the switch". From one of your previous posts, "IF type G1 S2 X100 F3000 machine says busy then nothing. Then 30 sec. later the distance reflects a move that didn't happen."
I assume you are still using the internal drivers - can you confirm that?
I can think of the following reasons why movement may not be consistent:
1. Stiffness or binding in the mechanics. With power off, do the axes move easily? Don't try to move them too fast with the motors connected, that makes the motors generate power and feed voltage back into the Duet.
2. Insufficient current for your stepper motors:
( a) What is the rated current of your stepper motors? Please provide a link to the data for the motors.
(b) What motor currents do you have set (M906 command in config.g)? 60% to 85% of the rated motor current is normally used in 3D printers.
If you are using 2A or more motor current, are you cooling the Duet with a fan?3. Faulty stepper driver. Do both the X and Y axes behave in the same way? If you suspect a faulty stepper driver, you can use the M584 command to remap the X motor to a different driver and connect the motor to that one - then see if it is any different. M584 must be earlier in config.g than M906.
Once you have G1 S2 moves working correctly, we can sort out any remaining issues with getting the endstop switches to work.
