Greetings all!
I have a Creality CR-10s Pro and I have happened across a weird bug. When slicing with S3D, the filament runout sensor is ignored. However, when slicing with Cura, it magically works again. I have sliced a calibration cube in both and investigated the starting scripts of both but have been unable to find anything that would indicate why it doesn't work.
S3D Version 4.1.2
Cura 4 w/Creawesome Mod
I am also printing using Octoprint.
Thanks!
-
3DEnthusiast
- Posts: 9
- Joined: Sun Feb 18, 2018 8:41 am
Re: Filament Runout Sensor
The GCode Commands in the start script is only a part of all GCodes, which will be sent as an initialization to the printer.
I recommend to check the first part of both GCode Files.
You should be able to find the relevant difference, i.e. a GCode command which enables the Filament runout sensor in the cura file.
Then you can add this command to the S3D start script.
I recommend to check the first part of both GCode Files.
You should be able to find the relevant difference, i.e. a GCode command which enables the Filament runout sensor in the cura file.
Then you can add this command to the S3D start script.
-
swiftninja
- Posts: 1
- Joined: Tue Oct 06, 2020 6:36 pm
Re: Filament Runout Sensor
I am having the same issue.
While @Scotty's answer is a nice attempt, this is not the case. This is a failure to handle the response from Marlin when a filament runout is signaled when USB printing. And for giggles, I did in fact double check the gcode generated. The command M412 is used to control filament runout enable/disable, and there are no invocations of this command in the generated GCOde, and the feature is enabled in the firmware.
When USB communication is used for printing (as opposed to something like SD Card or USB Printing), Marlin sends a command back to the host to ask the HOST software to pause the print. So, yes - the filament runout bits exist and are handled in Marlin - 100% when using SD/Storage printing, but only the detection is handled when USB Printing. Marlin expects the host to be smart enough to pause the print. Which, in this case, it appears unable to do.
@Simplify3D: You need to handle this instruction from Marlin:
#define ACTION_ON_FILAMENT_RUNOUT "pause: filament_runout"
I too was surprised that Simplify3D Does not handle this. Would be real nice were it fixed.
TL;DR: Simplify3D Doesn't handle the "pause: filament_runout" response from firmware, and it should.
While @Scotty's answer is a nice attempt, this is not the case. This is a failure to handle the response from Marlin when a filament runout is signaled when USB printing. And for giggles, I did in fact double check the gcode generated. The command M412 is used to control filament runout enable/disable, and there are no invocations of this command in the generated GCOde, and the feature is enabled in the firmware.
When USB communication is used for printing (as opposed to something like SD Card or USB Printing), Marlin sends a command back to the host to ask the HOST software to pause the print. So, yes - the filament runout bits exist and are handled in Marlin - 100% when using SD/Storage printing, but only the detection is handled when USB Printing. Marlin expects the host to be smart enough to pause the print. Which, in this case, it appears unable to do.
@Simplify3D: You need to handle this instruction from Marlin:
#define ACTION_ON_FILAMENT_RUNOUT "pause: filament_runout"
I too was surprised that Simplify3D Does not handle this. Would be real nice were it fixed.
TL;DR: Simplify3D Doesn't handle the "pause: filament_runout" response from firmware, and it should.
