Compilation error with Scott-Russel (tuga) drive system

Hello!
Trying to configure a Scott Russel (Tuga like) printer with the configuration tool for 0.91 Rev 3, I encounter the following problems :

1 - No way to set up the lenght of the diagonal rod (No nice drawing as for delta machines ;-) ). The #define DELTA_DIAGONAL_ROD lacks in the configuration.h file. Added manually.
2 - No way to set up the offset between X and Y carriages at homing. Seems albeit needed for further calculations (not sure)...
3 - Compilation error in motion.cpp, line 962 : 'stepsRemainingAtZHit' is not a member of 'Printer'

The configuration.h here included comes directly from the configuration tool. Just added DELTA_DIAGONAL_ROD setting, line 193.

Thanks you Repetier, for your impressive work !

The reason it is not included in config tool is simply that it is not working so far. I have no such printer to test so development on the code will be very slow unless someone with printer and programming skills takes a look at the code and finds the problem.

For your compilation problem.

Printer.h around Line 87:

#if FEATURE_Z_PROBE || MAX_HARDWARE_ENDSTOP_Z || NONLINEAR_SYSTEM
    static long stepsRemainingAtZHit;
#endif

And Printer.cpp 82:

#if FEATURE_Z_PROBE || MAX_HARDWARE_ENDSTOP_Z || NONLINEAR_SYSTEM
long Printer::stepsRemainingAtZHit;
#endif

Should fix it.

If you have some solutions whats wrong let me know and I update it.

---

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.
I have now completed the hardware of my Scott-Russel prototype, so I will try to pursue the completion of the firmware for this type of machine, with your help.

I neglected a bit my other machine Bipod, the hardware is OK, but I could not run the firmware yet.

I also made some French translations for the user interface, I will send that to you as soon as I have a machine in good operating order to control the relevance of my translation.

Hello Repetier !

The compilation problem is gone, but it's still not working. I did some changes in printer.cpp and motion.cpp, as in included files.

in Motion.cpp, the generic coordinate transformation from cartesian to Scott-Russel :

#if DRIVE_SYSTEM==4 // Scott-Russel XY mechanisms

/**
  Calculate Scott-Russel carriages position from a cartesian position
  @param cartesianPosSteps array containing cartesian coordinates in steps units.
  @param srPosSteps result array with SR carriage coordinates in steps units.
  @returns 1 if cartesian coordinates have a valid SR position counterpart, 0 if not.


    +------------->| srPosSteps[1]
    +---->| srPosSteps[0] ( same as cartesianPosSteps[0] )
    |              |
    |     X        Y
----+-  <-*->    <-*->  ----------------+-- Common Linear Guide = X axis
    |      \      /                     |
    |       \    /                      |
    |        \  /                       |
    |         \/                        |
    |         /                         | y2 = cartesianPosSteps[1]
    |        /                          |
    |       /                           |
    |      /                            |
    |     *-----------------------------+--
    |   Nozzle
    +---->| cartesianPosSteps[0]
    |
    V
    Y axis


*/
uint8_t transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long srPosSteps[])
{
    srPosSteps[0] = cartesianPosSteps[0]; //X as cartesianX
    srPosSteps[2] = cartesianPosSteps[2]; //Z as CartesianZ
    long y2 = cartesianPosSteps[1]; // was wrong : y2 = Printer::deltaBPosXSteps-cartesianPosSteps[1];

    if(Printer::isLargeMachine())
    {
        float y2f = (float)y2*(float)y2;
        float temp = Printer::deltaDiagonalStepsSquaredF - y2f;
        if(temp<0) return 0;
        srPosSteps[1] = srPosSteps[0] + sqrt(temp);
    }
    else
    {
        y2 = y2*y2;
        long temp = Printer::deltaDiagonalStepsSquared - y2;
        if(temp<0) return 0;
        srPosSteps[1] = srPosSteps[0] + HAL::integerSqrt(temp); //Y carriage follows X, with the calculated nonlinear offset
    }
    return 1;
}
#endif

As you can see, I set the common linear guide as the X cartesian axis (more exacty, the cartesian X axis is parallel to the guide, through the articulations of the mechanism). The cartesian Y axis origin is set at the X carriage articulation, while at XMin endstop position). This could be not coherent with the rest of the firmware. What do you think about these settings ?
Also, is Printer::deltaDiagonalStepsSquared correctly set and safe in the SR context ?

In printer.cpp, the homing function

#if DRIVE_SYSTEM==4  // Scott-Russel drive system homing
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.xOffset);
            offY = RMath::max(offY,extruder.yOffset);
#else
            offX = RMath::min(offX,extruder.xOffset);
            offY = RMath::min(offY,extruder.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::xMaxSteps-Printer::xMinSteps) * X_HOME_DIR;
        currentPositionSteps[X_AXIS] = steps;
        currentPositionSteps[Y_AXIS] = 0; // dummy : no Y movement while traveling, together with X, toward endstops

        //Is it really necessary to transform coordinates here, since we need a simple uniaxial X movement, for both carriages ?
        //Seems to induce strange side effects (wawing movements while traveling toward endstops)
        transformCartesianStepsToDeltaSteps(currentPositionSteps, currentDeltaPositionSteps);

        //The use of this high level function leads to many segments, queuing, etc, with possible side effects.
        //Will it something more direct and safe (but perhaps less concise), for this uniaxial move ?
        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; // dummy for now
        // Re-test the endstops to improve precision of homing
        PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[X_AXIS]*-ENDSTOP_X_BACK_MOVE * X_HOME_DIR,0,0,0,homingFeedrate[X_AXIS]/ENDSTOP_X_RETEST_REDUCTION_FACTOR,true,false);
        PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[X_AXIS]*2*ENDSTOP_X_BACK_MOVE * X_HOME_DIR,0,0,0,homingFeedrate[X_AXIS]/ENDSTOP_X_RETEST_REDUCTION_FACTOR,true,true);
#if defined(ENDSTOP_X_BACK_ON_HOME)
        if(ENDSTOP_X_BACK_ON_HOME > 0)
            PrintLine::moveRelativeDistanceInSteps(axisStepsPerMM[X_AXIS]*-ENDSTOP_X_BACK_ON_HOME * X_HOME_DIR,0,0,0,homingFeedrate[X_AXIS],true,false);
#endif
        // Now the home position can be set, for X and Y
        currentPositionSteps[X_AXIS] = (X_HOME_DIR == -1) ? xMinSteps-offX : xMaxSteps+offX;
        currentPositionSteps[Y_AXIS] = SR_CARTESIAN_Y_HOME * axisStepsPerMM[X_AXIS]; // To be verified by Repetier
        coordinateOffset[Y_AXIS] = 0;
        transformCartesianStepsToDeltaSteps(currentPositionSteps, currentDeltaPositionSteps); // Z is not set yet
#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
}
#else

The SR_CARTESIAN_Y_HOME parameter has to be set in configuration.h. This is the Y extension of the Scott-Russel mechanism along the cartesian Y axis, both carriages being at home position.

Last question : There are many DEBUG options in Repetier.h. Which debug method do you recommand, to simply peek at variables (Serial.print() does not work) ?

Thanks a lot, Repetier !

Edited 3 time(s). Last edit at 01/17/2014 09:29AM by M_Xeno.

Trying to trace the behaviour of Printer::moveRelativeDistanceInSteps, I found that the queueDeltaMove( , , ) function was not defined for the DRIVE_SYSTEM = 4 settings. (Line 106 in motion.cpp).
Code::blocks does not found any implementation of this function. However, this seems t be implemented if DRIVE_SYSTEM = 3.

/**
Move printer the given number of steps. Puts the move into the queue. Used by e.g. homing commands.
*/
void PrintLine::moveRelativeDistanceInSteps(long x,long y,long z,long e,float feedrate,bool waitEnd,bool checkEndstop)
{
    //Com::printF(Com::tJerkColon,x);
    //Com::printF(Com::tComma,y);
    //Com::printFLN(Com::tComma,z);
    float savedFeedrate = Printer::feedrate;
    Printer::destinationSteps[X_AXIS] = Printer::currentPositionSteps[X_AXIS] + x;
    Printer::destinationSteps[Y_AXIS] = Printer::currentPositionSteps[Y_AXIS] + y;
    Printer::destinationSteps[Z_AXIS] = Printer::currentPositionSteps[Z_AXIS] + z;
    Printer::destinationSteps[E_AXIS] = Printer::currentPositionSteps[E_AXIS] + e;
    Printer::feedrate = feedrate;
#if NONLINEAR_SYSTEM
    queueDeltaMove(checkEndstop,false,false);
#else
    queueCartesianMove(checkEndstop,false);
#endif
    Printer::feedrate = savedFeedrate;
    Printer::updateCurrentPosition();
    if(waitEnd)
        Commands::waitUntilEndOfAllMoves();
}

What to think about that ?

First I have to say your Scott-Russel is not identical with the Tuga system, so you can not make your changes in driver system 4.
The tuga has 2 independently driven axis x /y so it can even be at the same position making the Y a I, which is also the intended homing procedure. Bring them to the same left side, so they are exactly straigt. So I guess you need to add a 6 for your system.

Please check repetier.h line 128 where nonlinear systems get defined. Should then look like this:

#if DRIVE_SYSTEM==3 || DRIVE_SYSTEM==4 || DRIVE_SYSTEM==5 || DRIVE_SYSTEM==6
#define NONLINEAR_SYSTEM true
#else
#define NONLINEAR_SYSTEM false
#endif

Line 106 in motion.cpp is already so in my current version (master). Not sure what you wanted to say or was it missing in some older dev version?

Debug messages are simple
Com::printFLN/(PSTR("MyMsg:"),value);
with value = int, long or float for bytes use (int)value.

Here also some helper file I use when doing delta considerations. It shows how and where coordinate systems get transformed. Perhaps it helps you understand some things.


There are 4 coordinate systems:

Printer::currentPosition - Extruder position in float real word coordinates
relative to printer origin. Printer::coordinateOffset is never included and only
added when M114 is shown or subtracted when coordinates are send.

On this coordinates we always add PrinterffsetX and PrinterffsetY during operations.

When bed leveling is active, these 3d coordinates get transformed to bed coordinate system.

Multiplying with steps per mm yields the
destinationSteps coordinates in R3

For nonlinear motions a last transformation maps moves an axis:
transform cartesian step position to nonlinear coordinate string.

coordinateOffset get subtracted from coordinates given to get the printer x,y,z
coordinates.
Example: At Position 15 a G92 X40 is given. coordinateOffsetX = 25
G1 X40 give 40-25 = 15 as real coordinate.


Helper function:

void Printer::updateCurrentPosition()

Sets Printer::currentPosition based on Printer::currentPositionSteps
considering offsetX/Y and coordinateOffset

static inline void Printer::realPosition(float &xp,float &yp,float &zp)
fills xp,yp,zp with Printer::currentPosition

void Printer::moveTo(float x,float y,float z,float e,float f)
Moves printer to x,y,z coordinates neglecting active bed transformations
and coordinate shift (G92)

void Printer::moveToReal(float x,float y,float z,float e,float f)
Moves printer to real coordinates including all transformations

uint8_t transformCartesianStepsToDeltaSteps(long cartesianPosSteps[], long deltaPosSteps[])
transform cartesian step position to nonlinear coordinate string.

---

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!

What reactivity ! Thank you !
I understood the architecture of Tuga printer, with two parallel guides, and the fact that two carriages could therefore have the same X coordinate.

However, I wonder if you really deduce that this is a different system. The offset of the two carriages in the X direction can be reduced to 0 for Tuga , OK, but this can be seen as a special case of the general case : there is a gap between carriages for the homing position , which may be any including 0 .

Moreover, in our imperfect real world, it must be mechanically very difficult to measure and ensure perfect alignment of the two carriages , since they are on remote and parallel guides, and I think that, even for Tuga machine, it would be better to have a way of adjusting by software, the shift observed .

There is another argument : it is probably best to never mechanically align the two carriages , as this would correspond to a geometric singularity , where rigidity is no longer guaranteed , and some parameters are indeterminate .

Here are the parameters I included in the " configuration.h " file to define the geometry of the mechanism after homing:

#define DELTA_DIAGONAL_ROD 236     // SR Setting, added manually
#define SR_XYHOMEDIST       92     // SR offset between X and Y carriages at homing
#define SR_CARTESIAN_Y_HOME sqrt( (DELTA_DIAGONAL_ROD * DELTA_DIAGONAL_ROD) - (SR_XYHOMEDIST * SR_XYHOMEDIST) ) //217.32924

We can see that, if SR_XYHOMEDIST = 0, then SR_CARTESIAN_Y_HOME = DELTA_DIAGONAL_ROD, OK for the Tuga.

I hope we can cope with DRIVE_SYSTEM = 4. I am very afraid of having to duplicate so many tests of the DRIVE_SYSTEM parameters found in Repetier firmware! I did it for Bipod, and it was a nightmare for me...

The reason I think these are different is that you said the x motor moves x position and the y motor changes distance of the Y. The tuga has one motor for each log the the Y so a pure x move moves x and y motor the same amount. At least that is how I understood it. If I got you wrong and the only difference is that you can not align the Y legs we can leave it at 4 and define the distance at homing position. At least if you also use 2 endstops - one for each leg.

---

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, each carriage has his own motor and move independently. The only difference with Tuga is the single common linear guide, and therefore the inability to align the Y legs.
One endstop for each carriage, and the two endstops have to be on the same side, of course (both MIN or both MAX). For now, I consider, for my machine, only two endstops on the MIN side, but, from a generic software point of view, the MAX side could be used as well : In this case, at homing, the mechanism is folded, more or less flat, along the linear guide, on the MAX side.

I continue this way. Thanks for your help !

Ok, then continue with type 4 and add a variable for the distance of the 2 carriages after homing. That should then work for both versions.

---

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,

I have a problem with Tuga kinematics :

This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.
Arduino: 1.0.6 (Windows 7), Board: "Arduino Mega 2560 or Mega ADK"
motion.cpp: In function 'uint8_t transformCartesianStepsToDeltaSteps(long int*, long int*)':
motion.cpp:973: error: 'deltaDiagonalStepsSquaredF' is not a member of 'Printer'
motion.cpp:980: error: 'deltaDiagonalStepsSquared' is not a member of 'Printer'

Firmware 0.91 rev. 8, generated 07.06.2015

Please help me

Best regards
Slawek

Edited 1 time(s). Last edit at 06/07/2015 01:56PM by Slawek.

That tuga implementation was never 100% finished. I did not have one and without having access we did not manage to solve all issues. If someone starts correcting it, please do so in work092 tree so we can include the corrections.

---

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!