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.

https://www.youtube.com/watch?v=Up78QgEejOo </div><div>

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.