rehome.g not found

Phaedrux

I remain of the idea that there is something in cura that creates some error

I don't see anything in the slicer start gcode that looks out of place.

;FLAVOR:RepRap
;TIME:1692
;Filament used: 1.00837m, 0m
;Layer height: 0.15
;MINX:-9.255
;MINY:-35.116
;MINZ:0.15
;MAXX:9.259
;MAXY:34.982
;MAXZ:14.4
;POSTPROCESSED
;Generated with Cura_SteamEngine mb-master-20200822
T0
M82 ;absolute extrusion mode
;Sliced at: Sun 06-09-2020 12:09:56
M82 ;absolute extrusion mode
M104 T0 S175
M190 S50
M109 S205
M82 ;absolute extrusion mode
T0
G21
G90
G92 E0
G1 X-50 Z2.5 E20 F1500
G92 E0
G1 X50  Z0.15 F1000
M82 ;absolute extrusion mode
M117 Printing...
;
M82 ;absolute extrusion mode
;T0                             ;switch to extruder 1
;G92 E0                      ;reset extruder distance
;G1 F2000 E93           ;load filament
;G92 E0                      ;reset extruder distance
;M104 S205
;

M83 ;relative extrusion mode
M83 ;relative extrusion mode
G10
;LAYER_COUNT:96
G92 E0
;LAYER:0
M107
M204 T1000
M566 X600 Y600
G0 F2400 X6.196 Y0.892 Z0.15
M204 P500
;TYPE:SKIRT
G11

Were you able to capture a video?

Marco Bona

@Phaedrux, I tried to remove the part of code you indicated but nothing has changed compared to before.
The video of the problem I encountered I published in a previous post. here is the link
https://www.youtube.com/watch?v=T0eO3SE1cW8&t=182s
Any changes made to start.g and files did not lead to any changes, result is always what you see in the video.

I publish files related to tool change:
tpre2.g tpost2.g tfree2.g

Phaedrux

The video link is set to private and I can't see it.

Marco Bona

@Phaedrux, sorry, it's now set to public, it should be visible

Phaedrux

So just to make sure I understand what I'm seeing. You're starting a print, and it goes to do it's homing process and it keeps detecting erroneous stall conditions and rehoming?

But you get no stall detections like this any other time?

Marco Bona

@Phaedrux , No, it occurs during the probing of the bed (G32) befoee printing. On other occasions it works fine, I mean if I run start.g from dwc as a test, not before printing. Is it possible that the problem arises from the lack of M204 in config.g?
In this case where does it get the acceleration values ?

droftarts

@Marco-Bona From your video, it looks like the homing is happening 3 times. Is that correct? Or does it just go on repeating?

Lack of M204 shouldn't matter, it will just be set to default. Send M204 on it's own to see the set values, eg mine is not set in config.g, reports

M204
Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0

Ian

Marco Bona

@Phaedrux, @droftarts, The homing works correctly, in the video starting from 40 seconds leadscrew leveling (M671) is performed and then probing for mesh compensation with G32 is performed. As you can see from the video, a stall is detected at 40 seconds even before starting to probe.
The really strange thing is that after adding M204 in config.g the frequency with which the wrong stall detection occurs has decreased.

BoA

If homing is correct, and stall is only in print, isn't that print uses faster travel speeds and acceleration than homing? From my experience this can trigger stall detection if sensitivity is too high (too low S param value).

Marco Bona

@BoA , This is correct, but I don't understand why if I run start.g from dwc, the commands are executed correctly while if start.g is called when starting the print motors keep stalling. I didn't find much explanation on setting the S value so I went a bit random (now it's set to 6) but occasionally when starting print an incorrect stall is detected.

BoA

@Marco-Bona Shortcut would be to disable stall detection action by setting R0 instead of R3 (sensorless homing still works)

On my printer I have 2 macros with different speed/acceleration limits - one for homing - more sensitive setting lower speeds, and second for normal print to avoid false stall detection.

Perhaps there are some commands in print gcode that change aceleration etc.

Marco Bona

@BoA ,I'm not using sensorless homing, I have normal optical sensors as limit switches, I use stall detection to prevent the motors from losing steps or the head colliding during printing.

BoA

@Marco-Bona OK then. I would just increase S level until no false stall detection occurs.
And just a stupid question - do You actually have rehome.g in sys folder ?

Marco Bona

@BoA , Sorry for the confusion, initially for wrong name, rehome.g was not found (there was a space after the g), then the problem became that an incorrect motor stall is detected. In all honesty I don't know what to feel anymore because I have inconsistent data.

BoA

Ok, What is Your current M915 configuration?

Marco Bona

@BoA , this is the one with which I found myself best

M915 X Y  T20000 S6 H51 F1 R3

BoA

I just tried to trigger stall detection on my printer. And it works ONLY when printing. In any other cases it allows motors to stall and do nothing.

That might be the reason why it is triggered only during print.

IMO You have too low H value.

Did You try formula from https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing ?

Marco Bona

@BoA , now it's clear. I got that value from 3D Printer Calc Toolbox, the formula should be same, although I have some doubts about actual current value (I set 2.24 A). Rated current is set on 2.8A