I have a strange problem, the printer, after pausing to change filament, always moves on the Y axis at the same rate, so I rule out a mechanical problem, has this happened to anyone else? I appreciate any help
I am having the exact same problem. All of my KE printers do this. I noticed that the Y-axis does a hard crash when going to the home position. I believe the Y-belt is then slipping and causing the issue. I am going to work on fixing this issue today.
There is no fix for this just yet. Creality needs to change their firmware so that PAUSE is 0,0 - not 0,225. There is about a 5mm belt slip when it crashes, so your y-axis gets confused. Sorry. We have to live with it for now…
My V3SE, V3KE and Ender 5 plus all do that crashing thing but at least the 5+ doesn’t do the shift thing.
Same issue here, most of my prints fail after a pause. Have you been able to solve this on your end?
I found that by enabling ssh and editing /usr/data/printer_data/config/gcode_macro.cfg to set the y_park value in the PAUSE macro to something like 150 fixes the problem (then reboot to ensure it is applied). Hopefully a firmware update can address this.
Is there any chance that you can elaborate on this? I have installed and enabled SSH server, but I can’t find it or the USR file that you mention.
I have now found installed and enabled the service openSSH server, but I don’t know what to do after that.
I presume you have got into the system? There are other good guides, e.g. on that step, e.g.
Note that things are case-sensitive. First try
grep 'set y_park = [0-9][0-9][0-9]' /usr/data/printer_data/config/gcode_macro.cfg
That should be 255 if you have the issue. You can either use “vi” to edit directly, or you can try the following to edit the file in-place
sed -i 's,set y_park = 255,set y_park = 150,' /usr/data/printer_data/config/gcode_macro.cfg
Rerun the grep to check it’s now 150
I tried it, but nothing changes. 50% of all pause/resume ends with over extruding and stringing.
One thing helps to 99% … If i see next layer (with new filament for instance) will fail (long string during traffic move) and the nozzle is OVER the print object, i hard switch off the printer, then switch on … And resuming the print wil result perfect.
After that i can print several objects with pause/resume… till (from hell) then it failes again
… that there is no solution, it goes not in my mind 
1 Like
Just for discussion, because I saw the comment that something might not work with the Resume Macro (unfortunately I don’t have the link right now):
in PAUSE Macro the z move to park position(?) will saved:
##### calculate save lift position #####
{% set max_z = printer.toolhead.axis_maximum.z|float %}
{% set act_z = printer.toolhead.position.z|float %}
{% if act_z < 48.0 %}
{% set z_safe = 50.0 - act_z %}
{% elif act_z < (max_z - 2.0) %}
{% set z_safe = 2.0 %}
{% else %}
{% set z_safe = max_z - act_z %}
{% endif %}
SET_GCODE_VARIABLE MACRO=PRINTER_PARAM VARIABLE=z_safe_pause VALUE={z_safe|float}
set as float, may be it could 37.6
but in Resume Macro it will read as int:
{% set z_resume_move = printer['gcode_macro PRINTER_PARAM'].z_safe_pause|int %}
{% if z_resume_move > 2 %}
{% set z_resume_move = z_resume_move - 2 %}
G91
G1 Z-{z_resume_move} F600
M400
{% endif %}
… so the toolhead will moved 37.0 and not moving 37.6 …different z-positions then result in different differences.
Or do i thinking wrong? 
But logically it is fundamentally wrong to mix float values and int values, isn’t it?
Second thing: the conditions for calculating in PAUSE… do they do the recalculation in RESUME?