search

repetier / Repetier-Firmware

Firmware for Arduino based RepRap 3D printer.
815 stars 734 forks source link

CoreXY X and Y steps per mm need to be doubled #466

Open jamesarm97 opened 8 years ago

jamesarm97 commented 8 years ago

I have found now that on two printers I have build that for some reason when running with the firmware set to CoreXY mode the steps per mm for the X and Y need to be doubled from what they normally are on any other firmware or based on the calculations and stepper micro stepping. I don't know if this is something that is normally accounted for on other systems but I was under the impression CoreXY will run even with cartesian set but just rotated 45 degrees. Maybe there is extra math being done that should not have to be requiring the need for the steps / mm to be changed. If my steps / mm would normally be 80 when I switch to Repetier with CoreXY set I have to change them to 160.

repetier commented 8 years ago

Yes, you need to double the value you would get from one motor driver and pulley, that is no error but a requirement to allow step by step moves to all direction, as you have 2 motors adding to the move and stepping both might be more then you wanted.

rcarlyle commented 8 years ago

Different firmwares handle this different ways. I don't understand Repetier's way though. The proper value has to do with how the kinematic transform is done. The TRUE steps/mm for CoreXY (single motor steps per XY carriage motion) is the nominal pulley/motor steps/mm times sqrt(2), with the carriage motion axis diagonal to the linear hardware. On the other hand, if you calculate Cartesian motor steps first and then do kinematics after as A=X+T, B=X-Y (like Sailfish) then the proper steps/mm is the nominal pulley/motor steps/mm and the kinematics transform handles the belt geometry.

I have no idea how Repetier gets doubled steps from that. The two logical values based on the physical belt arrangement are the nominal pulley/motor steps/mm, and that same value times 1.41.

rcarlyle commented 8 years ago

If I'm reading the code correctly, it looks like Repetier only fires CoreXY motor steps after EVERY OTHER stepper tick. See: https://github.com/repetier/Repetier-Firmware/blob/ce05b5f5acf7000e93937f4448e08d6293799baf/src/ArduinoAVR/Repetier/motion.h#L521 (Add one to motorX) https://github.com/repetier/Repetier-Firmware/blob/ce05b5f5acf7000e93937f4448e08d6293799baf/src/ArduinoAVR/Repetier/Printer.h#L855 (step if motorX >= 2)

Other firmwares with CoreXY support do not do this. Why is it being done here?

This could account for the many recent reports of poor CoreXY performance with Repetier on Due. (For example https://groups.google.com/forum/#!topic/3dprintertipstricksreviews/_j-rG-c_RH4)

repetier commented 8 years ago

In general there are 2 approaches. Convert coordinates when send, but then returned coordinates would not match what you think with x/y but it would be the motor position on belt.

In order to keep position = xyz as you expect we transform during bresenham. There it is possible that one diagonal step increases motor 2 times. To prevent this steps were doubled, so that this case creates only max. one step per motor. That's why it is doubled. These computations need to be done in bresenham so moving motors is a bit later. On due it still reaches 300000Hz so 150000 real steps per axis. Unfortunately I do not own a core xy printer so all changes are done just from what I hear and on a logic analyser.

rcarlyle commented 8 years ago

Why is it bad if the motor steps twice on diagonals? Seems like you're adding a lot of processing steps to a speed-critical area in order to avoid something that would be similar to the double-stepping/quad-stepping we already do.

I believe Sailfish does the transform after Cartesian steps are calculated, but before Bresenham's starts. So on diagonal moves, the motor gets twice as many steps but they are evenly spaced. And on X or Y axis moves it steps both motors in one tick and does not have all the extra "step only one motor" ticks that it appears Repetier is doing.

I would have to do some digging to see what Marlin etc do.

repetier commented 8 years ago

If I step twice in a interrupt I need to detect that and add a delay for step high signal. Best would maybe to handle it like delta printer as nonlinear but with only 1 update per second since it is in reality linear. That would give the additional coordinate system where we could put the transformation to and have the fast computation as you have seen it in sailfish. No extra nonsense and bookkeeping. All we would need is to declare these as nonlinear and add a transformation which is also very simple compared to delta. Would just need someone who can do all the tests since I do not have a core xy printer. But that would in deed increase speed by at least factor 2.

jamesarm97 commented 8 years ago

Well I'm sure both of us would be up to testing it. I started to copy and paste what Marlin was doing but stopped. They seem to be treating this as A_AXIS and B_AXIS and also keeping track of X_HEAD / Y_HEAD for actual move directions. So Marlin is doing the following in stepper.cpp to check the endstops during moves and planner.cpp for the stepper enable tests:

if ((current_block->steps[A_AXIS] != current_block->steps[B_AXIS]) || (TEST(out_bits, A_AXIS) == TEST(out_bits, B_AXIS))) {
  if (TEST(out_bits, X_HEAD))

if ((current_block->steps[A_AXIS] != current_block->steps[B_AXIS]) || (TEST(out_bits, A_AXIS) != TEST(out_bits, B_AXIS))) {
  if (TEST(out_bits, Y_HEAD))

Planner.cpp:

if ENABLED(COREXY)

// corexy planning
// these equations follow the form of the dA and dB equations on http://www.corexy.com/theory.html
block->steps[A_AXIS] = labs(dx + dy);
block->steps[B_AXIS] = labs(dx - dy);
block->steps[Z_AXIS] = labs(dz);

elif ENABLED(COREXZ)

// corexz planning
block->steps[A_AXIS] = labs(dx + dz);
block->steps[Y_AXIS] = labs(dy);
block->steps[C_AXIS] = labs(dx - dz);

else

// default non-h-bot planning
block->steps[X_AXIS] = labs(dx);
block->steps[Y_AXIS] = labs(dy);
block->steps[Z_AXIS] = labs(dz);

endif

// Compute direction bits for this block uint8_t db = 0;

if ENABLED(COREXY)

if (dx < 0) db |= BIT(X_HEAD); // Save the real Extruder (head) direction in X Axis
if (dy < 0) db |= BIT(Y_HEAD); // ...and Y
if (dz < 0) db |= BIT(Z_AXIS);
if (dx + dy < 0) db |= BIT(A_AXIS); // Motor A direction
if (dx - dy < 0) db |= BIT(B_AXIS); // Motor B direction

elif ENABLED(COREXZ)

if (dx < 0) db |= BIT(X_HEAD); // Save the real Extruder (head) direction in X Axis
if (dy < 0) db |= BIT(Y_AXIS);
if (dz < 0) db |= BIT(Z_HEAD); // ...and Z
if (dx + dz < 0) db |= BIT(A_AXIS); // Motor A direction
if (dx - dz < 0) db |= BIT(C_AXIS); // Motor B direction

else

if (dx < 0) db |= BIT(X_AXIS);
if (dy < 0) db |= BIT(Y_AXIS);
if (dz < 0) db |= BIT(Z_AXIS);

endif

if (de < 0) db |= BIT(E_AXIS); block->direction_bits = db;

block->active_extruder = extruder;

//enable active axes

if ENABLED(COREXY)

if (block->steps[A_AXIS] || block->steps[B_AXIS]) {
  enable_x();
  enable_y();
}
#if DISABLED(Z_LATE_ENABLE)
  if (block->steps[Z_AXIS]) enable_z();
#endif

elif ENABLED(COREXZ)

if (block->steps[A_AXIS] || block->steps[C_AXIS]) {
  enable_x();
  enable_z();
}
if (block->steps[Y_AXIS]) enable_y();

else

if (block->steps[X_AXIS]) enable_x();
if (block->steps[Y_AXIS]) enable_y();
#if DISABLED(Z_LATE_ENABLE)
  if (block->steps[Z_AXIS]) enable_z();
#endif

endif

jamesarm97 commented 8 years ago

and I guess this part is related:

/**

repetier commented 8 years ago

Ok, I will see that I make switch

define FAST_COREXYZ

that needs to be set for alternative version and add it as nonlinear solution. We will then see if that is enough or if there are problems I haven't thought of. If not it will simply be much faster. As a result also different resolutions for x and y motor might be possible, but I will start first with the identical computations.

rcarlyle commented 8 years ago

So, just thinking out loud, there are kind of two separate issues we're dealing with here: 1) The true physical motor step size resolution for CoreXY is 1/sqrt(2) ~= 71% of the size calculated by the pulley diameter and belt pitch, due to the 90-degree belt deflection on the Y carriages. 2) We need to do some kind of kinematic transform to get from a gcode Cartesian spatial coordinate system that is aligned with the linear hardware axes, to a diagonal rotated actuator step coordinate system.

The various techniques that Marlin, Repetier, Sailfish, etc are using all seem to combine these two issues into one conversion, but are doing it in different ways.

If we were imagining an algorithm from scratch without worrying about any other code interactions, I think we would want to do this: 1) Calculate acceleration and velocity in Cartesian space as normal, to respect gantry hardware limits 2) Perform spatial coordinate transform to rotate Cartesian axis distances to get CoreXY diagonal axis distances 3) If necessary, re-check acceleration limits in rotated CoreXY distance space, to respect motor limits 4) Convert CoreXY distances to motor steps using the true physical step size resolution

Instead it seems that we have been applying "virtual" steps/mm values to the Cartesian coordinates to get "virtual" Cartesian motor steps, and then doing a rotation transform hack to get to CoreXY steps. That works in practice (and might be much faster...) but is not a very rigorous approach.

repetier commented 8 years ago

Just uploaded first test version to master tree. You need to add

define FAST_COREXYZ

to Configuration.h and set xy steps per mm to 50% of what you had before.

Please let me work if kinematic is still working correct and if it works faster. I could only test that it still compiles. Kinematics is in motion.cpp

ifdef FAST_COREXYZ

uint8_t transformCartesianStepsToDeltaSteps(int32_t cartesianPosSteps[], int32_t corePosSteps[]) {

if DRIVE_SYSTEM == XY_GANTRY

//1 = z axis + xy H-gantry (x_motor = x+y, y_motor = x-y)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Y_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[X_AXIS] - cartesianPosSteps[Y_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[X_AXIS];  
#elif DRIVE_SYSTEM == YX_GANTRY
// 2 = z axis + xy H-gantry (x_motor = x+y, y_motor = y-x)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Y_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS] - cartesianPosSteps[X_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[X_AXIS];
#elif DRIVE_SYSTEM == XZ_GANTRY
// 8 = y axis + xz H-gantry (x_motor = x+z, z_motor = x-z)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Z_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[X_AXIS] - cartesianPosSteps[Z_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[X_AXIS];
#elif DRIVE_SYSTEM == ZX_GANTRY
//9 = y axis + xz H-gantry (x_motor = x+z, z_motor = z-x)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Z_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS] - cartesianPosSteps[X_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[X_AXIS];
#endif
return 1;

}

endif

jamesarm97 commented 8 years ago

(never mind, it looks like master is now up to speed with the work92 branch). ok, I will have to see if I can use the master branch. I have been using the work092 for some time now. It looks like you commit also included some other changes. I may try and sort out what is needed to change the work092 branch I use.

repetier commented 8 years ago

I have merged work092 to master. So that should be no problem if it was up to date.

jamesarm97 commented 8 years ago

Well, I don't think that worked unless I really messed up. Used my previous config and added the new flag. When I try and home or do anything with the steppers the code hard locks, no control or lcd updates.

repetier commented 8 years ago

I just had an idea to add a core xy without axis modification, so I can test the nonlinear version myself. And in deed it does not move motors. Already found that the updates per second were not copied to eeprom and are set invalid. But that is not the only problem. Will investigate further and report when a cartesian printer in nonlinear mode starts to work..

jamesarm97 commented 8 years ago

Any update or movement on this issue?

repetier commented 8 years ago

Yes. Internally it works with a fake math for cartesian printers. Were quite some changes so I'm glad I came up with the fake gantry solution for testing. I'm just searching why my prints fail while working in cartesian mode has no problems to print without loosing steps. There must be some math different and that should not happen with identical systems. Once that is solved I push the version.

repetier commented 8 years ago

Ok, I have just uploaded the new versions for testing. With GANTRY_FAKE I have printer several hours now without any problems, so it should work much better then last version.

The update also contains some other fixes and some speed improvements which I found while debugging my problems.

jamesarm97 commented 8 years ago

Thanks. I will give it a shot tonight. I ran into a print last night that was pausing a lot during printing so I will re-print it and see how it does.

jamesarm97 commented 8 years ago

Ok just tested. First thing I noticed is all the speeds are slower. Homing is extremely slow and ends up timing out before the endstop gets hit. I was also able to get into a state where nothing would move and the home menu choices where missing. This was after homing. The next issue is when I move X, Z moves also. Y seems to move ok. This is setup as CoreXY wi YX_GANTRY and the new flag added.

repetier commented 8 years ago

Ok, that was gladly a minor error. Transformation copied x to z axis and not z. This also means z acceleration/max speed limited speed. So for now I assume latest upload now fixes the issues you mention as they explain everything. You only need new motion.cpp file.

jamesarm97 commented 8 years ago

Ok. one last bug, X / Y / Z homes ok but when Z Min endstop is triggered X and Y will not move. I will see if anything stands out in the code.

repetier commented 8 years ago

I had to modify the endstop handling to work with gantry systems. So the error is clearly in bool NonlinearSegment::checkEndstops(PrintLine *cur, bool checkall) or the interpretation. I have made a update now testing against the global z move, but that should be no problem in your case, only for xz gantry it would otherwise cause a problem.

The new version also has a endstop debug entry in lcd menu. That way you see in log if endstop changes, making it maybe easier to search the reason.

I also tested if I can move with zmin triggered and I could. So it must be something that is different for you. The way endstop handling for this nonlinear system works is, that as soon as checkEndstops return true the move will be stopped completely. The function should return true if a endstop is triggered and we move in that direction. So unless your moves contain no z move, there is no reason to not move even when triggered and that is what worked for me.

If you have autoleveling enabled you might have zmoves to compensate rotation, but in that case you should have no zmin endstop. Or do you have?

jamesarm97 commented 8 years ago

Nothing abnormal as far as the setup. Auto level is disabled, Z Min endstop, X/Y Max endstops.

jamesarm97 commented 8 years ago

Still no go. Maybe I should try disabling the "always check endstops"

8:37:55 AM: N7 G28 X0.00 Y0.00 Z0.00 *81 < 8:37:55 AM: ok 7 < 8:37:56 AM: endstops hit: x_max:H y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:H y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:H y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:56 AM: endstops hit: x_max:L y_max:H z_min:L < 8:37:57 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:57 AM: endstops hit: x_max:L y_max:H z_min:L < 8:37:57 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:57 AM: endstops hit: x_max:L y_max:L z_min:H < 8:37:57 AM: endstops hit: x_max:L y_max:L z_min:L < 8:37:59 AM: endstops hit: x_max:L y_max:L z_min:H < 8:37:59 AM: X:350.00 Y:350.00 Z:0.000 E:0.0000 < 8:37:59 AM: wait < 8:38:00 AM: wait < 8:38:00 AM: ok 8 < 8:38:00 AM: T:5.43 /0 B:5.12 /0 B@:0 @:0

Try to move Y (no movement):

8:38:39 AM: N12 G91 2 8:38:39 AM: N13 G1 Y-10.00 F2400.00 15 < 8:38:39 AM: ok 12 8:38:39 AM: N14 G90 *5

8:40:11 AM: N24 M119 *60 < 8:40:11 AM: ok 24 < 8:40:11 AM: endstops hit: x_max:L y_max:L z_min:H

// ################ Endstop configuration #####################

define ENDSTOP_PULLUP_X_MIN true

define ENDSTOP_X_MIN_INVERTING false

define MIN_HARDWARE_ENDSTOP_X false

define ENDSTOP_PULLUP_Y_MIN true

define ENDSTOP_Y_MIN_INVERTING false

define MIN_HARDWARE_ENDSTOP_Y false

define ENDSTOP_PULLUP_Z_MIN true

define ENDSTOP_Z_MIN_INVERTING true

define MIN_HARDWARE_ENDSTOP_Z true

define ENDSTOP_PULLUP_X_MAX true

define ENDSTOP_X_MAX_INVERTING false

define MAX_HARDWARE_ENDSTOP_X true

define ENDSTOP_PULLUP_Y_MAX true

define ENDSTOP_Y_MAX_INVERTING false

define MAX_HARDWARE_ENDSTOP_Y true

define ENDSTOP_PULLUP_Z_MAX true

define ENDSTOP_Z_MAX_INVERTING false

define MAX_HARDWARE_ENDSTOP_Z false

define max_software_endstop_r true

define min_software_endstop_x true

define min_software_endstop_y true

define min_software_endstop_z false

define max_software_endstop_x false

define max_software_endstop_y false

define max_software_endstop_z true

define ENDSTOP_X_BACK_MOVE 5

define ENDSTOP_Y_BACK_MOVE 5

define ENDSTOP_Z_BACK_MOVE 2

define ENDSTOP_X_RETEST_REDUCTION_FACTOR 3

define ENDSTOP_Y_RETEST_REDUCTION_FACTOR 3

define ENDSTOP_Z_RETEST_REDUCTION_FACTOR 4

define ENDSTOP_X_BACK_ON_HOME 1

define ENDSTOP_Y_BACK_ON_HOME 1

define ENDSTOP_Z_BACK_ON_HOME 0

define ALWAYS_CHECK_ENDSTOPS 1

// ################# XYZ movements ###################

define X_ENABLE_ON 0

define Y_ENABLE_ON 0

define Z_ENABLE_ON 0

define DISABLE_X 0

define DISABLE_Y 0

define DISABLE_Z 0

define DISABLE_E 0

define INVERT_X_DIR 0

define INVERT_Y_DIR 0

define INVERT_Z_DIR 0

define X_HOME_DIR 1

define Y_HOME_DIR 1

define Z_HOME_DIR -1

define X_MAX_LENGTH 320

define Y_MAX_LENGTH 320

define Z_MAX_LENGTH 300

define X_MIN_POS 0

define Y_MIN_POS 0

define Z_MIN_POS 0

define DISTORTION_CORRECTION 0

define DISTORTION_CORRECTION_POINTS 5

define DISTORTION_CORRECTION_R 100

define DISTORTION_PERMANENT 1

define DISTORTION_UPDATE_FREQUENCY 15

define DISTORTION_START_DEGRADE 0.5

define DISTORTION_END_HEIGHT 1

define DISTORTION_EXTRAPOLATE_CORNERS 0

define DISTORTION_XMIN 10

define DISTORTION_YMIN 10

define DISTORTION_XMAX 190

define DISTORTION_YMAX 190

jamesarm97 commented 8 years ago

Disabling the Always Check Endstops got around the problem but the problem didn't exist until the new changes.

repetier commented 8 years ago

In cartesian systems a endstop hit only stops that move. In nonlinear systems which we now use we can not assume this works and need to stop all moves. That might be why it worked before.

Just found out that I forgot to set fast core in my last test. Now nothing moves for me too when z min is triggered, so will see what it is.

repetier commented 8 years ago

Ok, don't know why but my last change you should have tested was gone. Maybe from the other pull requests I included, don't know. With that reinserted it started working also with always check endstops.

What about speed/quality of the new system. Do you feel it works faster then the original version?

jamesarm97 commented 8 years ago

Ok. that fixed all the homing and movements. I was able to re-enable the Always Check Endstops. About to start testing speed and small segments (circles) now.

jamesarm97 commented 8 years ago

Ok. Still weirdness going on. Everything homes but depending on how far away from the endstops it may timeout. Once homed X=350, Y=350, Z=0. If I issue G1 X300 it moves fast to X300. If I issue anything much past that like G1 X200 it moves extremely slow and never gets to pos 200. Steps were halved and if I move +- 50 it moves 50 but something is going on that over a certain move distance it goes slow and never gets there. I can't put my finger on what it is. I will keep trying to see where the move limit is at.

Just did some relative moves and it seems anything with a move over 100 moves slower and only moves just a bit like a math overflow? (may help to know that I am using a 1/128 driver and have 640 steps per mm, worked in this setup before changes but I am thinking overflow if the math is done differently, 640steps per mm *100 = 64000 (using 32 bit ints?)

repetier commented 8 years ago

Nonlinear moves are split in 16bit delta chunks. This split is done by computing planned time. So you need to check in eeprom you segements per second for travel and print. Normally values of 15 should work ok, making the value split into segments < 32000. If you get too slow you get a overflow and some part of the move might get neglected.

@vincent could also be your problem

jamesarm97 commented 8 years ago

Are these the ones you are talking about? It is the only ones in the configuration that mentions segments and show the values my config has:

define DELTA_SEGMENTS_PER_SECOND_PRINT 180 // Move accurate setting for print moves

define DELTA_SEGMENTS_PER_SECOND_MOVE 70 // Less accurate setting for other moves#define #define DELTASEGMENTS_PER_PRINTLINE 24

jamesarm97 commented 8 years ago

So I downloaded the latest where you test for min speeds and it worked better. I then looked at my eeprom and I guess because I don't have the delta flag set (because I am corexy) the defaults were at -1 so I changed the eeprom also. I did notice on long moves that it would pause for a second or more before actually moving like it was thinking or filling a buffer. I printed a test cube ok so I will try a large model next.

repetier commented 8 years ago

Yes these are the values I meant. -1 comes from having had a non delta version first. Latest update also fixed a problem with long z moves getting slow. Nonlinear systems have a longer wait period for prefilling, but nothing like a second. Segments per second need only be 15 for corexy systems. More is only wasing resources.

Salandora commented 8 years ago

Hey guys with this new feature you get a problem with autoleveling. I tried to implement it the last 2 days and wondered why I always got different Z values for the same spot (multiple G30 command). After a bit of testing and code reading I had the guess it could be the nonlinear part. So I disabled the fast corexyz flag and tested bow I get almost reproducable values (+-0.2 instead of +-5). I'm going to investigate thia problem further. A real simple solution could be to exclude the fast corexyz flag in the probing code.

repetier commented 8 years ago

No, switching between fast and slow is no option. These are completely different code parts and you compile only one. The real solution must be finding why you get so big differences.

One problem with nonlinear moves is that each subline can only have 64000 steps. And then it is also split into x segments per second. For z probing we use a small trick in that we detect pure z moves, which are split only into 64000 step big sublines so that the complete move should fit into one line. So when we hit z probe we only need to remove the reminder of the line. It is the same as we do for delta printers and there I never had a problem.

So I wonder what are the special condition in your case that it doe snot seem to work. So which processor do you use and how big are the buffers/subline count? What steps per mm in z direction and what is your starting height? Does it work if you measure from a lower point?

Salandora commented 8 years ago

I'm using an arduino due with RADDS shield and RAPS128 stepper drivers. My Z steps per mm are set to 5200. Starting height is at 15mm. Z probe height was around 8mm. Z bed distance 5mm. Probe speed was 3 mm/s. As Z probe I have now switched back to a pibot optical reflection endstop. The segments for ... settings were both at 15.

Today I managed to get the Z probe perfectly working with the old corexy implementation. So in the next few days I'll try to check what makes it go crazy in the fast implementation.

One more thing I forgot to mention. I do 3 repetitions per probe and sometimes the probe speed got extremly slowed down while the Z axis gets raised.

I try to make a video of it when I switched back to the fast implementation.

repetier commented 8 years ago

5200 might be the problem. With 200mm z height probe will go down 400mm*5200/43680 = 48 subsegments needed. 200mm height was now an assumption but you see the number of subsegments is quite high and is easily larger then your DELTASEGMENTS_PER_PRINTLINE = 15. You could try increasing it to 80, should be no problem with due. If it then works we know that this is the problem. My delta has 80 steps per mm and 90 DELTASEGMENTS_PER_PRINTLINE so I will never come in that range, so it might in deed be the problem.

Salandora commented 8 years ago

Alright, I tested it again with Segments for printline set to 80 and segments for travel set to 80.

I tested 4 times the same point with G30 this are the results:

Z-probe:9.63 X:90.00 Y:100.00 Z-probe:17.52 X:90.00 Y:100.00 Z-probe:14.14 X:90.00 Y:100.00 Z-probe:10.77 X:90.00 Y:100.00

After this testing I added some debug outputs and the informations are interesting:

First probe:

Recv: lastCorrection: 44200

Recv: StepsRemainingAtZHit: 2140850 Recv: currentPositionSteps Z: -2108600 Recv: currentPositionSteps Z: 32250 Recv: sum: 11950

Recv: StepsRemainingAtZHit: 2144792 Recv: currentPositionSteps Z: -2112750 Recv: currentPositionSteps Z: 32042 Recv: sum: 24108

Recv: StepsRemainingAtZHit: 2144623 Recv: currentPositionSteps Z: -2112958 Recv: currentPositionSteps Z: 31665 Recv: sum: 36643

Recv: distance: 8.75 Recv: Z-probe:8.75 X:90.00 Y:100.00

Second:

Recv: lastCorrection: 44200

Recv: StepsRemainingAtZHit: 2092599 Recv: currentPositionSteps Z: -2108600 Recv: currentPositionSteps Z: -16001 Recv: sum: 60201

Recv: StepsRemainingAtZHit: 2145116 Recv: currentPositionSteps Z: -2161001 Recv: currentPositionSteps Z: -15885 Recv: sum: 120286

Recv: StepsRemainingAtZHit: 2144691 Recv: currentPositionSteps Z: -2160885 Recv: currentPositionSteps Z: -16194 Recv: sum: 180680

Recv: distance: 17.98 Recv: Z-probe:17.98 X:90.00 Y:100.00

Third:

Recv: lastCorrection: 44200

Recv: StepsRemainingAtZHit: 2110505 Recv: currentPositionSteps Z: -2108600 Recv: currentPositionSteps Z: 1905 Recv: sum: 42295

Recv: StepsRemainingAtZHit: 2145086 Recv: currentPositionSteps Z: -2143095 Recv: currentPositionSteps Z: 1991 Recv: sum: 84504

Recv: StepsRemainingAtZHit: 2145063 Recv: currentPositionSteps Z: -2143009 Recv: currentPositionSteps Z: 2054 Recv: sum: 126650

Recv: distance: 14.52 Recv: Z-probe:14.52 X:90.00 Y:100.00

Changing the Segments for Travel/Printing dosn't change anything for me.

repetier commented 8 years ago

No not segments per second, you should change DELTASEGMENTS_PER_PRINTLINE 80 that is a different thing.

repetier commented 8 years ago

Other question. As they differ so much i assume that it does not go back the same distance. So are you measuring always after G28/G1 Zx or just G30 after G30 on new z position. Latter will add more unknowns. So it would be good to know if you get same results from definitely same height.

Salandora commented 8 years ago

Uhm damn yeah they are different sorry was somehow fixes to this 2 variables :-/

My normal routine for testing is: G28 G1 Z15 G1 X90 Y100 F25000 G30 G30 G30

With the slow implementation this produces nearly constant values.

repetier commented 8 years ago

Vincent remembered me that we had this error, but fixed it some time ago. Are you using the latest version where we fixed the z probing for core xy nonlinear? All 0.92.9 versions should do. If yes there is another issue.

Salandora commented 8 years ago

I used the configurator and downloaded the full firmware pack from there. M115 says I'm running on 0.92.9.

Increasing DELTASEGMENTS_PER_PRINTLINE didn't worked (yeah I double checked it is the right one this time :-))

What I noticed a few times now is after the probing the Z-Axis raises again, this raising is strange, it sometimes moves extremly fast and sometimes its slow, sometimes it moves 2-3mm(as configured) and sometimes 7-8 or more (can't really measure it because it is between the repetations)

AKEric commented 8 years ago

I just gave this a shot on my corexy RADDS/Due setup, running SD6128's set to 1/32 microstepping. Seems to print ok, but when it homes x/y, or when the toolhead first leaves origin to start the print it's super jerky: starts\stop\start\stop. Thoughts?

Also, I printed two 2cm calibration cubes: one with the 'old' style, and one with this. Their quality was indistinguishable. Remind me why I want this? :P