There are a few thing that I think would help facilitate the use of the print queue process.
Lot of great suggestions here Ben. Thank you for providing them. Let me put in my $0.02 on some of them. Will be more of a $1.50 on a couple. I think I'll start in reverse order though.
7. We'll make it "Remove Job" and "Remove with Comment". I know there are members who just want to remove a number of jobs and won't want the extra click per job. (Click to remove, click to get past the pop-up in which to supply a comment.) Hence a separate remove w/comment. This has been added to our work queue (PC2-502). Related to this is adding a post-printing comment field to put in a note about the print. Would likely allow the print owner or queue managers to scribble in. (It would allow multiple notes.) Queue managers might indicate something like, "decimate the mesh -- the mesh had far too much resolution/fine detail that the printer's microcontroller got bogged down with the ga-zillion tiny segments and made lots of zits/pimples", or "print cooling fan inadequate on the printer; print 3 copies to give the fine, thin towers more time to cool between layers". The print owner may want to add notations like, "this version with the frob done slee-wise had less droop and thus printed fine without support".
6. Added to our work queue (PC2-506).
5. Very interesting idea. We need to think about it some more. Not so much as to whether we'd implement it, but how. It most definitely addresses a pain-point for any queue manager.
4. I guess we might have a printer setting which says to lock the start/end gcode. Then anyone who is not the printer manager/owner cannot touch it? But printer managers/owners can. This is probably best done in conjunction with 5 but need not be? There's an interesting loop hole when it isn't done in conjunction with 5: the saved per-user printer profiles can be used with any printer of the same make/model. So, if a student has access to a printer of type P which is not locked down this way, they can edit the profile changing the start or end gcode. Then save that as a custom profile. Then they can go to print on a "locked down" printer of type P, call up their saved, custom profile and voi la, there's their altered start/end gcode. Not do-able by most students, but would be a head scratcher for the teachers for which it does happen to.
3. This one is gnarly. We actually started to do this. However, first realize that there's no such thing as standard gcode. (The ANSI standards are just the overall syntax and, for some elements, the semantics.) Even within 3D printing, there are significant differences. For example, I have printers for which G10 is a retraction command (Marlin, Repetier, Smoothieware) and others for which G10 sets the tool offset, standby temp, and active temps (MakerBot, RepRapFirmware, MachineKit). Unfortunately, gcode files don't tell you the intended firmware target.... I literally cannot preview correctly the gcode from my farm of printers with a single viewer configuration. And G10 is just one of the several differences which impacts previewing.
So, we backed off on doing gcode previewing. Now that we actually slice in the cloud with a fixed slicer (Cura) which has a relatively fixed behavior, we may revisit this in the future but solely for that subset of printers for which we must slice in the cloud. No firm decisions have yet been made. I wouldn't hold my breath waiting for this one to happen but we do have a developer who is chomping at the bit to do this.
2. Much of this is on our to-do list. We are incredibly conscious to a fault to not disclose member's first and last names (should we know them). We only present the member's "display name" which they can set to whatever they choose. I'll talk with others about presenting a first/last name (if we have it) in the print jobs on the presumption that if X is letting you use their printer, you've agreed to let them know who you are. We don't have student ids though. How critical would the student id be to you if you had the member's first and last name (given name, family name)? [Warning: I do not check back here regularly. You can reach me at firstname.lastname@example.org]
1. I'm loathe to add this. Issue being that I've been around the block on this in the past. Some brief history: we (as in the DIY 3DP community) used to do this back in 2008/2009/2010. That was before "acceleration" was added to firmwares. "Acceleration" is the term commonly used and is intended to contrast the old firmwares in which the printer would just "instantaneously" jump to the commanded speed vs. new firmwares which would gradully ramp up the speed using controlled, linear acceleration. So back with these old "unaccelerated" firmwares, you seldom printed faster than 30mm/s. And Z motion had to be constrained to well below 5mm/s. Then, about late 2010, early 2011, everyone started adding the concept of gently ramping up the speed by controlling the rate of acceleration. Up until about late 2015, everything was limited to linear acceleration. (With linear acceleration there are still "jerks" -- jumps in the rate of change of the acceleration -- when the linear acceleration instantly changes from, say 1000 mm/s/s/, to 0. In late 2015, tinyg came out which controls the jerks as well.)
With "unaccelerated" firmwares, it was quite easy to compute the print time down to the second. At least one line of printers with LCD displays would show this info and give accurate to the second print times and remaining print times. (The firmware for the first 2 generations of MakerBots; I was the person responsible for that part of the code.) But when we added acceleration, it became a bit of a nightmare. Sure, a laptop/desktop could still do all the math. But the printers all had user-settable, onboard concepts of maximum axial speeds, maximum axial accelerations, maximum "jerks" or similar concepts. Add to that the fact that printers all did very approximate computations of the motions. And I don't mean round off errors. I mean short cuts they did owing to lack of memory and processor power. Shortcuts which often led to slight violations of the kinematical constraints. Net, net, the desktop/laptop computers not only needed to talk to the printer to get these user-controlled settings, but also had to understand the exact nature of the computational shortcuts taken. Without knowing all of that info, the desktop/laptop estimates were widely off: tens of minutes for a short print and hours for prints taking 6+ hours.
Net result was that instead of a few people complaining about a lack any time estimate, lots of people would complain that the time estimates were always wrong. Sigh. For the (by now) first four generations of MakerBot printers, we made available a desktop/laptop tool which could provide a down-to-the second estimate PROVIDED you configured it with the correct kinematic constraints (max speeds, max accelerations, etc.). Next to no one cared to use it. It really needed to be built into the slicers, but circa late 2012 people were using too many different slicers and no one set of slicer devs were keen to build it into theirs. (MakerBot, who never cared much about supporting anything but their current generation of printers, was by then too focused on their upcoming 5th gen printers and adding it for the first four generations wasn't of interest to them at that point.)
Add to this providing accurate estimates across different printer firmwares with different control algorithms, different default settings for kinematic parameters, different ways to get the settings from the printer, etc. Not really something we're keen on implementing.
You may be interested to read that 7 and 6 have been implemented. May be a few days before they appear on the production servers.
I forgot a few last thoughts -
6. Send to Back - You currently only have the ability to send an item to the front of the Queue. It would be great to send an item to the back of the Queue (for instance, if it will take 17 hours to print.)
7. Reason for removal - It would be nice if when you remove an item from the queue, you could give a reason why (improper scale, etc) - this reason should then be communicated back to the submitter.