PanelDue and Motors will not function properly with Duet Wifi
-
@bearer said in PanelDue and Motors will not function properly with Duet Wifi:
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
now reports the phases are disconnected
If you look closer at the actual output it says they may be disconnected. Could be a settings issue. Motor specs and config to confirm/rule out.
It just moved literally 17 seconds earlier.
I copied the default E0 settings to the others since the motors worked when plugged into that driver. -
Please post your config.g and homing files.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in PanelDue and Motors will not function properly with Duet Wifi:
Please post your config.g and homing files.
Oh boy that's a tall order with how many revisions I made.
Here is the ones I'm using as of my previous post. The endstops I was not sure of so did one as NO and one as NC; see which one works the way I expect.homez.g
homey.g
homex.g
homeall.g
config.g*Also someone may have burned out the Y driver so I reassigned it to E1.
-
I'll have to do more testing at home, reading the files I wonder if maybe it's because I only have one motor connected?
Looks like wen homing Y it's also giving commands to Z and since there is no Z wired...Just curious, why use G1 over G28?
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
Just curious, why use G1 over G28?
Because G1 allows you to target a specific axis. G28 executes homeall.g which has moves for all the axis. As you noticed there is also a move to lift the Z axis slightly to get it out of the way for travel. So having no motor connected will result in errors.
Here's a guide that goes through some commissioning steps that may help.
https://duet3d.dozuki.com/Guide/Ender+3+Pro+and+Duet+Maestro+Guide+Part+3:+Commissioning/39
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
one as NO and one as NC
If at all possible, physically wire them as NC.
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
Oh boy that's a tall order with how many revisions I made.
We're not psychics and the devil is usually in the details. So you'll need to keep us up to date if we are to help you efficiently; something to keep in mind going forward
-
Good news had a bunch of progress...
Motors seems to be working mostly.Z motors were working in opposite directions so I inverted the wiring on one and now they work in unison.
Only trouble bit now is when I'm homing the X and Y. The motors don't seem like they are entirely in sync with each other. I thought with a CoreXY it'll differ the movements of the motors to produce the same carriage movement of a Cartesian, is that correct? (Forward/Back, Left/Right)
When homing Y it'll draw the carriage forward but there will also be lateral movement too. About 100mm Left from the most extreme point to Home; but not smoothly, it'll travel a bit and then jerk over, and travel more OK, then jerk again, etc... (I double checked to make sure the belts are taught)
Similarly, X will do the same, moving the carriage back towards the extreme away from Home and latterly about 100mm Right.
I'm using those Drylin bearings on the carriage, when mounted they are snug with the rail. And on the Y i'm using normal linear bearings.
So I can't seem to get X to Home since for that I'd need what? 600mm Y travel? (300mm cubed is my intention)
*Not sure if related but I'll still almost randomly get warnings of Drive 0 having it's phases disconnected and have to reset the machine, at which point it'll be OK again till the next random warning. Could the motor itself be bad, or not enough current?
If I try just movement it does the same...
G1 X50 Y50
Which I would expect a 45 degree movement is again a very small movement on X but a much greater one on Y. It's hard to tell exact since the machine think's it's done 50 on each axis.
*Also does the "M564 H0" as mentioned earlier in this thread override the endstops? I had used it and then was moving the axis to test the endstops but they did not stop the movement even thought they triggered. But when using the default Homing commands the axis did stop as expected.
Please let me know if you need any additional files, or config's to test.
-
I suggest you test the motor individual using G91 followed by G1 H2 Xnn and G1 H2 Ynn commands. Check that the other motor doesn't move and that movement is at 45 degrees to the axes. https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter#Section_Testing_motor_movement.
Have you made sure that the belt runs whose lengths vary with carriage position run exactly parallel to the X and Y axes? User @mrehorstdmd has posted a useful diagram to illustrate this in other threads.
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
*Also does the "M564 H0" as mentioned earlier in this thread override the endstops? I had used it and then was moving the axis to test the endstops but they did not stop the movement even thought they triggered. But when using the default Homing commands the axis did stop as expected.
Endstops will only stop movement if they are triggered during a homing move, which is denoted by G1 H1 . The H1 switch (or in older firmware versions S1) denotes it as a homing move.
I believe this is the diagram that DC42 mentioned.
-
-
Hi there,
So the belts look to be OK... I'm pretty sure it's the X driver, I must have damaged it in a previous test.
I disconnected the belts and ran the commands as you suggested...
For the X command, the X motor remained still with no holding torque and the Y remain still with holding torque.
For the Y command, the X motor remained still with no holding torque and the Y rotated as expected.
So I simply swapped the motor connections and same behavior but in reverse. I went into the config and reassigned them to E0 (X) and E1 (Y), and now it'll traverse as expected, when homing Y with the carriage remaining still and being drawn forward.
One thing though, how do I get the X homing to move to the left of the machine, right now it's going to the right. I tried setting the config to run the motor backwards and also tried inverting the wiring like with the Z motor, but it still moves to the right.
I assume in the homing file I could just invert the movement of the X movement, but is there a more official way of doing this?And a bit off topic, any suggestions about the heatbed curve? By default it heats too slowly and errors out thinking it's runaway. And when I try to auto-tune it using "M303 H0 S120", it wont save due to the curve. Fans, A/C are off, and I put foam insulation on the bottom side minimize heat loss.
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
how do I get the X homing to move to the left of the machine
Homing direction is controlled by the homing macros homex homey homez homeall. The direction of the moves will depend on the location of the endstops. If you're using a left hand coordinate system with 0,0 in the front left corner then x- will be to the left, x+ to the right, Y- to the front, Y+ to the back.
The positions of the endstops will need to be defined in your M574 command in config.g as well so that when the endstop is hit the firmware knows to set the position to either the minimum or maximum defined with M208.
-
@Phaedrux said in PanelDue and Motors will not function properly with Duet Wifi:
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
how do I get the X homing to move to the left of the machine
Homing direction is controlled by the homing macros homex homey homez homeall. The direction of the moves will depend on the location of the endstops. If you're using a left hand coordinate system with 0,0 in the front left corner then x- will be to the left, x+ to the right, Y- to the front, Y+ to the back.
The positions of the endstops will need to be defined in your M574 command in config.g as well so that when the endstop is hit the firmware knows to set the position to either the minimum or maximum defined with M208.
Sorry I don't quite follow.
I did try editing the homing macros to make the machine move as expected while homing, but, when X is homed it still thinks it's at the far right side, so if I then try and move it with a positive value it'll slam into the side/endstop flag. And it wont let me move it a negative since it's at 0.; Axis Limits
M208 X0 Y0 Z0 S1
M208 X280 Y280 Z280 S0
; Endstops
M574 X1 S1 P"xstop"
M574 Y1 S1 P"ystop"
I also tried inverting the X endstop, that did was make it not move. As well as flipping the min and max but no change of behavior when moving after homing.
; Axis Limits
M208 X280 Y0 Z0 S1
M208 X0 Y280 Z280 S0
And the endstop limit...
M574 X280 S1 P"xstop"
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
And the endstop limit...
M574 X280 S1 P"xstop"
https://duet3d.dozuki.com/Wiki/Gcode#Section_M574_Set_endstop_configuration
-
Don't mess with motor wiring ot M569 to get the homing direction right. Change only the commands in the homing files.
Please post the contents of your homing files, and confirm the locations of your endstop switches.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in PanelDue and Motors will not function properly with Duet Wifi:
Don't mess with motor wiring ot M569 to get the homing direction right. Change only the commands in the homing files.
Please post the contents of your homing files, and confirm the locations of your endstop switches.
Hi there,
Both endstops are triggered near Alpha in the previously posted photo. With the "Front" being the side with the two motors.
I changed X to be at the Highend so now it'll move and trigger with no other meddling, but of course it's now at +280 instead of 0.
config.g
; Endstops
M574 X2 S1 P"xstop"
M574 Y1 S1 P"ystop"
M574 Z1 S1 P"!zstop"
homex.g
G91
G1 H2 Z5 F600
G1 H1 X285 F600
G1 X-5 F600
G1 H1 X285 F180
G1 H2 Z-5 F600
G90
homeall.g
G91
G1 H2 Z5 F600
G1 H1 X285 Y-285 F600
G1 H1 X285
G1 H1 Y-285
G1 X-5 Y5 F600
G1 H1 X285 F180
G1 H1 Y-285
G1 H1 Z-285 F180
G90
G92 Z0
-
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
M574 X2 S1 P"xstop"
https://duet3d.dozuki.com/Wiki/Gcode#Section_M574_Set_endstop_configuration
Xnnn Position of X endstop: 0 = none, 1 = low end, 2 = high end.X2 will give you 280. X1 will give you 0.
-
@bearer said in PanelDue and Motors will not function properly with Duet Wifi:
@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:
M574 X2 S1 P"xstop"
https://duet3d.dozuki.com/Wiki/Gcode#Section_M574_Set_endstop_configuration
Xnnn Position of X endstop: 0 = none, 1 = low end, 2 = high end.X2 will give you 280. X1 will give you 0.
I understand, but if it's X1 I get 0 and then it wont mover left or right, since it wont move into a negative, just like how it wont move beyond 280 since that's what I set the far limit to. And otherwise it'll slam into the endstop flag if I moved it using a positive movement command.
If I set it for X2 then it's at +280 and I can move it using negative movement commands, but I don't think I've seen an option in Cura to invert an axis movement commands. That and it'd all be mirrored based off the way it'd appear in the slicer, wouldn't it?
-
In a cartesian printer i would say your motor turns the wrong direction, but not familiar with corexy. In any case if you want X=0 when homing you need to use X1 as a parameter.
