Repetier Working on my robot arm 3d printer

wangsamax

Hi repetier,

finally I can try to print using my robot arm with repetier firmware. honestly I almost give up.

it still not perfect but it works.

this is the documentation video of how it run.

anyway I still have some questions

1. I confuse about bed leveling method and bed correction method. what is the difference between those two. can I use bed leveling method 0, bed correction method 1 or vise versa?

2. how to make G32 move faster? how to change the up move distance after touching bed?

3. please watch the video, see when it homing and when z axis go down before printing. Seems like it stopped several times, how to fix this?

Thanks

Repetier

1. BED_LEVELING_METHOD is how you measure the tilt of the bed. All methods return a optimal plate depending on the measurement method. You need 3 points but more help if you have some measuring errors or bed is a bit wavy to get a better overall plane.

BED_CORRECTION_METHOD is the way you correct the computed rotation. Software or mechanical side. Botha re independent and you can mix any combination that your hardware supports.

2. It always goes back to starting height so start deeper. Probe bed distance is the distance it does when homed under some conditions otherwise make sure you start within that height to bed. Apart from this change the xy or z probe speeds.

3. You can not really fix this. It has to do with the nonlinear motion splitting moves into submoves and the fact that we do not change speeds for started moves. So what happens is a move is e.g. split in 3 moves and movement starts on first move. As move 2 and 3 were not there at start oath planner said to slow down at and. When move 2 is added is sees move 1 is running so it can not change that move and must start from low speed. Only solution would be to always add a longer wait before first move but then the first move would wait a longer time before starting. So these pauses are no bugs just the result of how it works. In real print you do not notice as the buffer is at some point full so it always can get up to speed. But here you always start from paused so longer moves will always show that.

wangsamax

Hi repetier,

in my case, I use my nozzle as probe. when it touch the bed it switch z-min endstop pin. 

i don't activate z min. 

when I command G32, it go near bed, but after the first point it touch the bed, suddenly it jump.

you can see it in the video, and bellow is the command info. first point is 3.32, 2nd point is 64.45. I don't understand what happen.

03:31:03.647 : Z-probe:3.32 X:-80.00 Y:-80.00

03:31:08.673 : Z-probe:64.45 X:-80.00 Y:-40.00

03:31:16.656 : Z-probe:64.61 X:-80.00 Y:0.00

03:31:24.610 : Z-probe:64.10 X:-80.00 Y:40.00

.

.

.

I set my Z max in EEPROM 196.040

after g32, it said that printer height is 267.65

so when i give g1 z0 command, it hit bed so hard.

please tell me what I did wrong.

this is my configuration.h

#define Z_PROBE_Z_OFFSET 0

#define Z_PROBE_Z_OFFSET_MODE 0

#define UI_BED_COATING 1

#define FEATURE_Z_PROBE 1

#define Z_PROBE_BED_DISTANCE 10

#define Z_PROBE_PIN ORIG_Z_MIN_PIN

#define Z_PROBE_PULLUP 0

#define Z_PROBE_ON_HIGH -1

#define Z_PROBE_X_OFFSET 0

#define Z_PROBE_Y_OFFSET 0

#define Z_PROBE_WAIT_BEFORE_TEST 0

#define Z_PROBE_SPEED 30

#define Z_PROBE_XY_SPEED 300

#define Z_PROBE_SWITCHING_DISTANCE 0.5

#define Z_PROBE_REPETITIONS 1

#define Z_PROBE_HEIGHT 0

#define Z_PROBE_START_SCRIPT ""

#define Z_PROBE_FINISHED_SCRIPT ""

#define Z_PROBE_REQUIRES_HEATING 0

#define Z_PROBE_MIN_TEMPERATURE 150

#define FEATURE_AUTOLEVEL 1

#define Z_PROBE_X1 -80

#define Z_PROBE_Y1 -80

#define Z_PROBE_X2 80

#define Z_PROBE_Y2 -80

#define Z_PROBE_X3 -80

#define Z_PROBE_Y3 80

#define BED_LEVELING_METHOD 1

#define BED_CORRECTION_METHOD 0

#define BED_LEVELING_GRID_SIZE 5

#define BED_LEVELING_REPETITIONS 5

#define BED_MOTOR_1_X 0

#define BED_MOTOR_1_Y 0

#define BED_MOTOR_2_X 200

#define BED_MOTOR_2_Y 0

#define BED_MOTOR_3_X 100

#define BED_MOTOR_3_Y 200

#define BENDING_CORRECTION_A 0

#define BENDING_CORRECTION_B 0

#define BENDING_CORRECTION_C 0

#define FEATURE_AXISCOMP 0

#define AXISCOMP_TANXY 0

#define AXISCOMP_TANYZ 0

#define AXISCOMP_TANXZ 0

Repetier

With nonlinear moves a pure z move must fit into one move so it must not be split into several moves but maximum into several segements in same move. If that does not happen z homing and leveling might go wrong. See original nonlinear queue where you see pure z moves are a special case.

I assume the 3,x mm were correct and 64mm wrong? Or did it really go so much up after first probe? From your z max values I concluded that the lower value would be correct.

wangsamax

Yes, 3.x correct, 64 wrong.
I just notice that g30 is also behave the same. I jump after touch bed. I suppose it shouldn't behave that way... right?
What did i do wrong?

Repetier

As I said I guess you have split the z move into more then one move on planner and that is not allowed for probing/homing. Just a guess but when I had similar problems that was the reason. Then I added the special case for only one move using the maximum of steps per segment and not 100 segments per second at it worked.

wangsamax

I didn't do anything with z move, but i'll try to see it.

Repetier

Problem is I don't know what you changed. It is part of the nonlinear queue move function I think.

Otherwise you know the typical solution to debug? Adding Com::printFLN(PSTR("msg"),value); at strategic places to see where shit happens and then find out what is really going on.

wangsamax

That' great idea. I'll try it

wangsamax

Hi Repetier,

I found this in nonlinear queue. 

    else

    {

        // Optimize pure Z axis move. Since a pure Z axis move is linear all we have to watch out for is unsigned integer overruns in

        // the queued moves;

#ifdef DEBUG_SPLIT

        Com::printFLN(Com::tDBGDeltaZDelta, cartesianDeltaSteps[Z_AXIS]);

#endif

        segmentCount = (cartesianDeltaSteps[Z_AXIS] + (uint32_t)43680) / (uint32_t)43679; // can not go to 65535 for rounding issues causing overflow later in some cases!

    }

I think it do split Z move by 43680 each segment, right?

I didn't modify it, it exactly the same as original download.

Repetier

Yes, that is the part I spoke of. For z homing/probing you must have pure Z moves so your steps fit into one move with it's x subsegments. Maybe add some debug prints there to see if it is using that part.

wangsamax

Hi repetier,

I've add debug. 

home, g30, g32, all use that part.

I'm not sure what I suppose to do with this

Repetier

Looking your video again I saw that it goes down very close to bed for first probe so 3.x might even be correct and then it goes up higher always which is also what you measure.

As you use nonlinear behavior for non delta it is hard to say what is going wrong. All the code is made to work on deltas correctly, but you don't have a delta. Did you make any changes to autoleveling code? Since it is not the move itself it might be good to log all moves executed and at some points in bed leveling add also comments to find our where which move gets wrong distance and debug from there onwards.

wangsamax

Hi Repetier,

I found that I make mistakes about Z_PROBE_PULLUP and Z_PROBE_ON_HIGH.

It was both 0, and it makes the switch unstable. after I fix it, it became stable.

but it doesn't fix the problem. now I get even more strange behavior.

after probe trigerred, it doesn't move up. it just vibrating no where.

I tried to debug the G30 by track runZProbe function, and this is what I get:

02:15:29.228 : Short Move:1200

02:15:29.228 : Last Correction:4040

02:15:29.228 : Probe Depth:112000

02:15:29.960 : Step Remaining At Z Hit:106930

02:15:29.975 : Current Position Steps Z Axis:-1030

02:15:29.975 : Distance:12.68

02:15:29.975 : Z-probe:12.68 X:-0.01 Y:0.01

02:15:29.975 : Go To Start Position - Last Correction:4040

02:15:29.975 : Go To Start Position - Current Position Steps Z Axis:-1030

I think it's normal right?

wangsamax

Hi repetier, 

I try to dig it depper and this is the result

02:55:36.985 : Current Position Steps Z Axis:4040

02:55:36.985 : Last Correction =  :4040

02:55:36.985 : Current Non Linear Position Steps Z Axis:4040

02:55:37.016 : Real Delta Position Steps = Current Non Linear Position Steps:4040

02:55:37.016 : Probe Depth:112000

02:55:37.744 : Current Non Linear Position Steps C Tower:-107960

02:55:37.744 : Real Delta Position Steps C Tower-1061

02:55:37.765 : Step Remaining At Z Hit = Real Delta Pos C Tower - Current Nonlinear Pos C Tower:106899

02:55:37.765 : Current Position Steps Z Axis:-107960

02:55:37.765 : Step Remaining At Z Hit:106899

02:55:37.765 : Current Position Steps Z Axis + = stepsRemainingAtZHit:-1061

02:55:37.765 : Distance:12.75

02:55:37.781 : Z-probe:12.75 X:-0.01 Y:0.01

02:55:37.781 : Go To Start Position - Last Correction:4040

02:55:37.781 : Go To Start Position - Current Position Steps Z Axis:-1061

02:55:37.796 : Move Relative Distance in steps:5101

I notice there is something strange with Real Delta Position Steps

the first it defined = Current Non Linear Position Steps Z Axis with value 4040

suddenly I don't know why it changed to -1061

and Current Non Linear Position Steps Z Axis become -107960 ???

is this normal ?

wangsamax

I do have delta printers, they work with repetier properly. And I modify the firmware from my delta.

I didn't change bedleveling files at all, and didn't change the moves functions and nonlinear queue.

The changes is only coordinate transformation with forward and inverse kinematics.
And add some new functions specific for scara movements.

I change alot the ui for user display but i don't think this has something to do with the problem.

wangsamax

I figure value 4040 came from bed probe distance since i put value 10 and my z step per unit is 400.

I've tried to add new value to replace real delta position steps so it didn't change, the result is error after probe hit bed.

So i think the value of real delta position steps might be correct.
And the final result move to 5101 also might be correct. 5101 / 400 = 12.7525. Same as distance.

The problem is the printer doesn't go to 12.7525
And the feedrate is not z probe feedrate, it's way faster than z probe feedrate. This cause the jumping ( in my last modification it just vibrating because i doubled the z axis step per unit, it's too fast)

I tried to find the function but didn't find any functions that command z axis to move that fast.

wangsamax

Hi repetier,

I found that this line in Printer::runZProbe cause the trouble:

PrintLine::moveRelativeDistanceInSteps(0, 0, lastCorrection - currentPositionSteps[Z_AXIS], 0, EEPROM::zProbeSpeed(), true, true);

I don't know how but I'm sure that function misbehave. 

it suppose to command to go back to start position, but somehow the value seems multiplied  both (lastCorrection - currentPositionSteps[Z_AXIS]) and zProbeSpeed value.

this cause the jump.

I'm sure because I try to divide the zProbeSpeed in the command with zProbeSpeed /100.

the result is it still jump high but the speed is very slow.

Then I make it back to zProbeSpeed, upload and change the value of the speed in EEPROM from 10 to 1. 

the result is first the nozzle move to start point with z homing feedrate, then hit the bed with z probe feedrate (1), then it go up high (jump) slower than ussual, but I think it is 10 times faster than it go down.

the final z position in ui display is 10.10 mm. this is wrong, the fact is the nozzle is not that high.

and it seems that it happen only once the first time.

it happen in G30 and in G32 first point. 

2nd point and next it no problem.

Repetier

The big values for C tower are correct. It want's to go down 2*z length so that is a big number. But you see also remeining steps is equally high so real steps done is much less.

That function causes in deed sometimes problems if the z max endstop gets triggered e.g. from crosstalk it will stop too eraly. In current dev version I set endstop testing to false (last param I think it was). If that is not the problem the question qould be why lastCorrection or currentPositionSteps did become wrong. 

wangsamax

Hi Repetier, I found the problem and fix.

in Printer::runZProbe, after nozzle hit bed, it suppose to add stepsRemainingAtZHit to currentPositionSteps, and currentNonlinearPositionSteps.

you add currentNonlinearPositionSteps with stepsRemainingAtZHit  just if drive system == delta.

so for non delta the currentNonlinearPositionSteps is not change, -107960 in my case.

this is the track in moveRelativeDistanceInSteps for runZProbe.

14:30:04.964 : moveRelativeDistanceInSteps -> Printer::currentPositionSteps[Z_AXIS]:-1033

14:30:04.980 : moveRelativeDistanceInSteps -> Printer::currentNonlinearPositionSteps[Z_AXIS]:-107960

So, I add this right after if drive system == delta in runZProbe.

#if NONLINEAR_SYSTEM

        currentNonlinearPositionSteps[C_TOWER] += stepsRemainingAtZHit;

#endif

it solve all the problem both G30 & G32.

wangsamax

btw, sorry to ask this stupid question.

after we run G32 S2. is it done with autolevel bed? 

I mean is it will going up and down according to bed surface when print, or we have to do something else?

Repetier

Well done. You are right that for other nonlinear systems you still need to add z part. Have added this for next update in case we add other nonlinear systems.

G32 only fixes rotation of bed. So if your bed is planar it is all you need. If it has bumps or is slightly curved you might want to add distortion correction support (G33). No extra programming should be required here.

wangsamax

Hi repetier, 

now I got another strange behavior, I don't know what I did wrong.

I've trace it and this is what happen.

my zMax is 195.5

after home, z pos is 195.5, lastcmd 195.5

this is the strange behavior:

1. when I command G30 & G32, it going wild, all three motor move don't know where.

2. when I command go down with repetier host manual command down button, whatever my command is, it go to z 180.

3. when I command go right / left then go down, it no problem.

when I try to trace, after home, currentposition, currentpositionSteps, currentNonlinearpositionsteps, lastcmdsteps, all in correct value.

then it run

Printer::setDestinationStepsFromGCode(GCode *com)

if(com->hasZ()) currentPosition[Z_AXIS] = (lastCmdPos[Z_AXIS] += convertToMM(com->Z));

at that line, lastCmdPos suddenly changed to 180. and the cause is the com->Z that line suddenly became 15.5

I don't know where this 15.5 value come from. there is nothing I search is that value in code and in eeprom.

Then I trace further, I found that this command give that value

GCode::parseBinary(uint8_t *buffer,bool fromSerial)

    if(hasZ())

    {

        Z = *(float *)p;

        p += 4;

    }

The Z before that line is correct. but changed to 15.5 after that line.

I don't know what should I do next after this. 

Please help

wangsamax

HI repetier,

I found out it goes to 180 every first time after home because the printer shape in repetier host is 180. 

but I still get strange behavior in G30, G32. 

Repetier

Wasn't G32 working?

Deltas home before leveling so all 3 go up for homing. Have you added your own homing routine? Not sure what else a can say to "it going wild, all three motor move don't know where.". First move is homing and so i assume it has to do with that also you said homing in general is working, but maybe there is again a special case for delta vs nonlinear in general.

wangsamax

G30 and g32 was working. But sometimes they don't.

I add printfln com->g, com->x, com->y, com->z to trace.

For g30 and g32 in normal case, it com g is 1 com x & y is 0, com z is 10.

In some point, it suddenly change by it self x com x & com y has it own value.

For homeaxis, i figure it out, the working route is home z, close elbow, close shoulder, go to bed center, then home z again. G30 & g32 are working.

If i remove the last home z, it going wild. G30 & g32 don't work. Something somehow add g1 command with strange x & y value.

I've check if it have something to do with allowed, i add printfln. It doesn't check allowed.

Repetier

Autoleveling has several G1 moves to move to probing position, start/end script. I guess you need some extr println to find the one adding that move and find out what home does change so it works.

wangsamax

The clue i have is it generate gcode in startzprobe function, after moveto().
Suddenly it generate some moverelative() command.

I can't find what function generate g code.

Maybe it the same function in this case.
When my zmaxheight is 200, my printer dimension in repetier host is 180, when we command g30, it automatic generate moverelative to z-20.
I can't find which function generate z-20, but it did. Please tell me how this work & which function generate the z-20.

But it maybe not that too, because in some case it generate g1 x----- y----- z----- f-----
Please tell me which function able to generate gcode like that.

Tx

Repetier

Actually bed leveling does not send any gcodes, it calls themove functions directly. Only the start/end z probe script can have additional g-code that gets called when you activate/deactivate the probe.

z-20 is a bit odd since we go down 2*z length if we go down for testing.

wangsamax

This must be have something to do with autolevel. If i turn off autolevel, g30 is fine. If autolevel is turn on, g30 is moving x y direction.

I mean before 2*z length command.
Normally if we g30, nozzle go to probe bed distance then 2*z length.
This wild movement is before go to probe bed distance.

Maybe you can try to set printer height in printer setting repetier host (not eeprom) that bellow your actual z height.

wangsamax

Hi repetier, i think the problem is it don't wanna go to y negative direction if y negatif & if autolevel activated.

It's fine if autolevel deactivate.
How is this happen?