Firmware CoreXY + DualX help

mael

Hi, 
I have a modified CoreXY kinematics (fixed Y, dual X Hbot style). in motion.h and motion.cpp and I have managed to drive Y and one of the X axis.
Problem is with DualX. When I select second extruder the X motor is not switched. Also in X Homing is the behavior without switching the X motor (X1 homing towards Xmin and then to Xmax).     
I know, that DualX is for cartesian machine, but where is the code, for switching the X axis. Maybe there is a chance to apply this motion.cpp & motion.h ? 
Motors and Drivers are working. Tested. 

Thank you for the best firmware. I'm using it on other printers.

regards,
Matej

mael

Version of Repetier firmware: version 1.0.2.

Thanks

mael

Anybody here to help me? 
I cannot switch to second X motor. On Cartesian type it works, but there is no X compensation. 

Regards,
Matej
 

Repetier

You can simply search for the dual x axis flag and find all parts where it is of interest. Most important are the stop/enable/direction handling in i think it was motion.h.
I do not really understand how this is supposed to work with corexy as this always moves 2 motors for a pure x move and i also assume not moving a motor would not make it stay at a defined position.

mael

Thank you. I was unclear. Please take a look at the picture:

https://cdn.hackaday.io/images/3545991485251102223.png

I have changed code below. Y is OK and works, X1 also. I cannot find, where I can link extruder2 with X2 motor, like it is in cartesian machine. Sorry, but I am not a coder and need a little help. 

In motion.h line 595:

#if DRIVE_SYSTEM == YX_GANTRY

       if(isYPositiveMove()) {

            Printer::motorX--;  //++;

            Printer::motorYorZ--;

        } else {

            Printer::motorX++;  //--;

            Printer::motorYorZ++;

        }

#endif

In motion.cpp line 1172:

#elif DRIVE_SYSTEM == YX_GANTRY

    corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS]; //+ cartesianPosSteps[Y_AXIS];

    corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS]; // - cartesianPosSteps[X_AXIS];

    corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS];

Thank you for your help,
Matej

mael

Also changed for pure X movement, forgot to include in post above:

In motion.h line 552:

#if DRIVE_SYSTEM == YX_GANTRY || DRIVE_SYSTEM == ZX_GANTRY

         if(isXPositiveMove()) {

            Printer::motorX++;

            //Printer::motorYorZ++;

        } else {

            Printer::motorX--;

            //Printer::motorYorZ--;

}

line numbers are maybe incorrect, due to testing. 

Regards,
Matej

Repetier

Ok, i understand what you do, but that is no corexy system, also you might want to use the functions as it is least required modification. One big problem is that y moves need both x motors to move the same time. So in reality you have a 4 axis + e axis motion system. Firmware until v1 only supports 3+1 axis. Normal dual x just has only one of the 2 x motors enabled or mirrors signals. You need to solve 4 motions here which is the main problem.

If you use a due based board the simplest solution would be to use dev2 branch on github. It is in eatly development stage so no jam control, lcd or bed leveling work at the moment. But it has amodular system supporting up to 7 axis, so use a axis for second x motor and write your own drive system class that moves x and y depending on active extruder with your equations. See corexyz implementation which is quite similar and a good start. So inout is xyz and output xyza positions. Should be quite easy to adapt. Ony thing as mentioned, v2 currently only works on arduino due based boards. Haven‘t ported avr types yet.

mael

I see. 
I think, I'm not capable to do this. 
How does then mixing extruders work? They need 3 active steppers. 

regards,
Matej

Repetier

All motors are handled as one motor and a switch decides which motor does the next step, so for calculations in is still only one axis.

when i write dual.x for v2 we will see what is really needed there. I think then the solution should be quite easy. Just a few lines difference in the cartesian dual x code should solve the problem. So have a look at the progress and ask back when it is implemented.