New Wifi install problems, need help
-
Please can you send M669 without parameters, also M584 without parameters, and let me know what the responses are.
-
M669
Error: M669 parameters do not apply to Cartesian kinematicsM584
Driver assignments: X0 Y1 Z2 E3:4:5:6:7:8:9:10:11 -
Did you follow this for connecting and setting up your endstops? https://duet3d.com/wiki/Connecting_endstop_switches
-
Yes. Active high, endstops correspond to correct axes, leds on, then off when triggered. Mechanical switches.
-
This is a long shot.
I know that M584 without any parameters seems to be reporting the correct drive mapping (apart from the fact that non existent drives 4 to 11 are mapped to non existent extruders but that shouldn't matter). However, there is no M584 command in your config.g therefore the values that are reported must be the default settings. Normally M584 would go before the other axis parameters like steps per mm, speeds accelerations etc). So maybe, (just maybe), the absence of the command is what is throwing things.
So try putting this near the top of your config.g file (as the first line after "Drives").
M584 X0 Y1 Z2 E3. This will force the drive mapping to occur before steps per mm etc are assigned.
Like I said, it's long shot but…....
-
Tried it, no help. Here's the sequence:
Home X; X carriage moves to end stop, triggers the end switch but doesn't stop, then returns about 3/4 length back
Home Y; X carriage moves to end stop, returns to center bed, Y carriage moves 10 mm, everything stops.
Home Z; X carriage moves to end stop, returns halfway, Z raises about 30 mm, everything stops.E works as it should
-
Have you tried making a new config with the online configurator ? https://configurator.reprapfirmware.org/
-
Yes, I've done that three times, tried someone else's and put this one together myself.
-
I think you may have your motor wiring swapped, in particular I think you may have the X motor connected to the Z motor connector. Please check. The order of the motor connectors is ZA/ZB, Y, X, E0, E1 which may not be what you were expecting.
-
@ Id1 - It might be an idea if you posted your homing files too.
-
David, you called that one. Switched those two drives and now it does all those things on the z axis that it did on the x axis. So:
homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Tue Nov 21 2017 10:14:37 GMT-0500 (Eastern Standard Time); Relative positioning
G91; Lift Z
G1 Z5 F6000; Course home X and Y
G1 X-365 Y-255 F3000 S1; Move away from the endstops
G1 X5 Y5 F6000; Fine home X and Y
G1 X-365 Y-255 F360 S1; Absolute positioning
G90; Go to first bed probe point and home Z
G1 X15 Y15 F6000
G30; Uncomment the following line to lift the nozzle after probing
;G1 Z5 F100Which tells me that the basic homeall config and probably the individual home configs are incorrect. It also tells me that the motors and drivers are working as they should if only their instructions were right. Especially as I don't use bed or mesh probing, only manual. My usable dimensions are 350X, 250Y and 340Z.
If I can get that all set, then it is just making sure the endstops are working. I think. Ever closer…. -
So, today's results so far:
When homing X; Z lift, carriage moves appx. 10 mm in the correct direction, z lower to original position.
Y Home: Z lift, carriage moves appx. 10 mm in correct direction, Z lowers
Z Home: Z lift appx. 10 mmHomeall: X and Y the same as above, then calls for Z bed compensation adjust with pop up window
Once homing done, though it doesn't really home, I can move X and Y in + directions and - directions until original positioning is reached. When I try Z positioning, X carriage moves in - direction.
The endstop LEDs are all on and will trigger, turn off, when activated. Set at active high. BUT when I look at machine properties in Settings, they are all triggered Yes and when I activate, they all register as No. Perhaps I have them wired incorrectly still?
And I still don't understand what is going on with the movements. We switched Z and X (properly so) yesterday, but they are still wrong when trying for individual movement.
-
Your homeall.g file is a bit screwed up. When you do G1 X-365 Y-255 F3000 S1, movement will stop when an end stop switch is triggered. That is to say, either the X or the Y end stop switch but not both. So if for example the Y axis switch triggered but X was still 50 mm away from the end stop, then when you do the next line G1 X5 Y5 F6000 Y will move to plus 5 but X will move to 50 + 5. Then your fine homing line G1 X-365 Y-255 F360 S1 will move back until one or other switches trigger again so Y will go to zero but X will still be 50 and will therefore never be homed. You can tell on the web interface as the axis buttons only turn blue when homing has been successful. So you need individual G1 S1 moves for each axis. e.g after G1 X-365 Y-255 F3000 S1 you then need G1 X-365 F3000 S1 and G1 Y-255 F3000 S1 and the same for your fine homing (or just home each axis in turn).
HTH -
Your homeall.g file is a bit screwed up. When you do G1 X-365 Y-255 F3000 S1, movement will stop when an end stop switch is triggered. That is to say, either the X or the Y end stop switch but not both. So if for example the Y axis switch triggered but X was still 50 mm away from the end stop, then when you do the next line G1 X5 Y5 F6000 Y will move to plus 5 but X will move to 50 + 5. Then your fine homing line G1 X-365 Y-255 F360 S1 will move back until one or other switches trigger again so Y will go to zero but X will still be 50 and will therefore never be homed. You can tell on the web interface as the axis buttons only turn blue when homing has been successful. So you need individual G1 S1 moves for each axis. e.g after G1 X-365 Y-255 F3000 S1 you then need G1 X-365 F3000 S1 and G1 Y-255 F3000 S1 and the same for your fine homing (or just home each axis in turn).
HTHIan, thanks for trying to be helpful, however his homeall.g file is OK (I think) for a Cartesian printer. On a Cartesian printer, when an endstop switch is triggered, only that axis is stopped. CoreXY is different because of the shared motors.
-
@1d1:
So, today's results so far:
When homing X; Z lift, carriage moves appx. 10 mm in the correct direction, z lower to original position.It should be lifting Z by 5mm, not 10mm. Are you sure that your Z steps/mm is correct in the M92 command? You currently have it set to 4000. What pitch of leadscrew are you using for Z, is there any gearing between the motor and the screw, and are you using a 0.9 or 1.8 deg motor?
See later in my reply for correcting your endstop configuration.
@1d1:
Y Home: Z lift, carriage moves appx. 10 mm in correct direction, Z lowers
Evidently the same issues as for X (too much ZS movement, incorrect Y movement).
@1d1:
Z Home: Z lift appx. 10 mm
Is that all it does? Please post your homez.g file.
@1d1:
Homeall: X and Y the same as above, then calls for Z bed compensation adjust with pop up window
The popup window means that you have homeall.g configured to use a Z probe, but you don't have a Z probe configured. See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Homing_Z.
@1d1:
The endstop LEDs are all on and will trigger, turn off, when activated. Set at active high. BUT when I look at machine properties in Settings, they are all triggered Yes and when I activate, they all register as No. Perhaps I have them wired incorrectly still?
The config.g file you published earlier has this:
M574 X1 Y1 Z1 S0 ; Set active high endstops
but S0 sets active low endstops. Change it to S1.
-
Besides, the end stops have yet to be reached by the carriages at all so even if one did the trick for all, I'm not to that point yet.
-
Ian, thanks for trying to be helpful, however his homeall.g file is OK (I think) for a Cartesian printer. On a Cartesian printer, when an endstop switch is triggered, only that axis is stopped. CoreXY is different because of the shared motors.
Ah OK. Apologies then. I'm too used to my CoreXY and assumed that Cartesian kinematics would work the same way.
Just to be clear, on a Cartesian the command G1 X-nn Y-nn S1 will move both axes until one end stop is triggered but then continue with the other axis until it's own end stop is triggered, yes? -
Vast improvements and really almost there. Rewrote the home files a bit and the homeall file. Now, the motors keep running in jerky motions after hitting the end stops so I am going to reduce the timeout idle to see if this does the job. After that, I'm hoping to have it sorted!
In 574 above I had added a "1" to each drive to make it active high. Didn't realize I needed instead to identify the drives as X1 Y2 etc and then making them active high by having it be S1 instead of S0. It's been a pain but I'm learning a lot! -
Ian, thanks for trying to be helpful, however his homeall.g file is OK (I think) for a Cartesian printer. On a Cartesian printer, when an endstop switch is triggered, only that axis is stopped. CoreXY is different because of the shared motors.
Ah OK. Apologies then. I'm too used to my CoreXY and assumed that Cartesian kinematics would work the same way.
Just to be clear, on a Cartesian the command G1 X-nn Y-nn S1 will move both axes until one end stop is triggered but then continue with the other axis until it's own end stop is triggered, yes?That's correct.
-
@1d1:
Vast improvements and really almost there. Rewrote the home files a bit and the homeall file. Now, the motors keep running in jerky motions after hitting the end stops so I am going to reduce the timeout idle to see if this does the job. After that, I'm hoping to have it sorted!
In 574 above I had added a "1" to each drive to make it active high. Didn't realize I needed instead to identify the drives as X1 Y2 etc and then making them active high by having it be S1 instead of S0. It's been a pain but I'm learning a lot!The X, Y and Z parameters specify the location of the endstops. See https://duet3d.com/wiki/G-code#M574:_Set_endstop_configuration.
I'm not sure what you mean by "keep running in jerky motions". Can you explain, or post a video?
