PanelDue and Motors will not function properly with Duet Wifi
-
So to be clear...
I'm using the Home command as the means to control the motors, but even using G92 to assign the current position as home it's the same behavior.
All the motors work on the extruder/E0 driver. But when I simply swap it to any other driver it starts complaining about phases A & B being disconnected so that's why I swapped the wiring initially. (Thinking it was phase A&B not 1&2)
In the config if I assign E0 to Y it'll have the same issues.
I also thought maybe the motor config was an issue, so I copied the config of E0 (known good) to all the axes and it still had the same issues.
-
The correct way to test individual axis motors is to send G91 to select relative mode, followed by G1 H2 commands. For example, G91 followed by G1 H2 X20 should move the X motor by the equivalent of 20mm.
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:
The correct way to test individual axis motors is to send G91 to select relative mode, followed by G1 H2 commands. For example, G91 followed by G1 H2 X20 should move the X motor by the equivalent of 20mm.
The issue appears to be with homing:
2/8/2020, 7:44:40 AM G1 H2 Y20 <--- Motors does not move
2/8/2020, 7:44:34 AM G91
2/8/2020, 7:44:28 AM G28 Y *<--- The motor is making an audible hum and torque
2/8/2020, 7:44:10 AM G1 H2 Y20 <--- Motors moves
2/8/2020, 7:43:50 AM G91 -
2/8/2020, 7:44:28 AM G28 Y *<--- The motor is making an audible hum and torque
Thinking issue is with Homing I wired up an endstop and re-enabled it in the config.
The motor works just fine till I trigger the endstop and then it locks up as before, and now reports the phases are disconnected:
2/8/2020, 8:15:30 AM G28 Y
Warning: motor phase A may be disconnected reported by driver(s) 0
Warning: motor phase B may be disconnected reported by driver(s) 0
2/8/2020, 8:15:13 AM G1 H2 Y20 <--- Motors moves
2/8/2020, 8:14:46 AM G91 -
@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.
-
@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
