Modify repetier firmware for SCARA

wangsamax

Dear repetier,

First of all i want to thanks for the great job on repetier firmware and host. I love it much more than marlin.

I'm using repetier firmware for my delta printer, and now i'm trying build my own design scara arm 3d printer. So i'm trying to modify repetier firmware.

Hopefully it's okay and i get some guidance.

What i've done is add new drive system called scara. Then i add some new functions for converting. First function is scara inverse kinematics, this is to convert cartesian coordinate to scara. Second function is scara forward kinematics, this is to convert scara coordinate to cartesian. Third function is dummy convert cartesian to delta. This is because i include scara drive to non linear, and i see there are some functions use the function.

The main idea is cartesian use x & y axis linearly, i use x & y axis circulary. While z axis is the same as cartesian. So cartesian step per unit is step per mm, scara step per unit is step per degree.

The main different converting cartesian to scara compare to convert to delta is which one to convert first.
i see that repetier firmware convert mm to steps then convert to delta towers in steps. While scara have to convert coordinate in mm to coordinate in degree first then convert in steps.

That's why i try to convert all the command in cartesian to scara in units then convert to steps.

My questions are

What functions that i have to modify. I add conversion scara-cartesian in motion.cpp, I found ispositionallowed(), updatederivedparameter(), moveto(), movetoreal(), setdestinationstepsfromgcode() in printer.cpp that i've modify, do i miss something?.
I'm confused with moveto() and moveto() function. A. I read the code and the comments but i dont really understand what is the different. Can you please explain what is the meaning of untransformed move, transformed cartesian coordinate, absolute cartesian space, mapping real(model) space to printer space.? B. In moveto() function. If i'm not mistaken, It's written if value is not ignored, then destinationsteps = (value + offset) * steppermm. What happen if it's ignored, what is the value of destinationsteps? I mean if moveto(5, ignore, ignore, ignore) I believe the x value is 5, what is the value of y? Because when convert cartesian to scara it need both x & y coordinate to get how much steps x & y motors should go.
Questions about homing. A. My scara have 2 parameters, armlength & forearmlength. X motor to move arm, y motor to move forearm. The ideal home coordinate is x motor at 0 degree and y motor at 180 degree. But it is not the fact. Let say x motor at 5, y motor at 175. What is this suppose to call? X offset & y offset or must be something else?

B. I set my print bed at the left side of the center axis (x motor). Because of x & y motor home coordinate is not ideal, it's forming a distance. I call it scara minimum radius, the maximum radius is armlength + forearmlength. In between min & max radius is my print bed area. Let say min radius is 50mm, max radius is 250mm and i want to put my print bed at leftside. So my printbed center is at (-150,0) cartesian position from x motor axis. Which one suppose to be the (0,0)? The x motor axis, nozzle position when touch endstop, center of printbed, or somewhere else? I am thinking it suppose to be the x motor axis, but i'm thinking how to use repetier host & cura about the printer shape.

That's all for now, hopefully it's too many questions & i hope you can kindly guide me.

Best regards Kusuma

Repetier

Sounds great. Hope you work against dev tree and make a pull request once you are done!

Implementing new systems should be quite simple in repetier. First select new drive system as you did and check it is recogniced as NONLINEAR_SYSTEM, which is what you need. You need only to program homing and your own version for

uint8_t transformCartesianStepsToDeltaSteps(int32_t cartesianPosSteps[], int32_t corePosSteps[])and you are done. First you should understand how to handle steps right. User enters real coordinates (currentPosition). If you check for example moveTo Real the main logic is then transformToPrinter(x + Printer::offsetX, y + Printer::offsetY, z + Printer::offsetZ, x, y, z); // There was conflicting use of IGNOR_COORDINATE destinationSteps[X_AXIS] = static_cast<int32_t>(floor(x axisStepsPerMM[X_AXIS] + 0.5f)); destinationSteps[Y_AXIS] = static_cast<int32_t>(floor(y axisStepsPerMM[Y_AXIS] + 0.5f)); destinationSteps[Z_AXIS] = static_cast<int32_t>(floor(z * axisStepsPerMM[Z_AXIS] + 0.5f));You see it gets transformed (meaning rotation of bed) and then converted to steps. So currentPositionSteps and destinationSteps are in cartesian printer format with steps per mm resolution. Your problem is X and Y which has nothing to do with rotation. So select for x and y a virtual resolution. So say you take 1000 for both. Using axisStepsPerMM you can convert this back into floats if needed or you keep computing with integers if that is faster. Next you implement

uint8_t transformCartesianStepsToDeltaSteps(int32_t cartesianPosSteps[], int32_t deltaPosSteps[])input is cartesianPosSteps = destination coordinates in steps as describedoutput deltaPosSteps = real motor position, so z stays the same and x and y are A/B rotations. You need to introduce a new parameter for your real motor resolution to do the conversion.Last you need to write your own homing routine (see printer.cpp how we already have 3 implementations for different drive systems). There are lots of delta parameter in eeprom you can misuse for your system, e.g. setDeltaTowerXOffsetSteps for homing offsets. Please update eeprom input/output so it shows user correct names for scara then.You might need to make some assumptions how bed coordinate is orientated relative to arm. If we assume arm is to right a natural coordinate system would have xmin/ymin on the left front. Or you take bed center as origin, both would work.Below some doc I wrote for orientation. I hope this covers your first questions. Ask again if you need more help.

-------------

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 Printer::offsetX and Printer::offsetY during operations.

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

Multiplying with steps per mm yields the

destionationSteps coordinates in R3

For nonlinear motions a last transformation maps moves an axis:

transform caresian 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

void PrintLine::moveRelativeDistanceInSteps(long x,long y,long z,long e,float feedrate,bool waitEnd,bool checkEndstop)

- No range check

- no coordinate transformation

- distance in steps

- updates currentPosition, but not lastCmdPos !

void PrintLine::moveRelativeDistanceInStepsReal(long x,long y,long z,long e,float feedrate,bool waitEnd)

- Range check

- coordinate transformation

- distance in steps

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

transform caresian step position to nonlinear coordinate strin

wangsamax

Hi repetier, thx for your kind reply.

I still confuse about coordinate transformation.

I checked this function transformToPrinter(x + Printer::offsetX, y + Printer::offsetY, z + Printer::offsetZ, x, y, z);

and confuse about what it does. is it simply the same as

x = x+offsetX;

y = y+offsetY;

z = z+offsetZ: ???

for coordinate system... this is the map that I think fit to my case

------------------------- E

| |

| | \O2

| | /

| | =O1/ >y

| |

<div style="color: rgb(0, 0, 0); font-size: 13.3333px;"> -------------------------

</div>

in the map, the square is the print bed, O1 is arm shoulder (X motor position), O2 is arm elbow (Y motor position), E is extruder position,

/ is arm length, \ is forearm length, ^x is x positive, >y is y positive, = is minimum distance allowed between shoulder and bed.

I want O1 to be the (0,0) position.

1. let say if I want extruder move to (-10,10) at this coordinate system. which function should I use? moveTo(-10,10,ignore) or moveToReal (-10,10,ignore). what is the difference result if I use moveTo and moveToReal in this case?

2. the bed is at the left side of (0,0), I set the farest bed side from (0,0) is (-50,0), the nearest side of bed is (-10,0), so the center of bed is (-30,0). Do I need OffsetX, OffsetY in this coordinate system?

3. I want shoulder(X motor) as the center of coordinate as map, not the bed center, because inverse kinematics equation that I use base on this mapping. if user give (X,Y) cartesian coordinate, I have to transform it to scara coordinate with this equation.

B = acos ((X²+Y²-L²-M²)/(2LM))

A = atan (Y/X) - atan (MsinB/(L+McosB)

A is X motor scara coordinate in rad, B is Y motor scara coordinate.

as you can see the equation need both X and Y cartesian coordinate to get successful transformation.

I see in moveToReal, for example...

if(x == IGNORE_COORDINATE)

x = currentPosition[X_AXIS];

I understand that if user command moveToReal(Ignore, -20, ignore, ignore), than the x value will be currenPosition[X_Axis]

so if I transform the given coordinate, it would be ( currentPosition[X_Axis] , -20)

but I don't understand moveTo function, it doesn't say anything about if ignored.

I mean if user command moveTo(ignore, -20, ignore, ignore), what is the value of x if the coordinate have to be transformed to scara with the equation above?

btw, I make changes log for the modification that I made. because I am not really a programmer, can you please help me to check my work. I don't know am I doing the right thing.

Kusuma

Repetier

transformToPrinter switches from ideal coordinates to coordinates corrected by rotation.

moveTo does not use the transformation while movetoReal includes transformations, so what users use at the end is moveToReal while for homing you will use moveTo as you want to ignore transformations there.

Making O1 origin is a bad idea. Then 0,0 would be outside bed and all Y coordinates are negative. That is very counter intuitive. You axis are wrong. We use a right handed coordinate system. The way you have drawn it all objects will be mirrored. Switch x and y and it looks good. Make x = 0 = left side. y = 0 could be middle to give you some advantage on transformation. Modifying coordinate system for your computations is a simple addition, so don't center too much on what's best for your formula, think more from usage point.

Don't think too much about coordinate systems. You only transform in transformCartesianStepsToDeltaSteps and there you get positions in steps as entered for x/y. All transformations are already done so you only do your simple math. So add offset to xy and compute A/B.

I hope you are using the due as your math is very slow. Don't use power 2 - use x*x which is much faster. asin/acos/atan are among the most expensive math computations. If you can replace equations with sqrt instead do it.

wangsamax

Tx for your explanations and advices. I will avoid using pow ect. But scara arm units conversion to steps options are only degree and rad. To convert angle to linear as far as i know only use sin cos tan asin acos atan functions. I have no idea how to replace those functions.

From your explanation, i think i can't use moveto() function. Even if i have to use them, the x and y in moveto() must not treated for cartesian coordinate. I mean i have to use them for scara coordinate directly. so for instance moveto(5, ignore) means x motor rotate 5 unit, y motor doesnt move. Is this right?

Sorry... you are right for the map. I mean ^y, >x. And all x coordinates are negative. And you are right that it will be not intuitive.

For the bed, actually the maximum usage is not square nor cicle. It's half circle, but it seems there is no such bed shape provided in repetier host, so the option is only square or circle. Which one you suggest will be better? Square or circle?

Please correct me, if the origin is bed center. Bed center is (0,0) and O1 let say (30,0). If i insist O1 is (0,0) then bed center is (-30,0) and this is not intuitive for user. To make bed is origin, simply use offset... x offset? I confuse x offset should be 30 or -30 in this case ???

Repetier

moveTo is always cartesian. You should not think about that too much. Your job is to make the right transformations. Most problematic will be homing where you want to set target motor position directly in your polar coordinates I guess. I think you need a new inject method for this - in your case a simplified "queueNonlinearMove" function that has no transformation.

DOn't think about the offsets we already have. These are for G92 and do change the coordinate system the user uses but not the resulting coordinates. Just add a variable for this on your own taken from delta variables, e.g. diagonal correction variables for x offset, Arm a/b length. Then you can correct in eeprom.

Bed shape is what you put on your printer not what you can reach. So I'd take a square bed and position it such that you can reach all positions. Scara has a big working radius and I know it is more a circle around arm. So if you want extreme take a circular bed and don't use the center:-)

Origin of coordinate system is also rotation point. This is important if you start autoleveling bed. It's always nice to have a point that does not change height due to rotation. Math will cover different origin, but it could result that all bed position have negative/positive correction which does not feel so good. SO many things are more like how would users expect things and not what is the mathematical simplest solution.

wangsamax

I do worry about moveto(), because i see it used many times (i haven't check them all) and it might causing problems. I dont know what will happen to atan(y/x) if y or x is ignored

So... you are suggesting to use O1 to be origin(0,0), but to make comfortable for users, make a dummy origin that intuitive, then all dummy coordinate transformed/corrected relative to O1? Isn't it the same as offset? Why not just use x offset then in user languages call it correction?

For homing i'm not worry too much it's less difficult then delta, and not so much different with cartesian. I don't need to do anything for z. Just transform xy linear to scara. The only problem that don't know what to do is i want it home z first, then y, then x.

Autobed leveling is important to me. That is one of the thing i love about repetier firmware. I design this scara bot for open bed, which means users can modify bed according to their applications. They may directly print on a floor, a glass, a plate, a wood, a metal or anything. I don't give any boundary to limit the bed, it even possible to print if you put the machine on a table then print on floor. And it even possible to modify to print to wall. So autoleveling is a must everytime user changing bed.

Autolevel is something that i worry too. Is it use moveto function? If you say moveto must be cartesian, then i can't use it. I guess i must make changes to all commands that use moveto().

Btw, this is just an information that i hope useful for you. I use repetier firmware for my delta printer. I learned about delta for months to get a proper way to calibrate. I search anywhere to get it but havent found any calibration procedure that satisfy me. So i make my own calibrating steps and succesfully get accurate result. Including how to find accurate diagonal & radius for each tower.

For calibrating delta accurately, calculating steps from a point at any towers to it's endstop is crusial. We can't get accurate diagonal & radius without this.

I know there is a command in repetier firmware gcode to do this, i was use it and found that it is not correct for some points (especially if we move extruder near z tower, we'll get strange behaviour). Try to check distance in steps for coordinate (0,90), (0,85), (10, 80), (-10,80). It happens to my printers that one of the value doesnt change for all that points.

I found it because transformcartesiantodelta() and step limits in the calculation. So i make another gcode, another function and another integers without transformation and limits to fix it and get accurate result. I hope you add a gcode to calculate steps to endstop without transformcartesiantodelta and limits in the next version.

wangsamax

Hi, repetier.

I modified distortion:: in printer.cpp It map distortion in steps, I add elif drive_system == scara that map distortions in mm, but when store to eeprom i transform it to scara coordinate. When call from eeprom, i transform it again to cartesian in mm.

I haven't change anything in bedleveling.cpp, but I've checked and found moveto() used many times.

What if i add elif drive_system scara in moveto(... if x ignored, x =lastcmdpos x axis ? Is this solving my problem or it will causing other problems?

Repetier

You are not supposed to change moveTo!!! It is a helper function and takes coordinates in cartesian coordinates and all callers expect it to be using cartesian coordinates. It is cartesian without applying bed leveling correction.

Same with distortion map. These corrections are applied in cartesian coordinate system and need no special case. I didn't need it for delta so you never need it. In delta we also have cartesian and delta coordinates and the only place we transform is transformcartesiantodelta. It is really that simple.

Regarding x offset. The one I mean is the one set by G92 and homing resets this to machine origin which is the only origin that counts. And we want this on bed so we can not use it.

wangsamax

Hi repetier, tx for your explanation.

I think I did it all wrong for cartesian transformation.

I was use steps per mm to be treated as steps per degree, so I modify all functions that convert position to steps.

please correct me if this one is wrong...

what I suppose to do is make a dummy stepsPerMM for x & y axis. let say define it 1000.

create new variables let say stepsPerRad[] for x & y.

in transformCartesianToDelta, I multiply armLength and forearmLength with 1000 so it will equal with cartesian steps.

then convert it to scara coordinate with stepsPerRad[].?

Repetier

No new variables needed. transformCartesianToDelta gets cartesian steps per mm and the result array needs steps from home position of motor. So x/y are your rads multiplied with steps per rad.

float x = in[X_AXIS]axisStepsPerMM[X_AXIS] + X_OFFSET;

float y = in[Y_AXIS]*axisStepsPerMM[Y_AYIS]

out[Z_AXIS] = in[Z_AXIS]

out[X_AXIS] = your transform result for x motor steps

out[Y_AXIS] = your transform result for y motor steps

no guarantee for variables, just what your transform would look like.

wangsamax

Is this correct?

<div>#if DRIVE_SYSTEM == SCARA

uint8_t transformCartesianStepsToDeltaSteps(int32_t cartesianPosSteps[], int32_t scaraPosSteps[])

{

int32_t tempX = cartesianPosSteps[X_AXIS] + Printer::BedOriginPos[X_AXIS] * axisStepsPerMM[X_AXIS];

int32_t tempY = cartesianPosSteps[Y_AXIS];

int32_t temp1 = tempX * tempX + tempY * tempY;

int32_t tempL = EEPROM::armLength() * 1000; // Arm Length

int32_t tempM = EEPROM::forearmLength() * 1000; // Forearm Length

temp1 = tempX * tempX + tempY * tempY - tempL * tempL - tempM * tempM ; // X² + Y² - L² - M²

int32_t temp2 = 2 * tempL * tempM ; // 2 * L * M

float tempB = acos( temp1 / temp2 ); // Elbow angle position

if (tempB <0) tempB = tempB + 3.1415926535; // Make Elbow angle always positive

if (tempX == 0) tempX = 0.000000001;

temp1 = atan ( tempY / tempX ); // atan (Y/X)

if (temp1<0) temp1 = temp1 + 3.1415926535; // Make the angle always positive

float temp3 = tempL + tempM * cos( tempB);

if (temp3 == 0) temp3 = 0.000000001;

temp2 = atan ( tempM * sin( tempB ) / temp3); // atan (M * sin (Elbow) / (L + M cos (Elbow)))

if (temp2<0) temp2 = temp2 + 3.1415926535; // Make the angle always positive

scaraPosSteps[X_AXIS] = (temp1 - temp2) * Printer::motorStepsPerRad[X_Axis]; // Shoulder angle position

scaraPosSteps[Y_AXIS] = tempB * Printer::motorStepsPerRad[Y_Axis];

scaraPosSteps[Z_AXIS] = cartesianPosSteps[Z_AXIS];

return 1;

}

#endif

</div>

wangsamax

#elif DRIVE_SYSTEM == SCARA

void Printer::ScaraMoveToEndstop()

{

for (fast8_t i = 0; i < 3; i++)

Printer::currentPositionSteps[i] = 0;

Printer::stepsRemainingAtXHit = -1;

Printer::stepsRemainingAtYHit = -1;

Printer::stepsRemainingAtZHit = -1;

setHoming(true);

PrintLine::moveRelativeDistanceInSteps(0, 0, scaraHomePosSteps[Z_AXIS] * 2, 0, Printer::homingFeedrate[Z_AXIS], true, true);

if (Endstops::zMax())

PrintLine::moveRelativeDistanceInSteps(0, Printer::yMotorMaxAngleSteps * 2, 0, 0, Printer::homingFeedrate[Y_AXIS], true, true);

if (Endstops::yMax())

PrintLine::moveRelativeDistanceInSteps(- Printer::xMotorMaxAngleSteps * 2, 0, 0, 0, Printer::homingFeedrate[X_AXIS], true, true);

if (Endstops::xMin())

offsetX = offsetY = offsetZ = 0;

setHoming(false);

}

void Printer::homeXAxis()

{

MoveToReal(0,IGNORE_COORDINATE,IGNORE_COORDINATE,IGNORE_COORDINATE,IGNORE_COORDINATE,homingFeedrate[X_AXIS]);

}

void Printer::homeYAxis()

{

MoveToReal(IGNORE_COORDINATE,0,IGNORE_COORDINATE,IGNORE_COORDINATE,IGNORE_COORDINATE,homingFeedrate[Y_AXIS]);

}

void Printer::homeZAxis()

{

long steps;

coordinateOffset[Z_AXIS] = 0;

steps = (zMaxSteps - zMinSteps) * Z_HOME_DIR;

currentPositionSteps[Z_AXIS] = -steps;

setHoming(true);

PrintLine::moveRelativeDistanceInSteps(0, 0, 2 * steps,0,homingFeedrate[Z_AXIS],true,true);

currentPositionSteps[Z_AXIS] = zMaxSteps;

PrintLine::moveRelativeDistanceInSteps(0, 0, axisStepsPerMM[Z_AXIS] * -ENDSTOP_Z_BACK_MOVE * Z_HOME_DIR, 0, homingFeedrate[Z_AXIS] / ENDSTOP_Z_RETEST_REDUCTION_FACTOR,true,false);

#if defined(ZHOME_WAIT_UNSWING) && ZHOME_WAIT_UNSWING > 0

HAL::delayMilliseconds(ZHOME_WAIT_UNSWING);

#endif

PrintLine::moveRelativeDistanceInSteps(0,0,axisStepsPerMM[Z_AXIS] * 2 * ENDSTOP_Z_BACK_MOVE * Z_HOME_DIR, 0, homingFeedrate[Z_AXIS] / ENDSTOP_Z_RETEST_REDUCTION_FACTOR,true,true);

setHoming(false);

int32_t zCorrection = 0;

#if defined(ENDSTOP_Z_BACK_ON_HOME)

// If we want to go up a bit more for some reason

if(ENDSTOP_Z_BACK_ON_HOME > 0)

zCorrection -= axisStepsPerMM[Z_AXIS] * ENDSTOP_Z_BACK_ON_HOME * Z_HOME_DIR;

#endif

currentPositionSteps[Z_AXIS] -= zBedOffset * axisStepsPerMM[Z_AXIS]; // Correct bed coating

PrintLine::moveRelativeDistanceInSteps(0,0,zCorrection,0,homingFeedrate[Z_AXIS],true,false);

currentPositionSteps[Z_AXIS] = zMaxSteps - Printer::zBedOffset * axisStepsPerMM[Z_AXIS];

#if NUM_EXTRUDER > 0

currentPositionSteps[Z_AXIS] -= Extruder::current->zOffset;

#endif

updateCurrentPosition(true);

setZHomed(true);

}

}

void Printer::homeAxis(bool xaxis,bool yaxis,bool zaxis)

{

bool nocheck = isNoDestinationCheck();

setNoDestinationCheck(true);

#if defined(SUPPORT_LASER) && SUPPORT_LASER

bool oldLaser = LaserDriver::laserOn;

LaserDriver::laserOn = false;

#endif

bool autoLevel = isAutolevelActive();

setAutolevelActive(false);

if (!(X_MIN_PIN > -1 && Y_MAX_PIN > -1 && Z_MAX_PIN > -1

&& MIN_HARDWARE_ENDSTOP_X && MAX_HARDWARE_ENDSTOP_Y && MAX_HARDWARE_ENDSTOP_Z))

{

Com::printErrorFLN(PSTR("Hardware setup inconsistent. Scara cannot home without proper endstops."));

}

<div>#if (xaxis = yaxis = zaxis = true)

ScaraMoveToEndstop()

currentNonlinearPositionSteps[X_AXIS] = xMotorMinAngleSteps;

currentNonlinearPositionSteps[Y_AXIS] = yMotorMaxAngleSteps;

currentNonlinearPositionSteps[Z_AXIS] = zLength;

transformScaraStepsToCartesianSteps(currentNonlinearPositionSteps[],currentPositionSteps[]);

homeXAxis();

homeYAxis();

homeZAxis();

#else

if(zaxis) homeZAxis();

if(yaxis) homeYAxis();

if(xaxis) homeXAxis();

#endif

</div>

updateCurrentPosition(true);

updateHomedAll();

UI_CLEAR_STATUS

Commands::printCurrentPosition(PSTR("homeAxis "));

setAutolevelActive(autoLevel);

#if defined(SUPPORT_LASER) && SUPPORT_LASER

LaserDriver::laserOn = oldLaser;

#endif

Printer::updateCurrentPosition();

setNoDestinationCheck(nocheck);

}

Repetier

I'm quite sure it will not work.

In your transformation you are using int32_t so max. value is +/-2147483648 so squaring some steps > 46340 will overflow the value and you have garbage.

Your homing neglects the fact that moveRelativeDistanceInSteps moves in cartesian not in scara coordinates. As I already said you need a special own function to move directly in scara coordinates. Don't implement home x/y as they are not possible. You can do homeZ since z is independent and homeScara if x and y is set, so pure G28 would home all.

#if (xaxis = yaxis = zaxis = true)

is a pain for programmer. #if is preprocessor compare so only works on const and it is always true if you omit # because you assign all axis true value and do not compare as you think. I guess you meant

if(xaxis && yaxis && zaxis)

wangsamax

Hi again,

if I change int32_t to long or int64_t, will it solve the problem?

btw, I don't know what is the different between long and int64_t.

I'll take your advice to make new function to move directly to scara coordinate,

but I don't understand about home x/y are not possible.

I think I have to really understand which one is home.

In the transformation I use center of print area as (0,0), my arm axis is outside the print area.

which one is home? the center of print area of when all axis touch endstop ?

I'm still considering about g28, where should the position of extruder be after g28... at the center of print area or at endstop?

thanks for your advice and patient.

wangsamax

Hi repetier would you please check if this is right or not?

void PrintLine::queueScaraMove(uint8_t check_endstops, uint8_t pathOptimize)

{

EVENT_CONTRAIN_DESTINATION_COORDINATES

Printer::unsetAllSteppersDisabled();

waitForXFreeLines(1);

float axisRotationRad[E_AXIS_ARRAY]; // Axis rotation in Rad

p->flags = (check_endstops ? FLAG_CHECK_ENDSTOPS : 0);

#if MIXING_EXTRUDER

if(Printer::isAllEMotors()) {

p->flags |= FLAG_ALL_E_MOTORS;

}

#endif

p->joinFlags = 0;

if(!pathOptimize) p->setEndSpeedFixed(true);

p->dir = 0;

//Find direction

Printer::zCorrectionStepsIncluded = 0;

for(uint8_t axis = 0; axis < 4; axis++)

{

p->delta[axis] = Printer::NonlinearDestinationSteps[axis] - Printer::currentNonlinearPositionSteps[axis];

p->secondSpeed = Printer::fanSpeed;

if(axis == E_AXIS)

{

if(Printer::mode == PRINTER_MODE_FFF)

{

Printer::extrudeMultiplyError += (static_cast<float>(p->delta[E_AXIS]) * Printer::extrusionFactor);

p->delta[E_AXIS] = static_cast<int32_t>(Printer::extrudeMultiplyError);

Printer::extrudeMultiplyError -= p->delta[E_AXIS];

Printer::filamentPrinted += p->delta[E_AXIS] * Printer::invAxisStepsPerMM[axis];

}

#if defined(SUPPORT_LASER) && SUPPORT_LASER

else if(Printer::mode == PRINTER_MODE_LASER)

{

p->secondSpeed = ((p->delta[X_AXIS] != 0 p->delta[Y_AXIS] != 0) && (LaserDriver::laserOn p->delta[E_AXIS] != 0) ? LaserDriver::intensity : 0);

p->delta[E_AXIS] = 0;

}

#endif

}

if(p->delta[axis] >= 0)

p->setPositiveDirectionForAxis(axis);

else

p->delta[axis] = -p->delta[axis];

if(axis == X_AXIS axis == Y_AXIS)

axisRotationRad[axis] = p->delta[axis] / Printer::motorStepsPerRad[axis]

else

axisRotationRad[axis] = p->delta[axis] * Printer::invAxisStepsPerMM[axis];

if(p->delta[axis]) p->setMoveOfAxis(axis);

Printer::currentNonlinearPositionSteps[axis] = Printer::NonlinearDestinationSteps[axis];

}

if(p->isNoMove())

{

if(newPath) // need to delete dummy elements, otherwise commands can get locked.

resetPathPlanner();

return; // No steps included

}

float xydist2;

#if ENABLE_BACKLASH_COMPENSATION

if((p->isXYZMove()) && ((p->dir & XYZ_DIRPOS)^{Printer::backlashDir & XYZ_DIRPOS}) & (Printer::backlashDir >> 3)) // We need to compensate backlash, add a move

{

waitForXFreeLines(2);

uint8_t wpos2 = linesWritePos + 1;

if(wpos2 >= PRINTLINE_CACHE_SIZE) wpos2 = 0;

PrintLine p2 = &lines[wpos2];

 memcpy(p2,p,sizeof(PrintLine)); // Move current data to p2

 uint8_t changed = (p->dir & XYZ_DIRPOS)^{Printer::backlashDir & XYZ_DIRPOS};

 float back_diff[4]; // Axis movement in mm

 back_diff[E_AXIS] = 0;

 back_diff[X_AXIS] = (changed & 1 ? (p->isXPositiveMove() ? Printer::backlashX : -Printer::backlashX) : 0);

 back_diff[Y_AXIS] = (changed & 2 ? (p->isYPositiveMove() ? Printer::backlashY : -Printer::backlashY) : 0);

 back_diff[Z_AXIS] = (changed & 4 ? (p->isZPositiveMove() ? Printer::backlashZ : -Printer::backlashZ) : 0);

 p->dir &= XYZ_DIRPOS; // x,y and z are already correct

 for(uint8_t i = 0; i < 4; i++)

 {

 if( i = X_AXIS || i = Y_AXIS)

 float f = back_diff[i]*Printer::motorStepsPerRad[i];

 else 

 float f = back_diff[i]*Printer::axisStepsPerMM[i];

 p->delta[i] = abs((long)f);

 if(p->delta[i]) p->dir |= XSTEP << i;

 }

 //Define variables that are needed for the Bresenham algorithm. Please note that Z is not currently included in the Bresenham algorithm.

 if(p->delta[Y_AXIS] > p->delta[X_AXIS] && p->delta[Y_AXIS] > p->delta[Z_AXIS]) p->primaryAxis = Y_AXIS;

 else if (p->delta[X_AXIS] > p->delta[Z_AXIS] ) p->primaryAxis = X_AXIS;

 else p->primaryAxis = Z_AXIS;

 p->stepsRemaining = p->delta[p->primaryAxis];

 //Feedrate calc based on XYZ travel distance

 xydist2 = back_diff[X_AXIS] * back_diff[X_AXIS] + back_diff[Y_AXIS] * back_diff[Y_AXIS];

 if(p->isZMove())

 p->distance = sqrt(xydist2 + back_diff[Z_AXIS] * back_diff[Z_AXIS]);

 else

 p->distance = sqrt(xydist2);

 // 56 seems to be xstep|ystep|e_posdir which just seems odd

 Printer::backlashDir = (Printer::backlashDir & 56) | (p2->dir & XYZ_DIRPOS);

 p->calculateMove(back_diff,pathOptimize,p->primaryAxis);

 p = p2; // use saved instance for the real move

 }

#endif

 //Define variables that are needed for the Bresenham algorithm. Please note that Z is not currently included in the Bresenham algorithm.

 if(p->delta[Y_AXIS] > p->delta[X_AXIS] && p->delta[Y_AXIS] > p->delta[Z_AXIS] && p->delta[Y_AXIS] > p->delta[E_AXIS]) p->primaryAxis = Y_AXIS;

 else if (p->delta[X_AXIS] > p->delta[Z_AXIS] && p->delta[X_AXIS] > p->delta[E_AXIS]) p->primaryAxis = X_AXIS;

 else if (p->delta[Z_AXIS] > p->delta[E_AXIS]) p->primaryAxis = Z_AXIS;

 else p->primaryAxis = E_AXIS;

 p->stepsRemaining = p->delta[p->primaryAxis];

 if(p->isXYZMove())

 {

// xydist2 = axisRotationRad[X_AXIS] * EEPROM::armLength() + axisRotationRad[Y_AXIS] * EEPROM::forearmLength(); 

 xydist2 = axisRotationRad[X_AXIS] * axisRotationRad[X_AXIS] + axisRotationRad[Y_AXIS] * axisRotationRad[Y_AXIS];

 if(p->isZMove())

 p->distance = RMath::max((float)sqrt(xydist2 + axisRotationRad[Z_AXIS] * axisRotationRad[Z_AXIS]),fabs(axisRotationRad[E_AXIS]));

 else

 p->distance = RMath::max((float)sqrt(xydist2),fabs(axisRotationRad[E_AXIS]));

 }

 else

 p->distance = fabs(axisRotationRad[E_AXIS]);

 p->calculateMove(axisRotationRad,pathOptimize,p->primaryAxis);

}

#endif

wangsamax

#if DRIVE_SYSTEM == SCARA // Kusuma SCARA

void PrintLine::rotateXYRelativeAngleInSteps(int32_t x, int32_t y, float feedrate, bool waitEnd, bool checkEndstop,bool pathOptimize)

{

#if MOVE_X_WHEN_HOMED == 1 || MOVE_Y_WHEN_HOMED == 1

if(!Printer::isHoming() && !Printer::isNoDestinationCheck()) {

#if MOVE_X_WHEN_HOMED

if(!Printer::isXHomed())

x = 0;

#endif

#if MOVE_Y_WHEN_HOMED

if(!Printer::isYHomed())

y = 0;

#endif

}

#endif

float savedFeedrate = Printer::feedrate;

int32_t destinationScaraSteps[X_AXIS] = Printer::currentNonlinearPositionSteps[X_AXIS] + x;

int32_t destinationScaraSteps[Y_AXIS] = Printer::currentNonlinearPositionSteps[Y_AXIS] + y;

Printer::feedrate = feedrate;

if (!queueScaraMove(checkEndstop, pathOptimize, false))

{

Com::printWarningFLN(PSTR("rotateXYRelativeAngleInSteps / queueScaraMove returns error"));

}

#endif

Printer::feedrate = savedFeedrate;

Printer::updateCurrentPosition(false);

if(waitEnd)

Commands::waitUntilEndOfAllMoves();

previousMillisCmd = HAL::timeInMilliseconds();

}

#endif

wangsamax

Sorry I'm quite sure my post above must be wrong.

I rewrite it, would you please check if this is right or wrong?

void PrintLine::rotateXYRelativeAngleInSteps(int32_t x, int32_t y, float feedrate, bool waitEnd, bool checkEndstop,bool pathOptimize)

{

#if MOVE_X_WHEN_HOMED == 1 || MOVE_Y_WHEN_HOMED == 1

if(!Printer::isHoming() && !Printer::isNoDestinationCheck()) {

#if MOVE_X_WHEN_HOMED

if(!Printer::isXHomed())

x = 0;

#endif

#if MOVE_Y_WHEN_HOMED

if(!Printer::isYHomed())

y = 0;

#endif

}

#endif

float savedFeedrate = Printer::feedrate;

Printer::NonlinearDestinationSteps[X_AXIS] = Printer::currentNonlinearPositionSteps[X_AXIS] + x;

Printer::NonlinearDestinationSteps[Y_AXIS] = Printer::currentNonlinearPositionSteps[Y_AXIS] + y;

Printer::currentNonlinearPositionSteps[Z_AXIS] = Printer::currentPositionSteps[Z_AXIS];

Printer::feedrate = feedrate;

transformScaraStepsToCartesianSteps(Printer::currentNonlinearPositionSteps, Printer::currentPositionSteps);

if (!queueScaraMove(checkEndstop, pathOptimize))

{

Com::printWarningFLN(PSTR("rotateXYRelativeAngleInSteps / queueScaraMove returns error"));

}

Printer::feedrate = savedFeedrate;

Printer::updateCurrentPosition(false);

if(waitEnd)

Commands::waitUntilEndOfAllMoves();

previousMillisCmd = HAL::timeInMilliseconds();

}

uint8_t PrintLine::queueScaraMove(uint8_t check_endstops, uint8_t pathOptimize)

{

Printer::unsetAllSteppersDisabled(); // Motor is enabled now

waitForXFreeLines(1);

int32_t difference[2];

PrintLine *p = getNextWriteLine();

p->flags = (check_endstops ? FLAG_CHECK_ENDSTOPS : 0);

p->joinFlags = 0;

if(!pathOptimize) p->setEndSpeedFixed(true);

p->dir = 0;

float axisRotationRad[2];

for(fast8_t axis = 0; axis < 2; axis++)

{

difference[axis] = Printer::NonlinearDestinationSteps[axis] - Printer::currentNonlinearPositionSteps[axis];

if (difference[axis] >=0)

p->setPositiveDirectionForAxis(axis);

else

difference[axis] = -difference[axis];

if(difference[axis]) p->setMoveOfAxis(axis);

axisRotationRad[axis] = fabs(difference[axis] / Printer::motorStepsPerRad[axis]);

Printer::currentNonlinearPositionSteps[axis] = Printer::NonlinearDestinationSteps[axis];

}

if (difference[X_AXIS] >= difference [Y_AXIS])

{

p->primaryAxis = X_AXIS;

p->stepsRemaining = difference[X_AXIS];

}

else

{

p->primaryAxis = Y_AXIS;

p->stepsRemaining = difference[Y_AXIS];

}

p->distance = fabs(axisRotationRad[p->primaryAxis]);

p->calculateMove(axisRotationRad,pathOptimize,p->primaryAxis);

return true; // flag success

}

wangsamax

Hi,

when I upload, I get this warning message, is this okay?

Sketch uses 143,716 bytes (56%) of program storage space. Maximum is 253,952 bytes.

Global variables use 7,011 bytes (85%) of dynamic memory, leaving 1,181 bytes for local variables. Maximum is 8,192 bytes.

Low memory available, stability problems may occur.

Repetier

First more then 1kb free ram is ok. If you get below reduce subdivisions of move to get more free ram.

Your homing understanding was incorrect I think. Think more abstract here. The reason for homing is to have a known starting position so X,y = 0,0 is at bed center. For Z it's just min/max endstop and easy. For xy position you need to know the angles of your scara, so cartesian koordinates do not help as you need to know the angles for this. So home XY means put scara angles at defined position. So you move here the angles towards your endstop in a way nothing gets damaged. So I assume first big arm, then second arm. Then you know where you are and can also set the cartesian coordinates.

Your second version looks better but you need to base queueScaraMove on queueNonlinearMove more closely. Your version looks more like the cartesian version, but you are nonlinear and need to fill in the submoves of a move correctly. Here the critical part is that each move stays inside int16_t range for steps.

Speaking of precision int32_t = long for 8/32 bit, int64_t is long long, but don't use it. Better convert it to float before squaring, then you have no range problems. Later you need it as float anyway for acos etc.