Dual Y Motor Configuration

3DPrintingWorld

I see what you are saying, but they will operate together. The issue is, If something bumps the axis when the motors are not holding then the axis is going to skew. To get around this on the MK3 the z-axis runs into the frame and skips steps to square up, then the motors run together. In this case its done with lead screws not belts.

droftarts

@3DPrintingWorld There's a couple of ways you can do this. If you have a probe, you can use that to level the axis to the bed, see: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

If you'd rather run the Z into a hard stop, you can, but I'd turn down the stepper driver current using https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M906_Set_motor_currents in your homing or macro gcode files. Alternatively, you could use stall detection, along with moving the two Z motors independently, to home them; see https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing and https://duet3d.dozuki.com/Guide/Independent+Z+motors+and+endstop+switches/18

Ian

3DPrintingWorld

Thanks @droftarts I will review the information you provided. Just to be clear its the Y axis not the Z. I was just using the Z-axis on the MK3 as an example.

If I used stall detection, each motor would have to have its own driver, right?

Phaedrux

@3DPrintingWorld said in Dual Y Motor Configuration:

If I used stall detection, each motor would have to have its own driver, right?

Correct. But at that point you may as well just drop the motor current and ram it into the frame to even it up. That way you're depending on a physical endstop rather than back EMF being detected in the driver.

Either way, it's probably best to use separate drivers for Y if you have some to spare. The Z axis doesn't do a lot of movement. It's just up and hold, up and hold. So a dual Z in series is no problem. But for a Y axis where you may be slinging a heavy load to and fro you're better off with separate drivers. It also allows you to get fancier with your homing/squaring routine.

3DPrintingWorld

Thanks @Phaedrux! Just to clarify as I probably did not give enough info, its not a i3 but a core xy'ish IDEX. Sounds like I'm better off with two drivers, which I do have available. Should I run the y axis all the way in the negative to a physical barrier to square it up, then touch off a end stop switch in the positive direction, or use the physical barrier for homing too?

Phaedrux

Yes, I assumed it was not an i3.

Here's a rather long thread that goes through getting a dual X axis motor setup using 2 endstops.

https://forum.duet3d.com/topic/13252/issues-setting-up-duet-wifi-with-dual-x-axis-motors-and-endstops?_=1581018240512

In your case, since the axis isn't likely to get significantly skewed, I would probably go to a single endstop first just to get the axis position defined, and then you would know how far to push into the opposite end. You could even use the same end as the endstop if you had an optical endstop that allowed you to move somewhat passed it.

Your Y homing macro would look something like this

Move to -Y until endstop triggered
back off a bit
split Y into two seperate axis
drop motor current
push one motor into the frame so it stalls out
push the other motor into the frame so it stalls out
recombine the Y axis
back off passed the optical endstop
rehome Y again

Your Y axis will need to be able to account for some twist though.

3DPrintingWorld

@Phaedrux I'm just getting to this now. Using a optical switch is not a bad idea, but I would like to get this running with the setup I currently have. The switch is at +Y which does not have a physical barrier and I can not run past the switch. The physical barrier is at -Y.

So I am thinking I would have to:
Move to +Y until endstop triggered
Move to -Y until it almost hits the frame
split Y into two separate axis
drop motor current
push one motor into the frame so it stalls out
push the other motor into the frame so it stalls out
recombine the Y axis
rehome +Y

I am wondering why I need to split the y axis motors before I run the carriages into the frame? I'm not using stall detection, right? I'm just running the carriages into the frame so cant they just be moved together?

Phaedrux

Yes that sounds doable.

@3DPrintingWorld said in Dual Y Motor Configuration:

I'm just running the carriages into the frame so cant they just be moved together?

Possibly. As long as the current is set low enough and the distance commanded is long enough to guarantee a stall on both motors.

3DPrintingWorld

@Phaedrux Were you previous suggesting that I split the motors because I would be using stall detection?

Phaedrux

The way I described it could go either way. Splitting them up leaves it open for that. But there's more than one way to bake a cake.

dc42

@3DPrintingWorld said in Dual Y Motor Configuration:

@Phaedrux I'm just getting to this now. Using a optical switch is not a bad idea, but I would like to get this running with the setup I currently have. The switch is at +Y which does not have a physical barrier and I can not run past the switch. The physical barrier is at -Y.

So I am thinking I would have to:
Move to +Y until endstop triggered
Move to -Y until it almost hits the frame
split Y into two separate axis
drop motor current
push one motor into the frame so it stalls out
push the other motor into the frame so it stalls out
recombine the Y axis
rehome +Y

I am wondering why I need to split the y axis motors before I run the carriages into the frame? I'm not using stall detection, right? I'm just running the carriages into the frame so cant they just be moved together?

It's a lot easier with RepRapFirmware 3, because you don't need to split the motors into separate axes. You can set up homing with M574 so that it uses individual stall detection on each motor.

3DPrintingWorld

@dc42 Can I still use the mark forged kinematics in RRF3?

Right now I think the idea is to:
Step 1: Move Y+ to hit the endstop switch to gauge the distance to the physical barrier ie the frame.
Step 2: Run Y- to straighten the X-axis out by running into the frame.
Step 3: Run Y+ into the endstop switch again for home.

I am wondering if it would be possible to reduce movement and eliminate the first step. If we are using stall detection do we need to know the distance to the physical barrier?

3DPrintingWorld

@Phaedrux Ok, I'm a new user so I'm just trying to understand your suggestions.

droftarts

@3DPrintingWorld Yes, Markforged kinematics are supported in RRF3. See https://duet3d.dozuki.com/Wiki/Gcode#Section_Parameters_for_Cartesian_CoreXY_CoreXZ_CoreXYU_CoreXYUV_MarkForged_kinematics_RRF_2_03_and_later_only

If you know where the physical barrier is, as in how far from the bed, why not just use the stall detection (or just ramming it into the physical barrier until it stops) to set the origin, rather than a physical endstop? You can use M208 to define how far the physical barrier is from the bed. You would have to put the endstop at the other end anyway, so you would have to wait for the axis to move to the other end to trigger the endstop. For example, if your bed is 300x300, but the area the X and Y axis can cover is 400x400, and hitting the physical barrier at X min is -50 off the bed, and -50 for Y, you:

In config.g M208 is set as

; Axis Limits
M208 X-50 Y-50 Z0 S1                             ; set axis minima
M208 X300 Y300 Z200 S0                           ; set axis maxima

Move X-410 until it hits the barrier (either with stall detection, or with reduced motor current)
(or at the same time as 2) Move Y-410 until it hits the barrier.

If you use stall detection, and you have 2 motors on Y, using RRF3 it will do the Y straightening up automatically. In RRF2, if you may have to split the two Y axis motors into Y and U (one motor each) and home them individually.

Hope that helps.

Ian

3DPrintingWorld

@droftarts Thanks for the info, that helps. I'll going to switch to RRF3 first. The kinematics are working with physical endstop switches but the x-axis is naturally out of square for some reason, but it should not matter as I am relying on a y axis motor on each end of the x axis to keep it square. Once I figure out the homing sequence.

I was wondering how the start of the bed was specified, I will revise the limits in my config to reflex this as you have stated.

Seems like it would be better to use stall detection if I'm going to run into the frame as if its sitting right next to the frame when homing is started it would stop as soon as its sensed and not continue thru the entire move.

Just wondering, I read that stall detection is not as accurate as a physical endstop however I cant think of any downsides to using this on the Y axis. It's a IDEX so I need physical endstops for the X and U axis but I cant think of a reason why this would be an disadvantage for the Y.

dc42

@3DPrintingWorld said in Dual Y Motor Configuration:

Just wondering, I read that stall detection is not as accurate as a physical endstop however I cant think of any downsides to using this on the Y axis. It's a IDEX so I need physical endstops for the X and U axis but I cant think of a reason why this would be an disadvantage for the Y.

The only disadvantage I can see is that if you use the resume-after-power-down facility, you might get a small Y axis shift.

3DPrintingWorld

@dc42 That's not too important to me but it might be to other who might build this printer and use my configuration. I already have a physical endstop switch. Is it possible to stall out on the one end then lastly use the physical end stop for a more accurate home?
I was working on this last night but my stall detection was not working unless I specified sensorless homing in the config

3DPrintingWorld

I got sensorless homing to work but the dual y axis motors are still tied together. What am I missing?

Config
M584 X0 U2 Y1:9 Z5:6:7 E3:4

M574 Y1 S4

Homey
M915 Y S10 R0 F0

dc42

@3DPrintingWorld said in Dual Y Motor Configuration:

I got sensorless homing to work but the dual y axis motors are still tied together. What am I missing?

What exactly do you mean? The motors should indeed be tied together, except that when homing them they should stop individually as they stall. Bear in mind that when one motor stall, the other will be moving the carriage by itself; so the load on it will increase, and if the stall threshold is set too low then it may report a stall immediately.

3DPrintingWorld

@dc42 It seems to work well but one side is not making contact with the frame. Both motors seem to stall at the same time. I see what you are saying about the increased load on the other motor. If I turn the threshold up the belts start skipping before the other end makes contact with the frame. I have the motors turned down to 30%, do I need to increase the speed with the threshold? The thing is, It really does not take much torque to skew the frame which is why I'm relying on the motors to keep it square.

Seems like I have something wrong with the programming. Is my M915 command right in my Homey script? It knows that "Y" is two motors.