Strange layer offset on coreXY

[Phaedrux]

Can you post the results of M122 as well?

[DVD479]

thanks for the support, this is the result that is given by running the M122 command

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9K662-MG5T4-6JKDL-3SD6J-KSPGZ
Used output buffers: 3 of 24 (23 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 75072 of which 24 recycled
Never used RAM 15444, free system stack 184 words
Tasks: NETWORK(ready,14.2%,252) HEAT(delaying,0.0%,326) Move(notifyWait,0.1%,364) MAIN(running,85.7%,441) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:03:40 ago, cause: power up
Last software reset at 2021-11-27 17:08, reason: User, GCodes spinning, available RAM 15444, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 24.9, current 25.7, max 26.0
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, SG min/max not available
Driver 1: position 0, standstill, SG min/max not available
Driver 2: position 0, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-11-28 10:01:52
Cache data hit count 4294967295
Slowest loop: 4.16ms; fastest: 0.17ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 0.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 203.64ms; fastest: 0.09ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 1
WiFi firmware version 1.23
WiFi MAC address 48:3f:da:50:32:2c
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24520
WiFi IP address 192.168.137.115
WiFi signal strength -46dBm, mode none, reconnections 1, sleep mode modem
Clock register ffffffff
Socket states: 4 0 0 0 0 0 0 0

[rjenkinsgb]

You could try reducing the jerk limit as a test?

@dvd479 said in Strange layer offset on coreXY:

M566 X1500.00 Y1500.00 Z24.00 E120.00 ; set maximum instantaneous speed changes (mm/min)

Try 1000 or even 500 for X & Y temporarily, just on the offchance something is not keeping up when both drives suddenly use high power whilst the heaters & extruder are running?

Probably not the cause, but it's the only thing I can think of..

[DVD479]

thanks for the tip, i tried right now but it seems the change is minimal.

thanks anyway

[Spanners]

Seems to me that your currents to the stepper moters is too low which maybe causing missed steps ....
your settings--> M906 X300 Y300 Z300 E300 I30

I have a coreXY and my currents are set to 700 ma (duet 2 wifi with NEMA 17 17HS4401 steppers)

my settings --> M906 X700 Y700 Z700 E700 I30

[JoergS5]

@dvd479 your offsets are so regular, I would suspect that either microstepping is wrong or pulley teeth. Microstepping of external stepper needs DM542 to be set e.g. (please check table printed on the DM542) on-on-off-on of the switches SW5 to 8 (arrow shows where is on), and please check that you're using 20 teeth pulley, not other number (to get 200*16/40 = 80 M92 setting).

[DVD479]

I tried to check your suggestions but unfortunately I didn't get any particular changes.

for the pulleys I have checked now and they are 20 teeth so they shouldn't be the cause of the problem, and the drivers are also set to the correct sequence

thanks anyway

[JoergS5]

@dvd479 strange.

An additional idea is that the pulleys are sliding on the stepper shafts. You can check by marking with a felt tip pen over pulley and shaft.

And to be sure, you're using GT2, not HTD or other belts?

[DVD479]

I used 20 tooth gt2 pulleys, I checked the pulleys on the motors and I did not see any oscillations

thanks for the tips

[Stephen6309]

@dvd479 I use M906 X800 Y800 Z800 E800 I30 for the stepper currents on my CoreXY. I believe the 300 your using is not enough.

[rjenkinsgb]

@stephen6309 said in Strange layer offset on coreXY:

I use M906 X800 Y800 Z800 E800 I30 for the stepper currents on my CoreXY. I believe the 300 your using is not enough.

He says early on that he is using external stepper drivers.

Back to the question - another thing to try; reduce the maximum speed from 18000 down to eg. 10000 to be sure the drivers are not missing steps?

[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!