The print management queue needs to be capable of handling the intake, storage, and querying of current and past print jobs with some architectural system.
Scope
This system should be capable of at the very least taking in the settings of the print job, any notes associated with it (such as quantity), and a file dropbox for storing and associating it with their Rutgers NetID. It should be capable of sending gCode to relevant printers (if this method is supported).
Architecture
A web service of some sort will ask the user to log in with their NetID, and view the progress on their print jobs.
- Past jobs should be rendered with a "Done" marker of some sort, future jobs with a "Queued" mark, and an estimate if possible. Ongoing jobs should use the print spooler to evaluate how long the job has remaining by the last gCode status display update.
When a job is eligible to be printed, the gCode is loaded into the spooler, mirrored after the OctoPrint architecture for hardware resources, which will dispatch new gCode commands, and on "OK" from the printer, also inserting status commands to the front of the queue as needed to receive information and update the web interface.
Web Interface
This is responsible for intake of new prints, correlating users with their print jobs, and offering a printerface to manage ongoing jobs (such as canceling, since the commands wouldn't be local to the printer to cancel.)
Potential Difficulties
The individual gCode commandsets offered by printers is far from unified, and may not work across printers. For this reason we'd need to be able to infer the destination printer type from the Project File or have the user select the printer? this may be moot given that the MVP may just be a digital tracking board for our ongoing prints.
Another difficult potentially exists in the hosting workflow, especially as billing is relevant, but that may not be at this point.
MVP
Takes files, stores them somehow.
keeps track of who has been billed or not / whose print jobs are done successfully / had to be reprinted.
The print management queue needs to be capable of handling the intake, storage, and querying of current and past print jobs with some architectural system.
Scope
This system should be capable of at the very least taking in the settings of the print job, any notes associated with it (such as quantity), and a file dropbox for storing and associating it with their Rutgers NetID. It should be capable of sending gCode to relevant printers (if this method is supported).
Architecture
A web service of some sort will ask the user to log in with their NetID, and view the progress on their print jobs.
When a job is eligible to be printed, the gCode is loaded into the spooler, mirrored after the OctoPrint architecture for hardware resources, which will dispatch new gCode commands, and on "OK" from the printer, also inserting status commands to the front of the queue as needed to receive information and update the web interface.
Web Interface
This is responsible for intake of new prints, correlating users with their print jobs, and offering a printerface to manage ongoing jobs (such as canceling, since the commands wouldn't be local to the printer to cancel.)
Potential Difficulties
The individual gCode commandsets offered by printers is far from unified, and may not work across printers. For this reason we'd need to be able to infer the destination printer type from the Project File or have the user select the printer? this may be moot given that the MVP may just be a digital tracking board for our ongoing prints.
Another difficult potentially exists in the hosting workflow, especially as billing is relevant, but that may not be at this point.
MVP
Takes files, stores them somehow.
keeps track of who has been billed or not / whose print jobs are done successfully / had to be reprinted.