Auto Squaring, My axis is hella square...

If you want to try it I will put the firmware up here but I have been rapidly changing this and didn’t want to keep up with revisions yet. So if anyone is ready to try it let me know but until then I will just keep going at it revision free for now. File management is a pain when revisions are many times a day/hour.

Appreciate this Ryan, will try and get a hold of some endstops from here to try it out, want to do some manual bed leveling for my mini Rambo for 3d printing, which apparently needs endstops (Open to any other options though, the bed is perfectly flat and seems like too much of a fuss to have to use endstops just to do a bed leveling once), but I guess I’ll have to get some eventually…

I will wait until it is at the point for testing Ryan. Am certainly keen to try this, but still very new to all this.

 

I need to get comfortable with the software and my machine first before experimenting further than stock setup.

Let me know if you want me to review your changes.

1 Like

Thanks Heffe, maybe when/if I get the x going as well. It’s ugly but functional I had to take a lot of notes by hand. Marlin is seeming pretty scrambled, but incremental updates and overall ecosystem stability probably means a fresh start is near impossible for them. Or who knows maybe that is a well organized program, I guess I wouldn’t really know the difference. Your world is rough, programming is tricky I hope they pay you well!

Really interesting that you’re doing this right now as I spent the past two days figuring out what the issue in the dualXY endstop fork of Repetier was preventing X from working correctly.

Turns out it was just the #ELSE following #DUAL_X_AXIS in Printer.h that comes after the MULTI_XENDSTOP code.

I’m not at all up to speed on Github/Versioning, but I commented on the fork with the issues.

Are you doing this in Marlin now or still with Repetier?

Saw on the main post you are doing this now in Marlin.

The issue there for me was editing marlin to allow zero Extruders seemed impossible. As a workaround, you can edit the ramps pin assignment to dump E0 to usused pin 22. This allows DualX to go to E1, which has E0 pins, and you create an E2 with the old E1 pins for Y. Like so.

 

#define E0_STEP_PIN 22 //Dump E0 pins to usused pin 22 to pass sanity check and allow Extruder 1 to be assigned to “nowhere”
#define E0_DIR_PIN 22
#define E0_ENABLE_PIN 22
#define E0_CS_PIN 22

#define E1_STEP_PIN 26 //Was E0, Now E1 so DualX is assigned to E1 at physical E0 location
#define E1_DIR_PIN 28
#define E1_ENABLE_PIN 24
#define E1_CS_PIN 42

#define E2_STEP_PIN 36 //Was E1, Now E2 so DualY is assigned to E2 at physical E1 location.
#define E2_DIR_PIN 34
#define E2_ENABLE_PIN 30
#define E2_CS_PIN 44

 

 

SWEEEEETTT!!!

DAn the MAN!

Sweet, so you have this fully functional in the repetier firmware? You only had to change three files?

If you look back in the thread I think I found your’s or someones other attempt a few months ago.

I thought marlin and repetier were basically close with repetier just using some sort of config script. But I am at 13 files changed in more than 31 places and that doe not have both the X and Y just the Y.

Short answer, yes, it is working fully on both axes. Here is a copy of my current Repetier-firmware.

http://www.danleitner.com/Repetier.zip

Note, this is based on the development branch, and doesn’t work with CNC enabled (spindle control) or with extruders set to anything but zero I don’t think. I only looked at the xy homing code. As a next step, I’d look into making the same changes to the current master branch of Repetier and see how that works. Obviously, if you are using dual xy motors and endstops on a ramps board, there isn’t a spot for the extruder motor driver so printing would be another issue entirely.

More:

I’m doing some work on my MPCNC so I haven’t done anything but test homing and run a bunch of G1 moves, but it seems to work.

My experience is that Repetier and Marlin are similar but handle many things very differently. I was using Marlin for everything (2 kinds of 3D printers and MPCNC etc) until I noticed a stuttering issue at certain feedrates, and after testing all the hardware as good, switched to Repetier and the problem disappeared.

It was then I started looking for dualXY endstop code and found the Pull request on github by ikidd which worked for Y but not quite for X. This included changes in 5 files and some specific changes to configuration.h

All I did was figure out why the X-code wasn’t working and found a couple other things in general.

I don’t know if you’d consider moving to Repetier as the main version of the firmware for MPCNC, but it seems to be more straightforward and compartmentalized than Marlin. I’m happy to help with firmware development either way, but take note I am NOT a software engineer, I just grew up with some.

 

Post doesn’t seem to be showing up…trying again.

Short answer, yes, it is working fully on both axes. Here is a copy of this dualXY Repetier-firmware.

http://www.danleitner.com/Repetier.zip

Note, this is based on the development branch, and doesn’t work with CNC enabled (spindle control) or with extruders set to anything but zero I don’t think. I only looked at the xy homing code. As a next step, I’d look into making the same changes to the current master branch of Repetier and see how that works. Obviously, if you are using dual xy motors and endstops on a ramps board, there isn’t a spot for the extruder motor driver so printing would be another issue entirely.

More:

I’m doing some work on my MPCNC so I haven’t done anything but test homing and run a bunch of G1 moves, but it seems to work.

My experience is that Repetier and Marlin are similar but handle many things very differently. I was using Marlin for everything (2 kinds of 3D printers and MPCNC etc) until I noticed a stuttering issue at certain feedrates, and after testing all the hardware as good, switched to Repetier and the problem disappeared.

It was then I started looking for dualXY endstop code and found the Pull request on github by ikidd which worked for Y but not quite for X. This included changes in 5 files and some specific changes to configuration.h

All I did was figure out why the X-code wasn’t working and found a couple other things in general.

I don’t know if you’d consider moving to Repetier as the main version of the firmware for MPCNC, but it seems to be more straightforward and compartmentalized than Marlin. I’m happy to help with firmware development either way, but take note I am NOT a software engineer, I just grew up with some.

 

On closer inspection, it seems the original changes from ikidd are somehow causing the issues with extruders=1 and cnc enable, so I am going to see if I can get a clean copy of the dev. Branch working without those issues…

Also, he reassigned endstops/endstop flag pairing which isn’t great, so maybe I can get it working with “Extended endstops”

Bummer, I’ll keep going on my side then with Marlin. Moving the extruder stepper I hope solves the next problem I would have thanks. Hope we both get this going!

[quote="vicious1,post:32,topic:6343"] Bummer, I’ll keep going on my side then with Marlin. Moving the extruder stepper I hope solves the next problem I would have thanks. Hope we both get this going! [/quote]

Ryan put it on github more pepole will help. For Windows is Nice app sourcetree but stuck app from github also do the job. Then you will see how fast it will go.

Github confuses the crap out of me, updating or rebasing last time just added both the old and the new code and I had to try and dig back though and try and fix all the weirdness. Someone else can try and put it up there but I have a feeling it will break severely with every update and I am not going to maintain that. If I get it working I don’t see any huge reason to update very often.

Github confuses the crap out of me as well, but I’m working on it, so I hope to have this up there soon. Still want to make a bit of progress and do some testing.

For now, updates will be here with date_stamp in format YYMMDD_Filename_REV

www.danleitner.com/170901_Repetier_001.zip

Today I rewrote the changes into a clean copy of the Repetier Dev Branch got rid of a bunch of issues with the pull request on Github and used the existing “extended_endstops” logic.

It compiles and tests fine for me with CNC support enabled. (The issue that remains is that if you set number of extruders >0, the direction pin for X2 gets locked so X2 only moves in one direction. But for a Ramps using 5 motors, there isn’t an extruder)

I’d be very interested if anyone out there wants to test this.

I am looking through your file right now. I have never opened up Repetier firmware. So crazy there are about 1/3 the tabs/files in there. Wow, I need to do some more research on the differences and dig around a little bit in the files. Can you think of anything off the top of your head that Marlin does or does have compared to Repetier or have you just been sticking with Repetier?

I see they both treat G0 like G1, that’s a bummer. Might have to look into that next.

Success!!!

Independently X, Y, And Z all work with dual end stops!

Now,

1-Moving the extruder driver to allow for both axis to have dual drivers (Maybe, Try Dan’s Method, or see what else is available out there I am pretty sure I have seen other dual-dual driver ramps so I think this edit is out there.

2-See if dual-dual endstops work, there are some number assignments that might need to be adjusted if two are working at once. (I don’t know what I am talking about).

 

 

What did a google search and theses very forums popped up!!! Fingers crossed. Sorry I am excited…don’t mind me.

https://www.v1engineering.com/forum/topic/marlinramps-patch-to-use-extruder-drivers-as-additionnal-xy-drivers/

Holy shit!

So close. I am in over my head now I need help.

The previous post didn’t work…luckily it was way easier. Just move the E0 pin in pins_ramps.h all to 70, E1 to the old E0, add a E2 set and give them the old E1 pins…Boom!!

So right now there is dual driver dual endstops on X, and dual drivers on Y.

So now, you folks that know How to program here is all that is left, I think.

#2 from above, Enabling the extra endstops has them sharing a “flag” (I guess you call it?)

Holy shit it works!!! I got it, X and Y dual drivers and dual endstops!!!

Who wants to try it? I will make a video ASAP it looks nuts.