First homing attempts failing.
-
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.
-
Rails for the machine are THK SHR-R 4 way ball bearing square profile linear rails with double blocks mounted on Mic 6 gig plate 15.88 mm thickness. This plate is flat to 1/1000 of the inch. Sr12-b 12mm ball screws for z with single ball nuts mounted with gimbals bearing attachment to prevent miss alignment. It's a ganty style bed traveling Y, X Traveling gantry Diamond head. The the 3 extruders are mounted on another gantry slide just above the head bowden style with separate belt drive and 2 additional X steppers. These are not being used now, because I need the external setup to add these. The belt setup is just 2 steppers motors on either end handed the same direction belt runs between 2 16 tooth 10mm wide GT2 pulley to pulley with belt fixing clamp centered on the axis for attachment to gantry and bed. Belts are level and tensioned via tension gauge. The 3 bowden extrudes are separate to remove the weight from the print head but still travel the equal distance to keep the extruder lines less than 125 mm in length. This system worked perfect with the smoothie setup, but lacked the ability for 1 additional extruder to do y,m,c,k instead of r,g,b color. I'm just trying to get the board to handle basic 3 axis movement before I connect anything else. Which for some unknown reason it won't. I know these boards are better than any other 3d print electronics out there. I just can understand what is wrong.
Here are the Y motors 2.2 amp set onboard drivers series wired 24 volts. Moving good based on commands you requested I perfom. These axis plain move easy at 1 amp each. These are the largest because the move the largest load.
NEMA 23 Frame,
KL23H2100-35-4BM
570 oz In. Hybrid Stepper Motor
1.8° / 200 Steps Per Rev.
3.5 Amps Current,
4-wire, Bi-polar,
1/4" dual shaft,Black: A+
Green: A-
Red: B+
Blue: B-These are the X motors set for 2.1 amp on board drive series wired 24 volts moving perfectly through the commands you ask me to perform. Distance speed acceleration all good.
KL23H2100-35-4A Single Shaft, it is more accurate
381 oz In. Hybrid Motor
1.8° / 200 Steps Per Rev.
2.7 Amps Current Per Phase
Inductance 2.1 mH
4-wire Bi-polar,
NEMA 23 Frame"The 2 Z motors current set 1.35 amp on drive series wired, move fine."
NEMA 17 BIPOLAR STEPPER MOTOR 62 oz-in
(1/4" dual shaft with a flat) 62 Oz In. Hybrid
1.8° /200 Steps Per Rev.
1.68 Amps Current Per Phase
Rated Voltage: 2.8V
Resistance: 1.65 Ohms
Inductance:2.5 mH
4-wire Bi-polarAs in 1 previous post I am a machinist at Hopecreek nuclear generation Station in Salem NJ. I have spent a lot of time on this machine and Stand behind the build quality. It is exceptionally free and accurate level plumb square. I employed granite surface plate, inspection gauge techniques along with fully machining all components on my 5 axis machining center. As I also provides All lines are electromagnetically shielded where signal applies. I truly believe something the processor is reading or not reading is the issue. Is there a way of tracking line by line what the processor handles are to see what its doing when this happens? A literal play by play of a homing attempt, to compare with the physical action to the file and commands its preforming?
-
Also Cooling, 1, 50mm 24v fan always "on" mounted behind the board 50mm away blowing directly on the rear side. Another 50 mm arranged the same way toward the front. Each on-board drive has a heat sink thermally adhered to the driver like the ramp mini aluminum heat sinks. Along with 1 more on the voltage reg. The board is mount with 65 mm nylon standoffs and 3mm threaded rod to an acrylic backing plate. All lines to and from are fastened with mini cable organizer made for this setup to maintain proper spacing and no restrictive pressure or tension has been applied. Stepper motor cases are bonded to small diodes and than to earth. Diodes are to prevent any gnd line potential from entering, only allowing potential from motor case to enter gnd.
-
Please can you explain what you mean by "Moving good based on commands you requested I perfom." Are you saying that G1 S2 moves are now working well?
I've thought of one other possible explanation for irregular movement, which is bad power. This could be caused by a faulty power supply, or by the screws in the Duet's VIN terminal block not being tight.
The only difference between G1 S1 and G1 S2 moves is that with S1, the move will be terminated when the corresponding endstop switch is triggered, and the location along that axis will be set to the value you defined in an M208 command.
Please try the following:
- Send G91 to put the printer in relative coordinate mode
- Send various G1 S2 moves. For example, G1 S2 X50 F750 should move the head 50mm in the +X direction; and G1 S2 Y-100
F750 should move the head -100mm in the -Y direction. Check that the movement is smooth and the movement amount is correct. Caution: it won't stop at the endstops. - If that works, try similar moves, but use S1 instead of S2. The motion should be the same as it was with G1 S2, except that if you press the endstop switch for the axis that is moving, that should immediately stop the move.
HTH David
-
Ok, I mean Moves are exactly performed by the machine as the gcode commands that I input. What ever input I provide it performers. It will also run a print file if I remove the g28 lines from the file. With g28 line included, no matter how they are written, the machine will behave irregular and not perform. The error which simply state G28 homing failure will be presented. This comes from the web interface, Repitier, even pronterface. It does everything so far except homing commands. It's the way it relates to the g28 command. This board or my firmware are simply not performing that action. It stops with manual S1 entered but not during a g28 command. G28 isn't working. It goes the wrong way sometimes, stops sometimes but other attempts it will not stop or it will head the correct direction. However it has never performed a single home x and y complete. I will also get x homed to the switch and stop, but y slams into it's endstop, or y will stop short of it's switch stop with X. No combination of any code allows for both to complete. not even completely separate, like home x separately and home y or vice versa. It just won't do it. I'm gonna have to live without homing i guess. Of course this means no probe either. I'm am beginning to think there is an internal short somehow between the x and y endstop connector to the processor. 1 signal is probably interfering with the other. I think I might swap x for E0 and Y for E1 and see if it homes. Have you ever seen an internal fault that could cause this?
-
The machine stops every time with if g91 entered than g1 s1 x300 f3000. every time it stops. measuring distance for many different distance moves are all accurate. the only difference is it fail to do so with g28 as the command. It's hands down a g28 issue and nothing else. It won't stop with g1 s2 x300 f3000 only with s1. What boggles me is if the the homing files are good why on Gods green earth is this happening only with the most important gcode it will ever perform? The same finding are true for Y and I connected the X switch connector to the z endstop and stopz the same way. Every thing for the user machine builder and config stand point is correct. That leaves only the firmwares handling of this code. It's Duetethernetfirmware version 1.19.2
Control All
Tool Heater Current Active Standby
Tool 0
T0
Heater 1
active 21.5 °CBed
Heater 0
off 21.5 °CTemperature Chart
0
50
100
150
200
250
Machine Status
Head Position X Y Z
0.0 0.0 0.00
Extruder Drives Drive 1 Drive 2 Drive 3
0.0 0.0 0.0
Sensors Vin Z-Probe
24.5 V 0Machine Control
Print StatusG-Code Console
G-Code Files
MacrosFilaments
Settings1:03:30 PM
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet Ethernet version 1.19.2 running on Duet Ethernet 1.0
Board ID: 08DDM-9FAM2-LW4S8-6JKD4-3SJ6L-9LXMY
Static ram used: 17684
Dynamic ram used: 95748
Recycled dynamic ram: 1256
Stack ram used: 1136 current, 3832 maximum
Never used ram: 12552
Last reset 00:24:37 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 12640 bytes (slot 0)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 25.9, current 38.5, max 38.8
Supply voltage: min 24.3, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-11-26 13:03:29
Slowest main loop (seconds): 0.009094; fastest: 0.000000
=== Move ===
MaxReps: 6, StepErrors: 0, FreeDm: 240, MinFreeDm 237, MaxWait: 373714ms, Underruns: 0, 0
Scheduled moves: 40, completed moves: 40
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
State: 5
HTTP sessions: 1 of 8
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
12:55:36 PM
G1 S1 X300 F3000
12:54:15 PM
G1 S1 X300 F3000
12:54:06 PM
G91
12:53:52 PM
G1 S1 X300 F3000
12:53:46 PM
G1 S1 X300 F3000
12:53:45 PM
G1 S1 X300 F3000
12:47:32 PM
G28 X
Error: Homing failed
12:46:24 PM
G28 Y
Error: Homing failed
12:44:17 PM
G28 Y
Error: Homing failed
12:43:47 PM
Connection established!
12:43:47 PM
Page Load complete! -
Thanks for your patience. Please can you change the contents of homey.g to the following and then try homing Y:
[[language]] ; Lift Z relative to current position G91 G1 Z5 F6000 ; Move quickly to Y axis endstop and stop there (first pass) G1 Y-300 F1800 S1 ; Go back a few mm G1 Y5 F6000 ; Move slowly to X axis endstop once more (second pass) G1 Y-10 F360 S1 ; Lower Z again G1 Z-5 F6000 G90If that still doesn't work, try sending those commands individually to see if/where I fails.
HTH David
-
Ok new information. Machine won't move x and y in relative cooridants at f1500 and below both directions. It will easily make the moves with G90 Than G0 y50 F1000. It moves slow like it should smooth and near silent. However The same thing in G91 Than G1 y50 F1000 and it smoothly shudders back and forth like it doesn't no the direction. I think it's not homing because it's having trouble moving slowly under relative moves for some reason. Is this handled like a macro and not like a jogging moves or other manual input for moves? That's the only difference and 100 percent repeatable. I read somewhere that the firmware uses different ways of handling moves based on the code. Maybe I have something I'm not seeing configured wrong. At This point I'm back with all external drives tested and conformed by the Gcode U had me exercise before. Same outcome with both internal and external. I switch back to my desired setup, because external drives and there setup are not causing this issue. Now I'm left with 2 challenges. 1st. solve this homing issue. Second Get the bltouch-smart to work. A note on that. On board power up it deploys and retracts and has solid red light lit that stays on. When I try to deploy using test codes it does nothing on deploy and retract. Putting it in test modes, it blinks blue 1 second. no value one probe screen changes value is 0
-
Ok working on your home work and thank you for your patients more!
-
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?
-
Which firmware version are you using? Send M115 to check.
-
Duetethernetfirmware 1.19.2
-
Still can't home machine. Now it's back to changing dir during homing. I goes different ways with no change in files. 2 attempts the correct direction than 1 the wrong way. This is not a hard ware related problem. All the issues external to the firmware or files have been address. Every time I work on the homing I check switches and movement first. I really need some guidance as to how I can't cure this issue. It stops when I manually enter gcode with s1 and travel the correct way every time via that method. However with g28 command it just doesn't work. Is there some bug I don't no about?
-
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.
