Strange layer offset on coreXY

[whosrdaddy]

This is a mechanical problem, not an electronics problem.
Can we see pictures of your belt setup. I guess one or more belts paths are not perpendicular to X or Y motion...

[JoergS5]

@whosrdaddy that's a good point, and the best description I know about it is in https://drmrehorst.blogspot.com/2018/08/corexy-mechanism-layout-and-belt.html

[rjenkinsgb]

@whosrdaddy said in Strange layer offset on coreXY:

This is a mechanical problem, not an electronics problem.

The "cube" appears to be slanted, not just deformed scale-wise - or is it just the photo angle?

Any mechanical setup or steps per mm error would give x-y distortion, but not drift, surely?
A given X-Y point should always be the same, no matter how far off true position it is??

If there is no slant or layer drift, and only shape distortion, then scaling and mechanics are the likely cause.

[mrehorstdmd]

I would try modifying the step/dir/en timing parameters in the M569 statements. You may be operating right at the limits of the external hardware. Try increasing the values until they are well above the minimum specs in the driver manual. In my sand table with servomotors I use

M569 P5 S1 R0 T4.0:5.0:6.0:12.0 ; drive 5 reverse, lo enable, timing parameters for servomotors
M569 P6 S1 R0 T4.0:5.0:6.0:12.0 ; drive 6 reverse, lo enable, timing parameters for servomotors

These values allow the motors to hit their back-emf speed limit of 3k rpm.

Some photos of the printer might be useful...

[DVD479]

thanks everyone for the advice. at the moment I can't send the photo of the corexy logic used but I think the problem is not due to the positioning of the belts since I used a scheme similar to the voron 2.4. I had also tried to increase the delay times of the motors and also reduced the microsteps to reduce the data flow. I am attaching some photos to show the problem that I have honestly never encountered. I fear it is a software problem and not a mechanical one because as you can see from the photos keeping the same mechanical configuration, generating the gcode with CURA and slic3r I got a different result. do you think it could be a problem of the slicer with the corexy logic?

[JoergS5]

@dvd479 said in Strange layer offset on coreXY:

generating the gcode with CURA and slic3r I got a different result.

you can analyze the two g-codes for differences, they are simple text files. Probably at the beginning is something different. To help you look into it, please publish it.

The corexy logic cannot be the reason, because g-code files contain cartesian coordinates and the firmware translates it into the specific kinematics like corexy.

[DVD479]

slic3rCube.gcode CuraCube.gcode

[DVD479]

these are the two files, however, I don't know if the engine of the two slicers behave in an equivalent way, giving similar Cartesian coordinates as values.

I wanted to hear your opinion regarding a doubt, in your opinion it is possible that in a Gcode file a certain coordinate with the information for XYE is repeated for each layer or it is not probable as a repetition

[JoergS5]

This post is deleted!

[JoergS5]

@dvd479 I am wondering why your printout is so height, when it should be a cube. Either XY print much shorter than calculated or your Z layer heights are heigher than 20 mm. Can you please tell me the dimensions of the printouts?

Do you have any gears at X, Y or Z steppers or Nema steppers with 400 instead of 200 steps?

[JoergS5]

@dvd479 Something is wrong with your config.g:

M669 K1 ; switch to CoreXY mode
M569 P5 T2.5:2.5:5:5 S0 ; physical drive 0 goes backwards
M569 P6 T2.5:2.5:5:5 S1 ; physical drive 1 goes backwards
M569 P2 S0 ; physical drive 2 goes backwards
M569 P3 S1 ; physical drive 3 goes forwards
M584 X6 Y5 Z7 E8 ; set drive mapping

Z7 and E8 have no mapping to steppers, there are no M569 definitions.

M350 Z2 with M92 Z80 is also a strange combination, what do you use for Z?

[mrehorstdmd]

Photos of the printer...?

[DVD479]

the stl file represents a cube with 20mm side, for the z I had used M350 Z2 combined with M92 Z80 as I set the driver at 400 microstep and having a screw with 5mm pitch doing the calculation should result 400/5 = 80 which it should be the microsteps needed by the Z to move 1mm,
the strange thing is that the cube is 20mm high and the sides are also 20mm the difference is in the printing angle which with slic3r is much lower while with CURA the deviation is greater

thanks for the tips

[JoergS5]

your print bed could also move,resulting in this shift. Or while printing the object is moved. Images would definitely help now to think about possible reasons.

About slic3r versus Cura, the g-code files have some different settings like bed temperature and filament temperature are different, this can be a reason. Thermal expansion of the bed e.g.

[A Former User]

@joergs5

So I have also layer shifts BUT ONLY when I´m switching tools.
May we have a similar problem.....
I slice with cura.

Richard

[JoergS5]

@gruna-studio please talk with @DVD479 , he has the problem.

[A Former User]

@dvd479 So I have also layer shifts BUT ONLY when I´m switching tools.
May we have a similar problem.....
I slice with cura.

Richard

Any news?
I´m also frustrated about the offset.

[deckingman]

@dvd479 At what angle is the part sloping with respect to the build plate? By that I means, does it slope front to back, left to right, or at 45 degrees to X and Y? A picture of the machine with the completed part on the build plate would be a great help.

[Phaedrux]

@mrehorstdmd said in Strange layer offset on coreXY:

I would try modifying the step/dir/en timing parameters in the M569 statements. You may be operating right at the limits or the external hardware. Try increasing the values until they are well above the minimum specs in the driver manual. In my sand table with servomotors I use

M569 P5 S1 R0 T4.0:5.0:6.0:12.0 ; drive 5 reverse, lo enable, timing parameters for servomotors
M569 P6 S1 R0 T4.0:5.0:6.0:12.0 ; drive 6 reverse, lo enable, timing parameters for servomotors

These values allow the motors to hit their back-emf speed limit of 3k rpm.

Some photos of the printer might be useful...

@DVD479 Have you taken a look at this yet?

[DVD479]

first of all I want to thank all those who have given me useful advice to solve my problem. in conclusion it seems that the problem is solved using Slic3r and going to set the value of XY SIZE COMPENSATION after several attempts and in this way I was able to solve the positioning error and the 20mm cube was printed correctly. I just have to test if this procedure works with other more complex files but I think it can work.