First homing attempts failing.
-
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
-
yeah i'm gonna exchange the board through filastruder. The circuit between endstop input and mcu path is bad I guess. Or there is a bad chip somehow. It's nothing I've done nor anything firmware can help.
-
1. What EXACTLY does it do when you send G1 X-295 F1500 S1 ?
2. If you send M119 before that command, what does it report?
3. What type of endstop switches are you using?
-
Hoping that I don't get flamed for trying to help but here goes…........
Config.g has this M574 X2 Y1 Z1 E0:1 S1 ; meaning that the end stop switch for the X axis is at the high end. So doing this "G1 X-295 F1500 S1 ;move -310 mm stop at switch" - is going to send the X axis away from the switch, not towards it. It looks like it was correct in the earlier homex files where the X moves were positive. If the switch has in fact been moved to the low end, then the M574 line needs to be changed too.
Also, this line "G1 X5 F1000 : move back slowly" has a colon before the comment, not a semi colon.
-
first answer, it starts to move, than immediately stops. Less than a mm of travel. Than the x axis "head position indicator" from web control reports that x has made it's total travel distance to the end stop when it hasn't.
Second answer, m119 reports x end stop not stopped before the g1 command.
Third answer, as stated before, 1 switch at -x and 1 at x 295 both wired in series to the 2 outer pins of the end stop with magnetically shielded instrumentation grade wire. Both switches a bare normally closed like Omron brand with roll style levers. Dido for Y. All other wiring including steppers are twisted and routed away from all signal.
My switches are not the problem. My config and homing files have changed due to trying anything to work, but nothing does. It won't move because it views the end stops as already activated when they are clearly not. With every tool available showing then as not stopped, lit leds, m119 reports, and so on. After it finally does move as strikes a switch, it ignores it. This is true even when the travel during homing is the correct direct speed and S1 is present. It does not sense the switches from an internal firmware respect as far as motion control is concerned. From a data reporting respect it does properly interpret the switches and there actions. It's an internal MCU/ firmware bug. If it's been this way for 2 months despite everyone's attempts to solve it, it's an incurable problem, or no one has witness this bug yet. But I have!
-
This board should probable be sent directly to the individual who wants to prevent people from going through this hell that I has. a month of machining and mechanical work, pouring all my talent into a printer/router that is as mechanical accurate and powerful as a small cnc mill and 2 month fighting to configure a board that is simply incapable of performing it's job, due to a flaw of some sort. It has to be a hardware issue, and I mean the board not the printer. Last week I put the smoothie board back in and it worked great. They just don't support the features I require.
As I stated before, I have built 7 cnc machines before this unit. mach3, uccnc, usbcnc, arduino/ramp 1.4, smoothie, and Haas machine. Everyone of them took a day or two to configure, but I achieved success with everyone of them and everyone still work flawlessly except smoothie, because I switched to duet. And here I am. I'm not inexperienced in anyway. It's not me!
-
Another issue is that I report to this forum every answer requested, however the same questions keep being asked. I've answered about the end stop switch type 7 times in this post. I even uploaded the manufactures full specs for them. Word by word play by play detailed explanation of there wiring type, sent many config.g and homing files. I've answered timely and in-depth, withheld nothing and the response to my effort on this forum is more of the same questions, but no insight to the problem. I've performed gcode moves many times as asked and reported result in word and in file form. I've emailed detailed machine reports and put more effect into receiving a response to this issue than I'm willing to debt most users ever due. You would think the persons responsible for promoting this product and firmware, would want a resolution as well.
I understand there are a lot of people to help, but how long does a person have to be strong along thinking the an end insight only to understand the is no end, no answer? I've even offered compensation to help the effort. It appears not even paying for help will work. I still don't have a return shipment authorization to exchange the board for another.
-
@sjason1377
I have no affiliation to Duet - I'm just an end user like you. Twice now I've tried to help and pointed out issues that I have spotted with your configuration/homing files. Instead of any sign of gratitude all I see is lengthy rants. It seems to me that you haven't even bothered to read my posts and instead you just go on and on about it being a problem with the board and saying that "it's not me". The issues that I have spotted are with your homing and/or configuration files which I'm afraid to say are down to you. I would suggest that if you spent a little less time ranting and little more time paying attention to those who are trying to help you, that your problems would have been solved long ago. For my part, as you can't be bothered to read what I post and show no sign of gratitude, then I can't be bothered to try and help. Sorry.
