rehome.g not found
-
I suspect that part of the problem may be in stall detection not working for motors on the expansion boards.
-
@Phaedrux , you are right for the confusion of the files. If I remember correctly I had done end.g because I hadn't noticed that cancel.g was missing.
I'll arrange to fix -
@Phaedrux, even if the X and Y motors are on the main board?
-
@Marco-Bona That's why I suspected a stall being detected on V or something and maybe related to the high steps per mm, but I'm not sure.
-
@Phaedrux, here are results:
M98 P"config.g" Warning: M307: Heater 3 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365CM584 Driver assignments: X0.0 Y0.1 Z0.2:0.3 U1.0 V1.1 W0.3 E0.4:0.5, 3 axes visibleM350 Microstepping - X:16(on), Y:16(on), Z:16(on), U:16(on), V:16(on), W:16(on), E:32(on):32(on)M92 Steps/mm: X: 80.000, Y: 80.000, Z: 802.005, U: 37.670, V: 5245.900, W: 802.005, E: 806.000:806.000M906 Motor current (mA) - X:2240, Y:2240, Z:2100, U:1800, V:1500, W:2100, E:560:560, idle factor 30%would seem all correct
-
With 3.2 beta now released you may want to try that out to see if the behaviour remains.
-
@Phaedrux said in rehome.g not found:
With 3.2 beta now released you may want to try that out to see if the behaviour remains.
I tried to make a print. The strange behavior of stall remains, however, after fixing name of rehome.g the error occurs less frequently. Part of problem I think was caused by the lack of file. I tried to insert M204 P500 T1000 and M566 X600 Y600 in start.g and I fixed files you told me but nothing changed, motors stalled anyway during start.g execution.
-
@Phaedrux, I repeat, this behavior only happens when you are running a printout
-
@Phaedrux said in rehome.g not found:
What happens if you step through the start.g manually command by command?
I'd still like to know how far it gets before it stalls.
Perhaps post a video so we can see exactly what's happening.
At this point we can't see anything obvious so we need to narrow it down.
-
@Phaedrux, sending the video link while I start a printout. As you can see it is practically impossible to work this way. When I run M98 P-"start.g" from the DWC console, machine is functioning correctly, no rehome.g is performed when running the command.
https://www.youtube.com/watch?v=T0eO3SE1cW8&t=182s
"What happens if you step through the start.g manually command by command?"
You mean some kind of single block? I ask why I don't know, how do I execute every single command?
-
@Marco-Bona said in rehome.g not found:
how do I execute every single command?
Copy each line and paste it into the gcode console and execute them one at a time.
-
@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
