Question: How do I rerun a completed job?

[napter]

I don't see github discussions open so I hope it's ok if I ask here. Is there a way to start a completed job again?

What if a job was partially completed but I want to start it back at the beginning, is there a way to do that without requeuing all the prints?

Thanks!

[smartin015]

Thanks for reminding me Discussions is a thing :) just set it up.

If you wanted to print a fully completed job again, you could just increase the count of that job - but currently, there's no way to requeue a single, partially-completed job. This seems like a reasonable feature to have, although I'm a bit cautious about adding too many icons and cluttering the page.

WDYT about something in the Gmail style, where you can select one or more (or all, or a specific subset e.g. 'completed') and then perform one or more operations on them (for now, "delete" and "requeue")?

[napter]

That could work. However I have another idea - I think one thing that adds complexity and leads to the clutter you mentioned is that the job templates and the executing list are combined into a single interface. I think it would be cleaner if you didn't run the jobs, instead think of the jobs more like templates. When you run a job it adds the individual items to a print queue in a separate tab. The print queue is a flat list of print tasks (not a tree like the jobs are). So for example: I have a job that is set to execute twice and has three individual items in it that each print once. When I click add to queue six items are added to the flat print queue in the order they will print and the first begins printing.

This has a number of advantages:

• It is very clear where things are up to and what is coming up next since the queue is just a flat list of upcoming prints.
• Say you have a job to print 5 parts that make up an item. You may want to come back to it in the future. Since the job is a template you don't have to delete it, you can requeue it at any time.
• You can easily adjust the queue even while it is printing - adding or removing items. You can temporarily make changes (ie reprint one part of a job because it didn't come out right) without changing the job itself for future prints.
• Requeuing after success or failure is simple - clicking add to queue just adds the job to the bottom of the list.
• There is now a built in history of previous prints.

[smartin015]

I like the concept of separate tabs for jobs vs the queue - it goes a long way towards addressing #33, as you mention. In fact, the jobs you see on the CP tab are already stored as a flat (unrolled) queue of individual prints, so this wouldn't even require any changes to the backend.

However, there's a couple issues here to work out first:

• While your approach makes it easy to add new prints onto the end, it's not so easy to add something elsewhere (example: I have two jobs "A" and "B". I add "A" to the queue, but then realize I wanted to print "B" first. Do I have to blow away the queue to change the order?).
  • This also holds true for reordering whole jobs worth of print items, especially longer jobs with 10's or 100's of items.
• It's difficult to reduce the number of times a job is printed - for a job of X items repeated Y times, you'd have X*Y*number_of_job_instances interactions with the queue to remove them without any notion of bulk editing, whereas today you just change a single number in a text box.

One way to partially resolve this would be to have a pipeline, i.e.

1. User defines jobs in the "Jobs" tab
2. User drags and drops the defined jobs into a job list in the same tab, can order them and change their count etc.
   • Maybe they can also add individual prints from a job (becomes a new, ephemeral job of some kind with just that print in it)
3. User "submits" the ordered jobs, where they appear on the "Queue" tab.
4. Annotate the "Queue" tab to indicate which chunks of the queue belong to which jobs, and allow for bulk options such as "delete all in job", "delete all after this", etc.

Beyond this, I've been dabbling with distributed 3D printing which would enable many-to-many management of queues and printers (see #35). I've been treating jobs as the atomic unit which gets distributed to printers. There's nothing we've discussed so far which isn't compatible, but it's something I'm keeping in mind as we chat.

[smartin015]

Coming back around to this, I think I'm going to split the difference and have a mutable "job/layout" view similar to what's presented today, but also have a seaparate, linear, and immutable "queue" view that shows the order in which things are expected to print.