rehome.g not found
-
@Phaedrux, I tried to run command by command but I don't see anything strange. The machine behaves correctly and the rehome.g file is not invoked. I remain of the idea that there is something in cura that creates some error
-
@droftarts said in rehome.g not found:
; If the printer hasn't been homed, home it if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed G28
Can you test your start.g with this conditional section removed? As it is right now it will always home because the command before it turns off the V motor, so it will show as unhomed anyway.
T2 P0 ;
You also have a tool call in there. Can you post your tool files? Tpre tpost, etc
-
@Marco-Bona said in rehome.g not found:
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 G11Were you able to capture a video?
-
@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 -
The video link is set to private and I can't see it.
-
@Phaedrux, sorry, it's now set to public, it should be visible
-
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?
-
@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 ? -
@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.0Ian
-
@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. -
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).
-
@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.
-
@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.
-
@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.
-
@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 ? -
@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.
-
Ok, What is Your current M915 configuration?
-
@BoA , this is the one with which I found myself best
M915 X Y T20000 S6 H51 F1 R3 -
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 ?
-
@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
