Job queue & mainsail config

I just had a pretty ugly accident where using the job queue, one of the jobs automatically started before I removed the previous print. Obviously the extruder crashed into the previous print, breaking my inductive sensor's holder, and the fan horns, thankfully it was just those and I had printed replacements because I'm paranoid and I've had similar accidents with other printers. I'm trying to find out why this happened though, and as far as I can tell, all the config related to the job queue is mainsail's and it seems to be setup to sensible defaults that shouldn't auto-start a job. Can anyone think of any settings I may be missing that could cause this? I had it happen once before, but I managed to stop the previous one before it caused any damage. I just don't feel very confident using the job queue at all having seen this twice already.
7 Replies
miklschmidt
miklschmidt•2y ago
Never used that feature, i don't know how it works. It's unrelated to RatOS, so maybe try #klipper, or the mainsail discord or even the klipper discord. Ah.. https://moonraker.readthedocs.io/en/latest/configuration/#job_queue
load_on_startup: False
# When set to true the job queue will attempt to load the next
# pending job when Klipper reports as "Ready". If the queue has
# been paused it will automatically resume. Note that neither
# the job_transition_delay nor the job_transition_gcode are
# applied in this case. The default is False.
automatic_transition: False
# When set to True the queue will automatically transition to
# the next job in the queue after the current job is complete.
# This is useful for belt printers and other machines with the
# ability to automate clearing of the build area. When False
# the queue will be paused after each job is loaded, requiring
# that users manually resume to load the next print. The default
# is False.
job_transition_delay:
# The amount of time to delay after completion of a job before
# loading the next job on the queue. The default is no delay.
job_transition_gcode:
# A gcode to execute after the completion of a job before the next
# job is loaded. If a "job_transition_delay" has been configured
# this gcode will run after the delay. The default is no gcode.
load_on_startup: False
# When set to true the job queue will attempt to load the next
# pending job when Klipper reports as "Ready". If the queue has
# been paused it will automatically resume. Note that neither
# the job_transition_delay nor the job_transition_gcode are
# applied in this case. The default is False.
automatic_transition: False
# When set to True the queue will automatically transition to
# the next job in the queue after the current job is complete.
# This is useful for belt printers and other machines with the
# ability to automate clearing of the build area. When False
# the queue will be paused after each job is loaded, requiring
# that users manually resume to load the next print. The default
# is False.
job_transition_delay:
# The amount of time to delay after completion of a job before
# loading the next job on the queue. The default is no delay.
job_transition_gcode:
# A gcode to execute after the completion of a job before the next
# job is loaded. If a "job_transition_delay" has been configured
# this gcode will run after the delay. The default is no gcode.
I'm guessing those are quite relevant if you want to mess around with queuing
xenial-black
xenial-blackOP•2y ago
Yeah I saw those, but from what I can tell, ratos already has those same defaults, and I couldn't find anything overriding them. Yet, somehow, my printer did the "automatic_transition", causing damage. So I'm thinking that I'm missing something in the ratos config that is setting tat automatic_transition to true, but I don't see where. Either that or the moonraker queue is bugged 😂
miklschmidt
miklschmidt•2y ago
true RatOS doesn't even have a job_queue section
xenial-black
xenial-blackOP•2y ago
Is there a way to read the setting ratos/moonraker have in memory for that? I'd like to confirm that the automatic_transition is set to false, because it's the only thing I've seen on the docs that would seem to do what happened to me. If it is set to false, then I'd guess moonraker has a bug that is sometimes (not always) making it auto-start the next job.
miklschmidt
miklschmidt•2y ago
there's nothing short of the moonraker defaults and the config file (RatOS/moonraker.conf and your own moonraker.conf).
xenial-black
xenial-blackOP•2y ago
Yeah, those two are the only files I found with config for moonraker, and neither are changing moonraker's defaults, so I'm inclined to believe there's a bug with that feature 😫
miklschmidt
miklschmidt•2y ago
Not impossible
Want results from more Discord servers?
Add your server