Need Firmware Help (RAMPS 1.4)

[Phife]

Hey guys,

Im on the home stretch of my LCD 3d printer build.

I need some help with the firmware. I have a dual Z axis on my machine with two steppers. No other steppers on the machine. I need to be able to home both Z axis steppers together then independently to square up the Z axis. I have 2 limit switches one for each side.

Im not sure the best way to do this with the Sprinter firmware I am using. Additionally I'd like to be able to do a tilt release by making one Z stepper raise about 3-4mm before the other side raises the same amount, then they can both return to their original location +0.1mm or whatever layer thickness I choose... I think I can do that by just issuing Gcode commands in Creation workshop so I dont think that needs to be in the firmware.

Currently I have one stepper on the Y output of RAMPS and the other on the Z. Both steppers move if I issue gcode commands or if I hit the appropriate buttons in creation workshop, but I cannot home them together.

Anyone have any idea of what I need to do? My knowledge of firmware and software is pretty limited.

Thanks

[Finhead]

[Phife]

Yeah, I downloaded a couple of the firmwares from the Muve1 but I have idea what part is needed to be changed to allow the dual axis. Really that firmware is much more complex than the standard Sprinter firmware that im using and is working, just a pain, I cant use the control buttons in creation workshop as they will skew my axis. Im just using gcode to move both axis together, I get close to the home switches then home each axis individually.

That Muve1 firmware has a ton of stuff I dont need, and I dont know where to find the stuff I do need.

If anyone can point me in the right direction. Id be happy to post my current firmware for anyone to look at, but its just the basic Sprinter with the correct step/unit and such for my machine.

[Finhead]

[sitzme]

Since you can use custom code in CW there are alternatives. Forget about normal XYZ orientation and relationships for your application for a minute. You have two motors to control that just happen to be attached to the same hardware. Lets call them A1 and A2 for axis1,2. Most of the time you want them to move together but at times you want independent motion.

To peal;
(all moves incremental)
A1 moves xx steps (lift one edge)
A1 and A2 moves yy steps (rip it off the glass)
A2 moves xx steps (level the build plate)
A1 and A2 moves together to lower to the layer thickness

What you call any axis matters to a degree but what if you call A1 "Z" and A2 "X"? Or any of A,B,C. Just an axis that you are not using.
To peal;
(all moves incremental, Z is one side of vert axis and X is the other in this case)
G1 Z.02 (lift one edge)
G1 X.1 Z.1 (rip it off the glass)
G1 X.02 (level the build plate)
G1 X-.11 Z-.11 (lower to .01 layer thickness)

For homing you may need to be carefull and make sure that either both axis home at the same time or jog them to a position that is close enough that the mechanical parts can flex while one axis is homing. Manual jogging will be an issue in this case since you control one motor at a time. You can always type in the commands to get close though.

I think that you can do this all with gcode and not have to mess with the firmware.

I may have missed some detail but I am short of sleep for a couple nights. This should give you a bump start to figure it out though.

[Finhead]

Moving independent and together will be a issue for sure, that is why I suggested the firmware from the mUVe1 printer it takes care of that in firmware and allows you to move each axis independent and together with no issues. Here is a quote from a email from Dean awhile back, if you look through the code in the firmware and the slicer gcode you can clearly see how this works. Why try and reinvent the wheel when all the work has been done for you?

"Since the command to move the Z, then the E, and then move them both back would take a lot of code for Slic3r, we simply built it in. It also has the nice feature for us in that we define the Z and E axis separately, so we can move them separately, but due to other firmware changes we can address changes to the Z axis and have it impact both the Z and the E, so if you jog the Z axis they both move"

[Phife]

Thanks guys for your help,

Sitzme, im doing that right now, just running gcode and moving it close to the switches to home, but none then none of the creation workshop controls work. Which is fine for testing but I'd like to get something figured out.

Finhead, Thank you for all your help. I really appreciate it. I just have no idea what I need to do with that code. The muve1 firmware doesnt work with my machine, nothing moves. Like I said, I am really bad with software and really have no idea where to even start. Also, I really dont have the time to learn it right now.

So Im hoping you could help me with my firmware? I'd like to do exactly as you described. Can I send you my firmware for you to add the peel move to it?

[Finhead]

[Phife]

Ok, with a bit of playing around i managed to get the muve firmware running on my machine, the Z steppers move together when i press the z arrows in CW. But I cant seem to home it correctly. Does anyone know if the mUVe1 uses two home switches for its Z? what input are they using for the E0 axis?

Since i only have one axis with two steppers id like to use two home switches to square up the axis. Is this possible with this firmware?

Thanks for all the help guys! I appreciate it!

[mUVe3D-Dean]

The mUVe 1 firmware only uses the Z min endstop. When the printer is homed to the endstop you can then move the Z axis, but you won't be able to move anything before homing. When the endstop is hit during homing it sets both the Z and E to 0, then you'll be allowed to jog using the program controls and it'll move both Z and E as one. You set parameters for peeling with M650 and then call M651 to peel. There is no way to individually control them other than with changes to the peel parameters. They're effectively locked together.

If you need help configuring the firmware for hardware other than RAMPS then just jump over to the mUVe 3D message board and let me know what you're running.

It is not possible to use 2 Z endstops with our firmware as you describe, that would require substantial changes. Specifically to the homing sequence.

-Dean