Custom drive system?

I have designed a custom drive system based in scara and polar
I have knowledges in programming but I dont understand the program structure, I also have maths that are needed and are optimized to process the minimun during runtime
I just dont know where to put it
being polar, I also need to set the acceleration
It would be nice if there is a flow diagram or something to understand it

Sorry, there is no nice diagram available. But it is quite easy if you can program.

1. Use the development tree on github
2. Select the next free DRIVE_SYSTEM
3. Search for tests of tuga system. Also it is currently not working correctly it shows all places that need to be changed. Copy them and modify for your math.

Main function is coordinate transformation from position steps in cartesian coordinate into position steps mapped coordate system.
Acceleration is done in cartesian coordinate system not for polar coordinates. So you have to select accelerations that polar system can handle at any position. If you need it mapped to polar coordinate you have to make much more modifications.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

is the rest of this version stable?

yes, i use it all the time and some vendors use it already for production. zhere will some more changes but nothing vital. More minor additions and improvements.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Great, I'm going to make a kind of guide so anyone can add his maths if need

That would be awesome. It you make it a pdf I can include it on my homepage as external source (credits to you) or add a link to your webpage where you describe it. Just let me know what you like.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

well its not so easy as it looks
there are 5 places to replace?
1°configuration.h (the easy one)
2°Printer.cpp what is supposed to do?

#elif DRIVE_SYSTEM==6
    deltaDiagonalStepsSquared = long(EEPROM::deltaDiagonalRodLength()*axisStepsPerMM[0]);
    if(deltaDiagonalStepsSquared>46000)
    {
        setLargeMachine(true);
        deltaDiagonalStepsSquaredF = float(deltaDiagonalStepsSquared)*float(deltaDiagonalStepsSquared);
    }
    else
        deltaDiagonalStepsSquared = deltaDiagonalStepsSquared*deltaDiagonalStepsSquared;
    deltaBPosXSteps = long(EEPROM::deltaDiagonalRodLength()*axisStepsPerMM[0]);
    xMaxSteps = (long)(axisStepsPerMM[0]*(xMin+xLength));
    yMaxSteps = (long)(axisStepsPerMM[1]*yLength);
    zMaxSteps = (long)(axisStepsPerMM[2]*(zMin+zLength));
    xMinSteps = (long)(axisStepsPerMM[0]*xMin);
    yMinSteps = 0;
    zMinSteps = (long)(axisStepsPerMM[2]*zMin);

3°Printer.cpp Homing WTF 0 comments jaja

#if DRIVE_SYSTEM==6  // Tuga printer homing
                                       void Printer::homeXAxis()
{
    long steps;
    if ((MIN_HARDWARE_ENDSTOP_X && X_MIN_PIN > -1 && X_HOME_DIR==-1 && MIN_HARDWARE_ENDSTOP_Y && Y_MIN_PIN > -1 && Y_HOME_DIR==-1) ||
            (MAX_HARDWARE_ENDSTOP_X && X_MAX_PIN > -1 && X_HOME_DIR==1 && MAX_HARDWARE_ENDSTOP_Y && Y_MAX_PIN > -1 && Y_HOME_DIR==1))
    {
        long offX = 0,offY = 0;
#if NUM_EXTRUDER>1
        for(uint8_t i=0; i 0)
            PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[0]*-ENDSTOP_X_BACK_ON_HOME * X_HOME_DIR,0,0,0,homingFeedrate[0],true,false);
        // PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[0]*-ENDSTOP_X_BACK_ON_HOME * X_HOME_DIR,axisStepsPerMM[1]*-ENDSTOP_Y_BACK_ON_HOME * Y_HOME_DIR,0,0,homingFeedrate[0],true,false);
#endif
        currentPositionSteps[X_AXIS] = (X_HOME_DIR == -1) ? xMinSteps-offX : xMaxSteps+offX;
        currentPositionSteps[Y_AXIS] = 0; //(Y_HOME_DIR == -1) ? yMinSteps-offY : yMaxSteps+offY;
        coordinateOffset[0] = 0;
        coordinateOffset[1] = 0;
        transformCartesianStepsToDeltaSteps(currentPositionSteps, currentDeltaPositionSteps);
#if NUM_EXTRUDER>1
        PrintLine::moveRelativeDistanceInSteps((Extruder::current->xOffset-offX) * X_HOME_DIR,(Extruder::current->yOffset-offY) * Y_HOME_DIR,0,0,homingFeedrate[X_AXIS],true,false);
#endif
    }
}
void Printer::homeYAxis()
{
    // Dummy function x and y homing must occur together
}

4°Printer.cpp ???

#if DRIVE_SYSTEM==6
        currentDeltaPositionSteps[2] = currentPositionSteps[2];
#endif

5°motion.cpp supposed system transformation but only returns 0 or 1?

#if DRIVE_SYSTEM==4

/**
  Calculate the delta tower position from a cartesian position
  @param cartesianPosSteps Array containing cartesian coordinates.
  @param deltaPosSteps Result array with tower coordinates.
  @returns 1 if cartesian coordinates have a valid delta tower position 0 if not.

  X         Y
  *        *
   \      /
    \    /
     \  /
      \/
      /
     /
    /
   /
  *  Extruder


*/
uint8_t transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long tugaPosSteps[])
{
    tugaPosSteps[0] = cartesianPosSteps[0];
    tugaPosSteps[2] = cartesianPosSteps[2];
    long y2 = Printer::deltaBPosXSteps-cartesianPosSteps[1];
    if(Printer::isLargeMachine())
    {
        float y2f = (float)y2*(float)y2;
        float temp = Printer::deltaDiagonalStepsSquaredF - y2f;
        if(temp<0) return 0;
        tugaPosSteps[1] = tugaPosSteps[0] + sqrt(temp);
    }
    else
    {
        y2 = y2*y2;
        long temp = Printer::deltaDiagonalStepsSquared - y2;
        if(temp<0) return 0;
        tugaPosSteps[1] = tugaPosSteps[0] + HAL::integerSqrt(temp);
    }
    return 1;
}
#endif

Those are the 5 functions to replace.. and dont know where to start
I have to admit that I'm used to java and maybe is the main problem

2. Initalization

Think of your printer having a cartesian coordinate system. Resolution is defined in axisStepsPerMM[0..2]. Here you compute the min/max positions in that coordinate system and also initialize precomputed values to speed up your later transformation. Please use any of the delta variables, so we do not need to introduce extra variables. RAM is a rare resource on a AVR and nonlinear systems operate already at the edge.

3. Nonlinear systems often need different homing sequences. Caresiens can home any axis independently. Deltas can only all axis to max endstop centering head at max z. So here you have to add your homing sequence that works. Tuge can only home x and y at once so we omitted y and x home does both. It's up to you what's the best.

4. copies z position. Tuga has the same z axis concept as cartesian printer. Only x/y is nonlinear. So we copy the z coordinate in steps.
currentDeltaPositionSteps[2] = currentPositionSteps[2];
you also see nonlinear systems have an additional coordinate system having a delta in their name. These are the real motor positions depending an values assigned during homing.

5. Coordinate transformation - the key part.

uint8_t transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long tugaPosSteps[])

returns 1 on success and 0 if transformation is not possible.
cartesianPosSteps = Position in steps in cartesian coordinate system
tugaPosSteps = New position in nonlinear coordinate system. These get computed in that function.


Hope that helps a bit.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

values at currentPositionSteps which steps per mm relation uses? the linear or the nonlinear?
and also currentPositionSteps is position from absolute 0 or from the last position?

Quote
Gomez.Marcos
values at currentPositionSteps which steps per mm relation uses? the linear or the nonlinear?
and also currentPositionSteps is position from absolute 0 or from the last position?

currentPositionsSteps are in linear = cartesian coordinate system. currentPosition is the float with current position. They are always absolute to the origin, but it is up to you to say where the origin is. With the homing procedure you set an initial value for the linear and nonlinear coordinate system. If you look there you will find something like this at the end of the delta home:

    transformCartesianStepsToDeltaSteps(currentPositionSteps, currentDeltaPositionSteps);

Knowing the homing position stored in currentPositionSteps this also sets the delta/nonlinear coordinates.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

I made everything like tuga system, but when testing, it doesn't worked, and tuga neither works, maybe version 0,91? or tuga never worked?

No, tuge never worked properly. Hadn't had the time to find thereason so far.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

but it doesn't even moves

now I'm trying to modify delta conversion

We got some moves with tuga during homing, but homing always stopped wrong, so we never could really test the normal movement calculations which require a homed state. I'm currently too busy to search the reason for this, but at least it includes all steps I thought were required. But there is a chance that one part that was for delta did not get converted to all nonlinear systems which was required. After all it is a delta handling with modified homing and transformation.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

hi
we have changed delta transformation with scara cinematics and it gives the right number of steps but the stepper moves a different amount of steps

is there any post transformation function that can change step numbers?

transformation code:

uint8_t transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long radPosSteps[])
{
radPosSteps[2]=cartesianPosSteps[2];

Com::printFLN(Com::tX,cartesianPosSteps[0]);
Com::printFLN(Com::tY,cartesianPosSteps[1]);
Com::printFLN(Com::tZ,cartesianPosSteps[2]);
Com::printFLN(Com::tZ,Printer::axisStepsPerMM[0],6);
Com::printFLN(Com::tZ,Printer::axisStepsPerMM[1],6);
float x=(cartesianPosSteps[0]/Printer::axisStepsPerMM[0])-Printer::deltaBPosXSteps;
Com::printFLN(Com::tE,x);

float y=(cartesianPosSteps[1]/Printer::axisStepsPerMM[1])+Printer::deltaBPosYSteps;
Com::printFLN(Com::tF,y);
float ang=0;
if(x<0){
ang=180+((atan(y/x))*(180/M_PI));
}else if(x>0){
ang=((atan(y/x))*(180/M_PI));
}else if(x==0){
ang=90;
}
Com::printFLN(Com::tS,ang);
float m=pow(x,2)+pow(y,2);
Com::printFLN(Com::tP,m);
float z=90-(acos((Printer::deltaAPosXSteps-m)/Printer::deltaAPosYSteps)*(180/M_PI)/2);
Com::printFLN(Com::tI,z);

radPosSteps[0]=(ang-z)*Printer::axisStepsPerMM[0];
radPosSteps[1]=(ang+z)*Printer::axisStepsPerMM[1];
Com::printFLN(Com::tJ,(ang-z));
Com::printFLN(Com::tR,(ang+z));



    return 1;
}

it have some prints for debugging cinematics
and in prints we can see that are the correct values but when we send a movement steppers move always the same direction and grades

Edited 1 time(s). Last edit at 01/23/2014 08:05PM by Gomez.Marcos.

Hello Repetier, Gomez.Marcos

Because our concerns are the same, I join this thread for further discussions with my Repetier, begun in "Compile error with Scott-Russel (Tuga) drive system".

Repetier, could you explain what happens at later stages in the functions
PrintLine :: queueDeltaMove
PrintLine :: queueEMove
PrintLine :: bresenhamSteps, and the Difference between the cartesian and delta versions.

Finally, I would like to understand what conditions trigger the error message Com :: tDBGDeltaNoMoveinDSegment : "No move in delta segment with > 1 segment. This should never happen and may cause a problem!"

My feeling is that we follow a vicious evolutionary path: at first, we have an algorithm for Cartesian machine. We have tricked this algorithm to cope with delta parallel robots. And then we are trying to trick the previous trick, in beleiving that all parallel robots are the same, and that the critical point is that they are non linear. They are not the same, and the critical point is they are parallel...

For example, delta machine are true full parallel robots : you have to move all three axis in parallel to get any cartesian move.

But Scott-Russel mechanisms are not really parallels : X and Z are cartesian, and Y is just non-linear, and also X dependant. You can get an Y cartesian move by activating only the Y motor, and the same for Z. X is cartesian also, but to get a pure X cartesian movement, you have also to make than Y will follow exactly X. Scott-Russel drive systems are more like XY H-gantry, with some non-linear conversion for a single axis, than like delta.

Therefore, I wonder if the right way for a Scott-Russel mechanism is not to adapt the cartesian part of the firmware, forgetting all the delta development. But what about the Bresenham algorithm ?

Edited 2 time(s). Last edit at 01/25/2014 08:00AM by M_Xeno.

transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long radPosSteps[])converts the cartesian to nonlinear steps. The resolution of the cartesian system is given by the steps per mm settings. The result must be steps position for the driven axis. For delta this is the same resolution. If that results in bad mappings you could e.g. double the value or add a new parameter to define scaling.

PrintLine :: queueDeltaMove

Creates a nonlinear move. Difference it that a line is split in sublines and for each end of a subline the above transformation is computed. For the later bresenham algorithm a new virtual axis was added, whcih gets set to the largest delta of al subsegments, so it is always the driving axis. Each subline is then interpolated linear in bresenhamSteps, so it is important to get many subdivisions for nonlinear moves.

PrintLine :: queueEMove

In case of a pure E move this is used. It is more performant then the usual nonlinear interpolation. Nothing to do here as it does not depend on transformations at all.

PrintLine :: bresenhamSteps, and the Difference between the cartesian and delta versions.

Handles the additional virtual axis and goes over all used subsegments of a line, otherwise no real difference.

Using the delta algorthims is the right solution for all nonlinear moves. Having x and z linear only makes computation easiser/faster but the nonlinear y move still needs that part.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks Repetier, so I will follow your advice.

And what about the error message Com :: tDBGDeltaNoMoveinDSegment : "No move in delta segment with > 1 segment. This should never happen and may cause a problem!" ?

No, I do not think it causes a problem. As you see it comes from this code

        if (virtual_axis_move == 0 && p->delta[E_AXIS] == 0)
        {
            if (numLines!=1)
                Com::printErrorFLN(Com::tDBGDeltaNoMoveinDSegment);
            return;  // Line too short in low precision area
        }

What it means is that you had a move that did not cause any step change, which is very unusual. So only if you have a real move it is problem, because your transformation returns the same positions every time and it is probably wrong.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Don't care. I edited an erroneous message

Edited 1 time(s). Last edit at 01/25/2014 12:38PM by M_Xeno.

The solution is

srPosSteps[1] = srPosSteps[0] + HAL::integerSqrt(temp);

your move is the x homing part I guess so y does not change but x does and x is srPosSteps[0] so y will change linearly with x. So at least it makes sense and you also get no tDBGDeltaNoMoveinDSegment messages.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Yes, I found it myself. Please excuse me.

ok but I am getting the right steps values in the transformation (no compilation problems) but they are not the same sent to the stepper where can I print to check the final steps that are being sent to the stepper?
steps_per_mm are ok
we have 400 steps motors with 16 microsteps and mechanical advantage of 8,666 it gave us 154, 062 steps per grade
and the final value at trasnformation is the right one so maybe is a post-transformation function that is sending wrong steps
sorry for my english

Edited 1 time(s). Last edit at 01/25/2014 03:14PM by Gomez.Marcos.

The only post transformation is in

inline uint16_t PrintLine::calculateDeltaSubSegments(uint8_t softEndstop)

which calls the transformation and computes the real deltas for each sub line. So you could add a print there after computing the delta values.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

great thanks this is exactly what I need

here can be seen that something is not ok
X=scara xmotor angle
Y=scara ymotor angle
J=scara transformation Xsteps
R=scara transformation Ysteps
first Z=deltax
second Z=deltay
third Z=deltaz
delta y values are not ok
I only modified configuration.h delta values
motion.cpp transformation
and Printer.cpp pre-transformation values

Connecting...
start
Printer is now online.
Info:External Reset
 X65.73
 Y194.83
 J10125
 R30016
Free RAM:1182
 X65.73
 Y194.83
 J10125
 R30016
X:0.00 Y:0.00 Z:0.00 E:0.00
SD init fail
ok 0
T:0.00 B:0.00 B@:0 @:0
wait
extruder 0: temp sensor defect
heated bed: temp sensor defect
Error: Printer set into dry run mode until restart!
wait
wait
wait
X+=10mm order, it only moves Y's motor in horary direction, after movement it needs to be disconnected because doesnt receive more movements
ok 0
ok 0
 X65.44
 Y194.71
 J10082
 R29997
 Z-43
 Z-19891
 Z0
 X65.16
 Y194.59
 J10038
 R29979
 Z-44
 Z0
 Z0
 X64.87
 Y194.47
 J9994
 R29959
 Z-44
 Z0
 Z0
 X64.59
 Y194.34
 J9950
 R29940
 Z-44
 Z0
 Z0
 X64.30
 Y194.21
 J9906
 R29920
 Z-44
 Z0
 Z0
 X64.01
 Y194.08
 J9861
 R29900
 Z-45
 Z0
 Z0
 X63.72
 Y193.95
 J9817
 R29880
 Z-44
 Z0
 Z0
 X63.43
 Y193.82
 J9772
 R29860
 Z-45
 Z0
 Z0
 X63.14
 Y193.69
 J9728
 R29839
 Z-44
 Z0
 Z0
 X62.85
 Y193.55
 J9683
 R29818
 Z-45
 Z0
 Z0
 X62.56
 Y193.41
 J9638
 R29797
 Z-45
 Z0
 Z0
 X62.27
 Y193.27
 J9593
 R29775
 Z-45
 Z0
 Z0
 X61.97
 Y193.13
 J9547
 R29754
 Z-46
 Z0
 Z0
 X61.68
 Y192.99
 J9502
 R29732
 Z-45
 Z0
 Z0
ok 0
wait
wait
wait

X=-10mm:
delta values are really wrong and motor do same as for x=+10mm

Connecting...
start
Printer is now online.
Info:External Reset
X65.73
Y194.83
J10125
R30016
Free RAM:1182
X65.73
Y194.83
J10125
R30016
X:0.00 Y:0.00 Z:0.00 E:0.00
SD init fail
ok 0
T:0.00 B:0.00 B@:0 @:0
wait
extruder 0: temp sensor defect
heated bed: temp sensor defect
Errortongue sticking out smileyrinter set into dry run mode until restart!
wait
wait
wait
wait
ok 0
ok 0
X66.01
Y194.95
J10169
R30035
Z0
Z-19891
Z0
X66.29
Y195.07
J10212
R30053
Z0
Z0
Z0
X66.57
Y195.19
J10256
R30071
Z0
Z0
Z0
X66.85
Y195.30
J10299
R30088
Z0
Z0
Z0
X67.13
Y195.42
J10342
R30106
Z0
Z0
Z0
X67.41
Y195.53
J10385
R30123
Z0
Z0
Z0
X67.69
Y195.64
J10428
R30140
Z0
Z0
Z0
X67.96
Y195.75
J10470
R30157
Z0
Z0
Z0
X68.24
Y195.85
J10513
R30173
Z0
Z0
Z0
X68.52
Y195.96
J10555
R30190
Z0
Z0
Z0
X68.79
Y196.06
J10598
R30206
Z0
Z0
Z0
X69.07
Y196.17
J10640
R30221
Z0
Z0
Z0
X69.34
Y196.27
J10682
R30237
Z0
Z0
Z0
X69.61
Y196.37
J10724
R30252
Z0
Z0
Z0
ok 0
wait
wait
wait

maybe if I upload it to github you can give a look

EDIT: uploaded: [github.com]

Edited 2 time(s). Last edit at 01/27/2014 02:09AM by Gomez.Marcos.

Hello Repetier !
Well, I tried to insert some dummy moves inside the homing function, to be able to understand where problems begin. It happends funny things :
Here is the modified function :

#if DRIVE_SYSTEM==4  // Scott-Russel drive system homing
/**

    ^ Y axis
    |
    +------->|SR_XYHOMEDIST
    |        |
  <-*->    <-*->  ------------+-- Common Linear Guide parallel to X axis
    |\      /                 |   at a distance = SR_CARTESIAN_Y_HOME
    | \    /                  |
    |  \  /                   |
    |   \/                    |
    |   /                     | SR_CARTESIAN_Y_HOME
    |  /                      |
    | /                       |
    |/                        |
 ---*-------------------------+--> X Axis
    Origin

*/

void Printer::homeXAxis()
// In S-R systems, X and Y are homed together
{
    long steps;
    if ((MIN_HARDWARE_ENDSTOP_X && X_MIN_PIN > -1 && X_HOME_DIR==-1 && MIN_HARDWARE_ENDSTOP_Y && Y_MIN_PIN > -1 && Y_HOME_DIR==-1) ||
            (MAX_HARDWARE_ENDSTOP_X && X_MAX_PIN > -1 && X_HOME_DIR==1 && MAX_HARDWARE_ENDSTOP_Y && Y_MAX_PIN > -1 && Y_HOME_DIR==1))
    {
        long offX = 0,offY = 0;
#if NUM_EXTRUDER > 1
        for(uint8_t i=0; i < NUM_EXTRUDER; i++)
        {
#if X_HOME_DIR < 0
            offX = RMath::max(offX,extruder[ i ].xOffset);
            offY = RMath::max(offY,extruder[ i ].yOffset);
#else
            offX = RMath::min(offX,extruder[ i ].xOffset);
            offY = RMath::min(offY,extruder[ i ].yOffset);
#endif
        }
        // Reposition extruder that way, that all extruders can be selected at home pos.
#endif
        UI_STATUS_UPD(UI_TEXT_HOME_X);
        steps = (Printer::yMaxSteps-Printer::yMinSteps) * Y_HOME_DIR; //Since Y carriage travel is always greater than X travel in a S-R
        currentPositionSteps[X_AXIS] = steps;
        currentPositionSteps[Y_AXIS] = 0; // dummy : no Y movement while traveling, together with X, toward endstops
Com::printFLN(PSTR("Homing move begin  "),1); //
        PrintLine::moveRelativeDistanceInSteps(2*steps,0,0,0,homingFeedrate[X_AXIS],true,true); //
        // Both carriages are now at home position
        currentPositionSteps[X_AXIS] = (X_HOME_DIR == -1) ? xMinSteps-offX : xMaxSteps+offX;
        currentPositionSteps[Y_AXIS] = 0;
#if NUM_EXTRUDER > 1
        PrintLine::moveRelativeDistanceInSteps((Extruder::current->xOffset-offX) * X_HOME_DIR,(Extruder::current->yOffset-offY) * Y_HOME_DIR,0,0,homingFeedrate[X_AXIS],true,false);
#endif
        currentPositionSteps[Z_AXIS] = 1500; // Dummy setting for debugging
        Printer::updateCurrentPosition();
        transformCartesianStepsToDeltaSteps(currentPositionSteps, currentDeltaPositionSteps);
Com::printFLN(PSTR("After homing move  "),2); //
Com::printFLN(PSTR("Dummy move 1 begin  "),3); //
        PrintLine::moveRelativeDistanceInSteps(7500,15000,0,0,homingFeedrate[X_AXIS],false,false); //Dummy move for debugging
Com::printFLN(PSTR("Dummy move 2 begin  "),4); //
        PrintLine::moveRelativeDistanceInSteps(12200,6400,0,0,homingFeedrate[X_AXIS],false,false); //Dummy move for debugging
Com::printFLN(PSTR("Dummy move ended  "),5); //
    }
}

Then, the corresponding log from Repetier host, with DEBUG_QUEUE_MOVE, DEBUG_STEPCOUNT and DEBUG_SPLIT activated :

12:23:59.729 : Homing move begin  1
THE PRINTER GOES IMMEDIATLY TO THE HOME POSITION
12:23:59.729 : Seconds:2.23
12:23:59.733 : Segments:155
12:23:59.733 : Num lines:8
12:23:59.733 : segments_per_line:19
12:23:59.737 : Max Delta Steps:34291
12:23:59.737 : Steps Per Segment:34291
12:23:59.741 : Virtual axis steps:651529
12:23:59.741 : Max Delta Steps:446
12:23:59.745 : Steps Per Segment:446
12:23:59.745 : Virtual axis steps:8474
12:23:59.753 : Max Delta Steps:446
12:23:59.757 : Steps Per Segment:446
12:23:59.757 : Virtual axis steps:8474
12:23:59.765 : Max Delta Steps:446
12:23:59.770 : Steps Per Segment:446
12:23:59.770 : Virtual axis steps:8474
12:23:59.782 : Max Delta Steps:446
12:23:59.782 : Steps Per Segment:446
12:23:59.786 : Virtual axis steps:8474
12:23:59.794 : Max Delta Steps:446
12:23:59.794 : Steps Per Segment:446
12:23:59.798 : Virtual axis steps:8474
12:23:59.807 : Max Delta Steps:446
12:23:59.807 : Steps Per Segment:446
12:23:59.810 : Virtual axis steps:8474
12:23:59.818 : Max Delta Steps:446
12:23:59.822 : Steps Per Segment:446
12:23:59.822 : Virtual axis steps:8474
HERE, WE ARE WAITING FOR ABOUT 45 SECONDS, THE PRINTER BEING IN HOME POSITION !
12:24:44.781 : Missed steps:66898
12:24:44.785 : Step/seg remaining:0
12:24:44.785 : Num Delta Segments:0
12:24:44.789 : Half Step:4
12:24:45.125 : Missed steps:16856
12:24:45.125 : Step/seg remaining:0
12:24:45.129 : Num Delta Segments:0
12:24:45.129 : Half Step:4
12:24:45.436 : Missed steps:16854
12:24:45.436 : Step/seg remaining:0
12:24:45.440 : Num Delta Segments:0
12:24:45.440 : Half Step:4
12:24:45.715 : Missed steps:16888
12:24:45.715 : Step/seg remaining:0
12:24:45.719 : Num Delta Segments:0
12:24:45.719 : Half Step:4
12:24:45.993 : Missed steps:16886
12:24:45.997 : Step/seg remaining:0
12:24:45.997 : Num Delta Segments:0
12:24:45.997 : Half Step:4
12:24:46.271 : Missed steps:16888
12:24:46.276 : Step/seg remaining:0
12:24:46.276 : Num Delta Segments:0
12:24:46.279 : Half Step:4
12:24:46.587 : Missed steps:16886
12:24:46.587 : Step/seg remaining:0
12:24:46.591 : Num Delta Segments:0
12:24:46.591 : Half Step:4
12:24:46.927 : Missed steps:16856
12:24:46.931 : Step/seg remaining:0
12:24:46.931 : Num Delta Segments:0
12:24:46.931 : Half Step:4
12:24:46.935 : After homing move  2
HERE, THE HOME POSITION IS STILL OK
12:24:46.935 : Dummy move 1 begin  3
12:24:46.939 : Seconds:0.55
12:24:46.939 : Segments:38
12:24:46.939 : Num lines:2
12:24:46.943 : segments_per_line:19
12:24:46.943 : Max Delta Steps:1012
12:24:46.947 : Steps Per Segment:1012
12:24:46.947 : Virtual axis steps:19228
12:24:46.951 : Max Delta Steps:577
12:24:46.951 : Steps Per Segment:577
12:24:46.955 : Virtual axis steps:10963
12:24:46.955 : Dummy move 2 begin  4
12:24:46.955 : Seconds:0.45
12:24:46.959 : Segments:31
12:24:46.959 : Num lines:2
12:24:46.959 : segments_per_line:15
12:24:46.963 : Max Delta Steps:526
12:24:46.963 : Steps Per Segment:526
12:24:46.967 : Virtual axis steps:7890
12:24:46.967 : Max Delta Steps:500
12:24:46.972 : Steps Per Segment:500
12:24:46.972 : Virtual axis steps:7500
12:24:46.975 : Dummy move ended  5
BOTH MOVES SEEMS OK, THEN THE PRINTER GOES BACK TO HOME POSITION, WITH AN ERROR
12:24:46.975 : Seconds:1.21
12:24:46.975 : Segments:84
12:24:46.980 : Num lines:4
12:24:46.980 : segments_per_line:21
12:24:46.980 : Max Delta Steps:54275
12:24:46.984 : Steps Per Segment:54275
12:24:46.988 : Virtual axis steps:1139775
12:24:46.988 : Max Delta Steps:0
12:24:46.997 : Error:No move in delta segment with > 1 segment. This should never happen and may cause a problem!
12:26:11.286 : Missed steps:15815
12:26:11.290 : Step/seg remaining:0
12:26:11.290 : Num Delta Segments:0
12:26:11.290 : Half Step:4
THEN, I WAS UNABLE TO MOVE ANY MORE THE PRINTER FROM THE REPETIER HOST PANEL

Any idea ?

Edited 3 time(s). Last edit at 01/27/2014 07:20AM by M_Xeno.

there are problems with soft endstops are generalised for delta axes
I uploaded modifications done to github

it works...
I added min and max software endstops, distinct for every axis (only max was active for delta and three axis were treated with same conditions)

now the problem is that only receive 1 order and then it doesn't moves any more

@Gomez.Marcos

Not sure using system 3 is a clever idea. There are several parts with special delta conditions like pure z move which could collide with your system, also I Think the mentioned one works.

You should also have a look at the timings from your computations. Especially if using an avr I guess your formulas are way to slow for practical use. atan/cos/pow are even a magnitude slower then division and square root and you use a lot of them. But with your debug writings you should be able to see how long one transformation takes. For normal prints you probably want 170-250 transformations per second, depending on nonlinearity. So I guess over short you need to switch to a ARM based version like the due port.

Each drive system needs a matching homing sequence to determine the start position. That will most likely differ from the delta version.

@M_Xeno

you also seem to hang in the homing sequence. The long waiting period is most likely from the first long homing sequence. My idea was to first home local x/y axis until endstop is triggered. I remember that I even changed the endstop test for nonlinear printer systems, so it stopps, when the x and y min endstop is reached. Taking so long means the move continues, so end of line detection was not triggered correctly.

Also

steps = (Printer::yMaxSteps-Printer::yMinSteps) * Y_HOME_DIR; //Since Y carriage travel is always greater than X travel in a S-R

is not really correct. yMinSteps and yMAxSteps are in cartesian system. Take the one from x axis and add a save factor like 2* to be sure. Endstop should stop it anyway.

I think you should also debug the result of transformCartesianStepsToDeltaSteps to see if homing initaliced it correctly and if it computes expected positions.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!