PanelDue and Motors will not function properly with Duet Wifi

Danal

@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

firex726

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.

homez.g
homey.g
homex.g
homeall.g
config.g

dc42

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.

Phaedrux

@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.

dc42

Thanks @Phaedrux, that's the diagram.

@firex726, belt sections A thru H in that diagram must run parallel to the axes. Sections JKM don't need to.

firex726

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.

Phaedrux

@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.

firex726

@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

dc42

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.

firex726

@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.

firex726

@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.

firex726

@bearer said in PanelDue and Motors will not function properly with Duet Wifi:

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.

Thanks for the suggestion, yea it's my first CoreXY too. I guess the big question is where in the files is it defined that X home is next to Beta motor? I guess worst case I can just dismantle the carriage and flip it so it'll be correct, but I've seen commercial and hobbyist printers with the motors at the front.

Flipping just the one results in the axis being flipped when moving.

@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:

I guess the big question is where in the files is it defined that X home is next to Beta motor?

its between M208 that defines the min/max value, and M574 X1/X2 that defines if the home value is at the min or max value.

firex726

@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:

I guess the big question is where in the files is it defined that X home is next to Beta motor?

its between M280 that defines the min/max value, and M574 X1/X2 that defines if the home value is at the min or max value.

Just in case I tried swapping both M208 and M574, as well at each individually and same end effect. With a positive movement making it move further into the endstop and negative away like I intend.

I wonder, instead of defining it has having X280, Y280, and Z280, could I change it to X-280, Y280, and Z280.

infiniteloop

@firex726 said in PanelDue and Motors will not function properly with Duet Wifi:

Just in case I tried swapping both M208 and M574, as well at each individually and same end effect. With a positive movement making it move further into the endstop and negative away like I intend.

Time for a mental reboot. – Looking at X and Y, you can move your print head along these axes, and, with the end stops, you can tell the Duet which coordinate to reference for any further moves. You’ve got your steps/mm right…

That are the basics. Now, a second concept comes into play: a coordinate system you and your slicer understand. Just to be clear: Cura is quite flexible, so it’s up to you which idea you are most comfortable with.

The origin of this system can be in any corner, it can even be in the center of your bed, leaving you with 4 quadrants to deal with. In config.g, you use M208 to define the area your head can reach, in coordinates relative to the origin you want. These can be negative, too - remember, the end stops are only an initial reference point.

This is key: select an origin of your choice, then, stay with that. If something goes wrong, it’s just a question of Gcodes.

Homing just means to confirm the minimum or maximum coordinate you have defined in M208. It’s that simple. If you become comfortable with your coordinate system, it is easy to detect when a stepper’s direction is inverted. Just invert it in Gcode: dunnit.

firex726

@infiniteloop 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:

Just in case I tried swapping both M208 and M574, as well at each individually and same end effect. With a positive movement making it move further into the endstop and negative away like I intend.

This is key: select an origin of your choice, then, stay with that. If something goes wrong, it’s just a question of Gcodes.

Homing just means to confirm the minimum or maximum coordinate you have defined in M208. It’s that simple. If you become comfortable with your coordinate system, it is easy to detect when a stepper’s direction is inverted. Just invert it in Gcode: dunnit.

Well that's what I thought I was doing... I have two other machines with their origin in the front left.

For M208 I tried it with the default min max at 0/280. And also flipped as 280/0 with the same movement behavior; as well as changing the endstop from Low side to High side, and also motor direction.

I'm not sure what other options I can flip...

Y has been behaving like I intend with no major fiddling, so that's why I assume it's only something with X.