Dual Y Motor Configuration

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

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

2. Move X-410 until it hits the barrier (either with stall detection, or with reduced motor current)
3. (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.

[dc42]

@3DPrintingWorld said in Dual Y Motor Configuration:

If I turn the threshold up the belts start skipping before the other end makes contact with the frame

Are you sure that is it possible for the second motor to carry on turning, without the axis binding and that causing a stall?

[droftarts]

@3DPrintingWorld What firmware are you on? You need to be on RRF 3 for this to work properly as you have it set up at the moment, not RRF 2. Send M115 at the console, and post reply.

Ian

[3DPrintingWorld]

@dc42 I think you might be right! The attached picture shows the belt arrangement. Maybe the X and U axis's are keeping the X-axis from twisting. I will try taking the second motor(P9) out of the config and see if I can move it with my finger after its been homed.

I do see an issue that the x(u) carriage must be away from the switch(end of travel) when homing the Y otherwise when the Y motor stalls the x(u) carriage will be pulled into the switch. My plan for home all was to home X & U first then move them away from their switch before homing the Y.

Is it possible to turn the x and u axis off the moment the Y detects a stall?

[3DPrintingWorld]

@droftarts Yep, I just switched to RRF 3 last night. I can do this when I get home but I think the issue may be that the belt arrangement is keeping the x axis from twisting. I will confirm both tonight.

[3DPrintingWorld]

@dc42 I tried multiple things, I can verify that the issue was not that the motor could not turn. I ended up getting it to work once I turned up the motor current to 50%. If I turned that up any more or the S value I would get skipping. The first time its homed and its far out of skew the farthest side does not always make contact. Then by the second or third time it always makes contact but has the tendency to bounce off.

I think I'm just going to add a second switch to the Y axis and hopefully call it a day.

[bot]

@3DPrintingWorld

That's an interesting belt arrangement. Is the reason you did not drive the Y axis from one motor because you couldn't get a belt long enough to go around the whole way?

[3DPrintingWorld]

@bot No not really, I debated a few different arrangements but decided this one was the best and I had a extra driver on the duex5. Less maintenance, setup and believe it or not probably the cheapest option out of the four. If you are interested I have been posting pictures of my progress on my twitter.

!