First homing attempts failing.
-
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.
-
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
