WO2018001480A1

WO2018001480A1 - Job recovery information in print processing

Info

Publication number: WO2018001480A1
Application number: PCT/EP2016/065215
Authority: WO
Inventors: Roger TARRES; Sergio Gonzalez; Jordi GONZALEZ ROGEL
Original assignee: Hewlett Packard Development Company, Lp
Priority date: 2016-06-29
Filing date: 2016-06-29
Publication date: 2018-01-04

Abstract

A print processing device may include an input to obtain data describing a print job; a processing section having a memory, the processing section to generate at least one intermediate file based on the obtained data, and to generate print-ready content based on the at least one intermediate file; an output to output the print-ready content for printing by a printer; and a job recovery section to store recovery information in non-volatile storage in response to generation of the at least one intermediate file, the recovery information describing contents of the memory relating to the at least one intermediate file.

Description

Job Recovery Information in Print Processing BACKGROUND

[0001] In printing devices a print job received by the device may be processed before the physical printing may begin. In some cases, the processing prior to beginning printing may be time consuming. Devices for 3D printing, or additive manufacturing, are examples of printing devices that may involve processing large amounts of data, which may result in lengthy processing of a received print job before physical printing may begin.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Examples are further described hereinafter with reference to the accompanying drawings, in which:

Figure 1 illustrates an example of a print processing device.

Figure 2 illustrates an example of processing stages and intermediate file generation. Figure 3 is a UML diagram illustrating an example of information stored in a memory during pre-print processing.

Figure 4 illustrates an example of pre-print processing, indicating storage of recovery information to non-volatile storage.

Figure 5 illustrates an example of writing recovery information 165d during rendering. Figure 6 illustrates an example of a restore process in response to an interruption.

Figure 7 illustrates an example method for pre-print processing of a print job.

Figure 8 illustrates an example of a method 800 of recovery from an interruption during pre-print processing.

Figure 9 illustrates an example of a physical printing process in 3D printing.

DETAILED DESCRIPTION

[0003] Some data formats for print jobs may be generic, and not suitable for input to low- level printer hardware. Accordingly, on receipt of the print job by a printer, and prior to the physical printing operation beginning, the printer may process the print job into a format suitable for interpretation by the print engine; this processing is referred to herein as pre-print processing. The pre-print processing of the print job may be time consuming, and this is particularly true in the case of 3D printing. The term 3D printing is used herein to describe any of various techniques that produce a three-dimensional (3D) object from a digital

representation. This includes techniques that may be referred to as 3D printing, additive manufacturing, etc. in which a three-dimensional object is synthesized by forming successive layers of the object under computer control. 3D printing techniques include, for example, fused deposition modeling, direct ink writing (or robocasting), stereolithography, powder bed and inkjet head 3D printing, electron-beam melting, selective laser melting, selective heat sintering, selective laser sintering, direct metal laser sintering, laminated object manufacturing, directed energy deposition, and electron beam freeform fabrication. In some examples a print engine may print a 3D job by forming, layer by layer, the parts of the job in a build bed.

[0004] Examples herein are mainly described in relation to 3D printing, but are generally applicable to other printing processes (e.g. 2D printing), and the devices and methods described herein are not limited to 3D printing.

[0005] Figure 1 illustrates an example of a print processing device 100 according to the present disclosure. The print processing device 100 is arranged to receive or obtain a print job 1 10 at an input 1 15 and output print-ready content 120 from output 125. Print-ready content may describe content or data in a format suitable for interpretation by the print engine, or information suitable for use by low-level printer hardware. In some examples the print-ready content may be a 3D compressed raster representation of a model to be printed. In this case, at print time slices of the 3D compressed raster representation may be taken at regular heights to provide 2D raster images for printing each layer.

[0006] The input 1 10 and output 125 may be communication ports of the processing device 100. In some examples the input 1 10 and/or output 120 may include a bus (e.g. a parallel or serial bus) for communication between the print processing device 100 and other components. In some examples, the input 1 10 and/or output 120 may be represented by a storage device (such as non-volatile storage 150) or register that is accessible by the print processing device 100. In some examples, the input and/or output may be represented by a communication path allowing writing to and/or reading from the storage device or register accessible by the print processing device 100. In some examples, an input and/or output may be a communication path between a printing device that includes the print processing device 100 and a device external to the printing device (such as a client device, for example). Generally, the input 1 10 and/or output 120 may represent physical and/or logical entities for communication between the print processing device 100 and devices external to the print processing device 100.

[0007] The print job may be in any suitable format. For example, the print job may be, or may include, a 3MF file. The 3MF (3D Manufacturing Format) file format is an OPC (Open Packaging Conventions) based format aimed to send full-fidelity 3D models from producing applications to 3D printers, platforms and services. As an OPC based format, it is based on XML files packed in a ZIP package structure following a defined structure.

[0008] The print processing device 100 includes a print processing section 130 for processing the print job 1 10 to produce the print-ready content 120. The processing section includes volatile memory 140 that may be used to temporarily store information during the processing of the print job 1 10. During processing of the print job 1 10 the processing section may generate one or more intermediate files 155 that are written to non-volatile storage 150.

[0009] The print processing device also includes a job recovery section 160 to facilitate recovery of interrupted jobs. The job recovery section 160 is arranged to store to non-volatile storage 150 recovery information 165 describing contents of the volatile memory 140 relating to an intermediate file 155 in response to the generation of the intermediate file 155.

[0010] According to this arrangement, recovery information 165 may be suitable for making the intermediate file 155 usable. In the event of an interruption in printing that results in the contents of the volatile memory 140 becoming unusable (e.g. being lost or corrupted), the recovery information 165 stored to the non-volatile storage 150 may be provided to the processing section 130 and/or volatile memory 140, such that the processing section 130 may make use of the intermediate file 155 generated prior to the interruption, without needing to repeat the processing completed prior to the interruption in order to generate the intermediate file 155. If recovery information 165 were not available from the non-volatile storage 150, repetition of all of the processing from the submission of the print job may be unavoidable.

[0011] Herein, the term interruption is used to mean an event that results in some or all of the contents of the volatile memory 140 becoming unusable. This may be due to an unexpected loss of power, a crash requiring a reboot of the print processing device 100, an unrecoverable error, an shutdown, etc. Herein, the memory 140 is described as volatile memory, such that the contents of the memory may become lost or unusable if power to the memory is interrupted. The current disclosure may also be applied to a print processing device 100 in which memory 140 is a non-volatile memory. The contents of a non-volatile memory may become lost or unusable for various reasons, such as power surges or signal noise.

[0012] According to some examples the print processing device 100 may be incorporated in a printer. In some examples some or all elements of the print processing device may be implemented in software, hardware or a combination of software and hardware.

[0013] The volatile memory may include dynamic random-access memory, static random- access memory, etc. Non-volatile storage may include a magnetic storage device (such as a hard disk drive), ferroelectric RAM, flash memory, magnetoresistive RAM, etc. The non-volatile storage 150 is illustrated as being included in the print processing device 100 in Figure 1 , but may be provided externally to the print processing device 100. The non-volatile storage 150 may be included in, or external to, a printer that incorporates the print processing device 100. [0014] In Figure 1 the intermediate file 155 and the recovery information 165 are illustrated as being stored to the same non-volatile storage, but according to some examples, the intermediate file 155 and the recovery information 165 may be stored to separate non-volatile storage.

[0015] Figure 2 illustrates an example of processing 200 by processing section 130.

According to this example, the print processing device 100 is incorporated in a 3D print processing device and the print job 1 10 is a 3D print job.

[0016] The job is created at 210, in response to an input indicating an incoming print job. The processing section 130 performs initial setup in preparation for receiving and carrying out the print job. In some examples the initial setup at job creation may include processing section 130 checking that the requested build parameters can be fulfilled by the printer. For example, that the material and the printmode are supported by the printer. The initial setup may include writing one or more intermediate files 155a to non-volatile storage. In some examples, no intermediate files 155a are written at this stage. In some examples intermediate file 155a may include a preview for showing in user interface (Ul) previews of the print job.

[0017] It is to be noted that the terms job and print job may be used interchangeably in the field of printing to describe (from a user's perspective) a user sending instructions to carry out printing, and (from a printer's perspective) the temporary entity for storing and tracking the execution of received instructions. Herein the former is generally referred to as a "print job" while the latter is generally referred to as a "job".

[0018] At 220 the print job is uploaded to the print processing device 100, and may be stored in non-volatile storage 150, for example. The print job may be uploaded as a file in 3MF format, for example. When the uploading of the print job is completed, the uploaded print job stored on non-volatile storage 150 may be considered an intermediate file 155b.

[0019] At 230 the processing section 130 waits to parse the uploaded file. The wait at 230 may be to allow the file to complete uploading, or may be to allow an earlier or higher priority job to finish, for example. In some examples the wait 230 may be omitted.

[0020] At 240 the uploaded file is parsed in order to extract the instructions in the uploaded file in a format that is usable in the subsequent processing stages. In some examples, parsing is the process of validating the input file and extracting and interpreting the content. Parsing may output the content into an internal format usable by a next stage of the processing. In some examples the output from the parser may use same graphical primitives as the input to the parser, such as lines or triangles. In some examples the input primitives may be decomposed into more simple graphical primitives, such as circles, sets of closed lines, or polygons. For example, a sphere may be decomposed into a set of triangles defining the 3D surface approximating the sphere.

[0021] One or more intermediate files 155c may be generated as a result of the parsing and these may be stored to non-volatile memory. As a result of the parsing, the information parsed from the uploaded file may held in volatile memory. This information may include, for example, identification of the file parsed, a bounding volume (a bounding volume of a set of objects is a closed volume that contains the union of the objects in a set), a reference to one or more relevant files stored in non-volatile memory, a reference to the 3D model, transformations to apply, etc. In some examples, the volatile memory 140 may also include tracking information, such as status, results, timestamps, etc. During, or after the parsing, a digested data file (or digested intermediate file), describing the result of the parsing and including data for use in a subsequent stage of processing, may be stored to non-volatile storage. The digested data file may be an example of an intermediate file 155c. In some examples the digested date file may be in VTK (Visualization Toolkit) format, which defines a file format for storing content describing 3D objects.

[0022] At 250 the processing section 130 waits to process (render) the data that results from the parsing 240 (e.g. as stored the digested data file). The wait 250 may be in order to allow another job to be processed, for example. In some examples the wait 250 may be omitted.

[0023] At 260 the data resulting from the parsing is rendered. This may involve rasterizing the data resulting from the parsing to generate an output that is usable by a print engine. This process 200 may generate one or more files to be stored in non-volatile storage 150, these files may be examples of intermediate files 155d. The processing section 130 may include a renderer to perform the rendering. The renderer may be include software, hardware or both.

[0024] When the rendering process 260 has been completed, the print job has been processed and the resulting output is usable by the print engine. In some examples, the output from rendering process 260 is or includes the print-ready content. In some examples the output to the rendering may be a raster representation of the model. For 3D printing this may be a 3D raster. In some examples, the 3D raster may use an octree representation to store the 3D raster in a compact manner. An octree is a data structure in which each internal node has exactly eight children. Octrees may be used to partition three-dimensional space by recursively subdividing into eight octants, for example.

[0025] Arrows to 280 in Figure 2 illustrate when intermediate files 155 may be generated according to some examples. In some examples there may be additional or fewer points at which intermediate files 155 may be generated. Some examples may include additional or fewer stages of processing. For example, in some arrangements a print job 1 10 having compressed information may be decompressed in preparation for subsequent processing.

[0026] Figure 3 is a UML diagram illustrating an example of information stored in the volatile memory. Figure 3 illustrates a data structure that may be stored for each job in the volatile memory 140. The print job is represented by a Build3D class 300 that contains one or more Build3Dltems 310. Build3D 300 is the job that encapsulates the content to print and has instructions (print ticket) on how to print it. Each Build3Dltem 310 includes one or more Build3DltemNodes 320, and is associated with the file to be printed (e.g. a 3MF file). Each Build3DltemNode 320 has a reference to a Model3D 330. Build3DltemNode 330 may be an element of a tree of nodes (e.g. as defined in 3MF). In some examples the Build3DltemNode 330 may include a part which is a leaf of the tree of nodes, and an assembly (not shown for simplicity), containing a subtree of Build3DltemNodes. For simplicity, one level is shown in Figure 3. Each Model3D may reference one or more files (e.g. raster files) stored in the nonvolatile storage as a result of the rendering 260. This is a hierarchical representation of the print job, with each Model3D 330 having a geometrical description of the part to print, referred to as a 3D model. Each Model3D 330 may be referenced by more than one

Build3DltemNodes 320. Where multiple Build3DltemNodes 320 refer to the same Model3D 330, each of those Build3DltemNodes 320 replicates the 3D model associated with that Model3D 330. Each reference to a Model3D 330 in a Build3DltemNode 320 may apply a, possibly different, transformation to the 3D model. For example, transformations may include different translations to avoid overlap of the resulting parts. Other transformations may be included, such as rotations and/or scaling, and multiple elemental transformations may be combined. During rendering of a Build3DltemNode, a transformation is applied to the

Model3D representation and an intermediate 3D representation of the part is produced. The 3D representation may be a 3D raster file. The Model3D 330 may be a 3D description of a part, and may be in the form of 3D vector graphics (meshes, slices, etc.) Accordingly, each Build3DltemNode 320 may instantiate one or more of the models, one or more times each, in the same or different proportions or orientations.

[0027] According to some examples, Figure 3 may represent the state of recovery information stored in the volatile memory when the parsing 240 has been completed. In this state the files (e.g. raster files) representing the respective parts have not been created, and so the Model3D information is incomplete when the parsing 240 has finished, and the Model3D information is included as it is created in the rendering process.

[0028] According to some examples, the status of the job may be stored as recovery information 165 each time any of the elements of Figure 3 (e.g. nodes, items, etc.) have been successfully processed. [0029] Figure 4 illustrates an example of the processing of Figure 2, with points at which recovery information 165 is stored to non-volatile storage 150 by the job recovery section 160 being indicated by synch 410a-e. Storage of recovery information 165 may be considered to produce a synchronization point, since the volatile memory 140 and recovery information 165 are synchronized at that point. Storage of recovery information 165 may also be considered to produce a restore point, since the recovery information 165 may provide sufficient information to restore/resume the processing at that point, by restoring that information to the volatile memory 140. Restoring/storing the recovery information 165 from the non-volatile storage 150 to the volatile memory 140 may include executing a routine to read the recovery information 165 stored in the non-volatile storage 150 and, using the volatile memory 140, continuing the pre-print processing of the print job based on the recovery information 165. In some examples restoring/storing the recovery information 165 from the non-volatile storage 150 to the volatile memory 140 includes creating in the volatile memory 140 the same or similar memory structures that were present at a point prior to an interruption (e.g. corresponding to a point at which the most recent recovery information 165 was stored).

[0030] At 405 the processing section 130 creates a job (which may alternatively be referred to as a build in 3D printing) 405 as part of creating the job 210. When the job creation is completed, the job recovery section 160 may write 410a recovery information 165a to nonvolatile storage 150. This recovery information 165a creates a trace that the job submission was attempted. The recovery information 165a may include a database for population in subsequent stages of the processing. In some examples, creating the job may cause an intermediate file 155a to be generated on non-volatile storage 150, and the recovery information 165a may be written to non-volatile storage in response to the generation of that intermediate file 155a. In some examples recovery information 165a may be written in response to creation of the job, whether or not intermediate file 155a is written or to be written at this stage. In some examples no recovery information 165a is written at this stage. If an interruption occurs prior to the recovery information 165a being written, the print job would have to be restarted from the beginning, which does not involve a significant amount of repeated processing in most cases. If an interruption occurs following the recovery information 165a being written, the recovery information 165a may be restored (stored) to the volatile memory 140, enabling the processing to continue from the point at which the recovery information 165a was written to the non-volatile storage 150.

[0031] In some examples, recovery information 165a includes information from the job, such as a job ID, a ticket containing instructions on how to print the job and/or material (e.g. a material powder from which the part is to be made) to be used in printing. In some examples the instructions may include information on how to lay a fusing agent (for melting a powder to form the printed part) and/or a detailing agent (to smooth the printed shape). In some examples the instructions may include information on how cooling is to be performed after the part is printed (e.g. active or passive cooling).

[0032] In some examples, no intermediate file 155a is written, and the print processing device may be unable to automatically restart the upload of the print job. In some such examples, the recovery information may log and/or report that the job failed, but the user may have to resubmit the print job as a new job in order for the job to proceed. Accordingly, in some examples the recovery information may not, itself, enable an actual recovery of the job in every case. It is expected that the processing up to creation of the job will be minor in most examples, such that the repeated processing would not normally be significant.

[0033] The process of transferring data to the printer is referred to herein as an upload, viewing the file transfer from the user, or client device's, perspective. This could also be viewed as a download of data form the printer's perspective.

[0034] At 220 the print job is uploaded to the print processing device 100, and in response to completion 245 of the uploading (e.g. the completion of writing the intermediate file 155b corresponding with the uploaded file), the job recovery section 160 may write recovery information 165b to the non-volatile storage 150. This recovery information 165b may link the created job with the uploaded print job. If the print job is interrupted before this recovery information 165b is written, the process would be restarted using the recovery information 165a stored when the job is created 407. If the recovery information 165b has been written, the process may be restarted from the point at which the recovery information 165 was written, that is, re-upload the print job may be avoided as the upload was completed and the information to make the uploaded file usable is preserved in the recovery information 165b; this recovery information 165b may be restored or rewritten to the volatile memory 140.

[0035] In some examples, job recovery information 165b may include a path to the file in non-volatile storage 150, indicating where the file is stored. In some examples the recovery information 165b may also include one or more of an identifier, a status (e.g. waiting to parse), timestamps (e.g. start and/or end of uploading), uploading duration, etc.

[0036] According to some examples, a client application may submit a print job to the printer and in response receive from the printer a URL to the printer's non-volatile storage 150, indicating a location to store the content file(s) for the print job. The client application may then copy the file(s) describing the object to be printed (e.g. 3MF files) to that URL. According to some examples, the uploading may be performed using http web services.

[0037] According to some examples, the uploading could be performed via the Internet, a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a LAN (Local Area Network), etc. According to some examples, the uploading could be performed from an eternal storage device via, e.g. a USB port, FireWire port, eSATA port, etc. of the printer.

[0038] According to some examples, the uploading may be performed prior to creation of the print job. For example, where the file(s) describing the object to be printed are uploaded to the printer independently of a print job being initiated (e.g. without an instruction from a user to begin printing.) A user may subsequently initiate the printing by sending or instructing a print job referring to the previously uploaded file(s).

[0039] According to some examples the uploading may be omitted. For example, an application for preparing the file(s) describing the object to be printed may generate the file(s) directly in non-volatile storage 150 accessible to the print processing device 150. For example, print processing deice 100 may be provided within a device that also includes the application for preparing the file(s) describing the object to be printed.

[0040] At 240 the uploaded print job is parsed, and in response to completion 445 of the parsing, recovery information 165c may be written to the non-volatile storage 150. Completion 445 of the parsing 240 may result in a digested data file being written to non-volatile storage 150 as an intermediate file 155c, and the recovery information 165c may be written in response to the intermediate file 155c being written. The recovery information 165c may include the information illustrated in Figure 3. In some examples, the recovery information 165c may be in the form of a database. In some examples, recovery information 165c populates a previously created database. In some examples the recovery information 165c may include one or more of identification of the file parsed, a bounding box, a reference to one or more relevant files stored in non-volatile memory, a reference to the 3D model,

transformations to apply, etc. In some examples, the recovery information 165c may also include tracking information, such as status, results, timestamps, etc.

[0041] If the print job is interrupted before this recovery information 165c is written, the process may be restarted using the most recent recovery information (e.g. recovery information 165b stored when the job upload is completed 425), and the parsing may be restarted from the beginning. If the recovery information 165c has been written, the process may be restarted from the point at which the recovery information was written, the intermediate file 155c generated in the parsing may be used and the parsing 240 need not be repeated. In this case, the information to make the data resulting from the parsing in the intermediate file 155c usable is preserved in the recovery information 165c, and this information 165c may be restored to the volatile memory 140 following a restart/reboot of the device.

[0042] At 260 the data resulting from the parsing is rendered. Recovery information 165d may be written at one or more times during the rendering process 260. If an interruption occurs during the rendering 260, the process may be restarted from the point at which the most recent recovery information 165d was written. In some examples, the data resulting from the parsing may describe a plurality of elements for producing the object to be printed, and recovery information may be written in response to completion of rendering one or more of these elements (e.g. in response to completion of each element). In some examples the data resulting from the parsing may describe a hierarchy, e.g. as shown in Figure 3, and the recovery information 165d may written in response to completion of rendering of an element of the hierarchy. In some examples, recovery information may be written in response to completion of rendering a Build3DltemNode 320. In some examples recovery information may be written in response to completion of rendering a part.

[0043] In some examples, rendering 260 includes generating one or more intermediate files 155d, and the recovery information 165d may be written in response to completion of an intermediate file, or in response to completion of each of one or more of the intermediate files 155d.

[0044] If the print job is interrupted before any of the recovery information 165d is written, the process may be restarted using the recovery information 165c stored when the parsing is completed 445. If recovery information 165d has been written, the process may be restarted from the point at which the recovery information was written. In this case, it may be possible to avoid repeating the rendering performed prior to the writing of the recovery information 165d, as any associated intermediate files 155d are present on the non-volatile storage 150, and the information to make these intermediate files 155d usable is preserved in the recovery information 165d, such that this information 165d may be restored to the volatile memory 140 and the processing may continue from the point at which the most recent recovery information was stored to the non-volatile storage 150.

[0045] In some examples, rendering may be performed in parallel, which may reduce the time requiring to complete the rendering process and/or make more efficient usage of computing resources. For example, two or more Build3DltemNodes may be rendered simultaneously.

[0046] At 270 the processing has been completed and print-ready content 120 has been produced from the input print job 1 10. In some examples recovery information 165e may be written to non-volatile storage 150 by the recovery section 160. In some examples, the recovery information 165e may be written to non-volatile storage 150 in response to an intermediate file being written.

[0047] In some examples an intermediate file 165d may be written at the end of the rendering process 260 and corresponding recovery information 165d may be written. Where this completes the processing, recovery information 165e may not be written according to some arrangements. For example, the most recent recovery information 165d may be sufficient to restart the processing at 270, without recovery information 165e being written. [0048] If the print job is interrupted before this recovery information 165e is written, the process may be restarted using the most recent recovery information 165d stored during rendering 260, and the processing may be restarted from the point at which that recovery information 165d was written. If the recovery information 165e has been written, the process may be restarted from the point at which the recovery information was written. In this case, the information in the recovery information 165e may be restored to the volatile memory 140. In the event of an interruption at or after 270 (following writing of the recovery information 165e) it may be possible to proceed directly to physical printing following a restart/reboot, without repeating any of the pre-print processing, since the pre-print processing is complete at 270, and information for using the intermediate files generated in the pre-print processing is preserved in recovery information 165e.

[0049] According to some examples a subset of the recovery information 165a-e is written to the non-volatile storage 150. For example, in some arrangements recovery information 165 may be written to the non-volatile storage 150 during rendering 260 (i.e. recovery information 165d) and not at other times. In other examples any suitable combination of the recovery information 165a-e may be written to non-volatile storage 150. In some examples, recovery information 165 in additional to that described above may be written. For example, recovery information may be written during uploading 220, parsing 240 stages, and/or during the corresponding waiting stages 230, 250. In some examples recovery information 160 may be written in response to events other than the generation of an intermediate file 155, such as completion of initiation of a stage of processing where the completion or initiation is not associated with generation of an intermediate file. This may improve tracking and/or reporting of a status of processing a print job, particularly in the event of an interruption.

[0050] In some examples, more than one intermediate file 155a may be generated during the create job 405 stage. In such examples, recovery information 165a may be written in response to the generation of each of these intermediate files 155a. Similarly, in some examples multiple files may be uploaded, corresponding to multiple intermediate files 155b, and the completion of the upload of each file (i.e. generation of each intermediate file 155b) may prompt recovery information 165b to be written. Similar comments apply to parsing 445, where multiple intermediate files 155c may be generated during the parsing, and

corresponding recovery information 165c may be written. Similarly, where multiple intermediate files 155d,e are generated between the rendering 260 and processed 270 stages, corresponding recovery information 165d,e may be written. Where an interruption occurs, the processing may be restarted from the point corresponding to the most recent recovery information 165. [0051] In some examples an intermediate file may be written during a particular processing stage (e.g. create job 405, uploading 220, parsing 240, rendering 270), before that processing stage is completed. According to some arrangements, corresponding recovery information 165 may be written while that processing stage is ongoing.

[0052] In some examples the recovery information 165 may be stored in a database in the non-volatile storage 150. For example, the recovery information 165 may be stored in a compressed XML database.

[0053] According to some examples, during pre-print processing the volatile memory 140 may include references to the actual locations of the intermediate files 155 related to the respective objects. For example, a Build3Dltem 310 may store a file path to a 3MF file. During parsing a model description file may be generated, and the file path of the resulting model description file may be stored in a corresponding Build3DltemNode 320. Corresponding information may be stored in the recovery information 165.

[0054] Figure 5 illustrates an example of writing recovery information 165d during rendering. In this example, the data resulting from the parsing has a hierarchy including a job 510 (e.g. Bulid3D) having an item 520 (e.g. Build3Dltem), and the item has four nodes 530a-d (e.g. Build3DltemNode).

[0055] At 500a rendering of job 510 has begun by rendering the first node 530a. When the first node 530a has been rendered the corresponding raster file is stored to non-volatile storage 150 as an intermediate file 155 and recovery information 165a is written. This creates a restore point, such that the processing, if interrupted, may be restarted at this point. In some examples writing the recovery information 165a includes writing a reference to the raster file corresponding to the first node 530a in a database. The rendering then proceeds as in 500b.

[0056] In 500b the first node 530a has been rendered and the second node 530b is in the process of being rendered. When rendering of the second node 530b has completed, the raster file is stored in non-volatile storage 150 as a further intermediate file 155 and recovery information is written. This becomes the most recent recovery point, such that in the case of an interruption, processing may be continued from the completion of the rendering of the second node 530b. The rendering process then proceeds to 500c.

[0057] In 500c the first node 530a and second node 530b have been rendered and the third node 530b is in the process of being rendered. The rendering may continue in this manner.

[0058] When the final node of the item 520 (the fourth node 530d, in the example of Figure 5) has been rendered, this may complete the rendering process associated with item 520, and the process may move to the next item within job 510 by rendering any nodes within that item, if any such items 520 remain to be rendered.

[0059] In some examples additional recovery information 165d may be written subsequent to the recovery information associated with the last node 530d of an item 520, when the item 520 itself is completed. This may be beneficial when additional processing is performed or a further intermediate file 155 is stored between rendering of the last node 530d of the item 520 and completion of the processing of that item 520.

[0060] Figure 6 illustrates an example of a restore process in response to an interruption. Continuing the example of Figure 5, the first 530a and second 530b nodes have been rendered, and the third node 530c is in the process of being rendered. This situation corresponds with that in 500c, and is illustrated at 600a. If an interruption, such as a loss of power or crash requiring a reboot occurs at this stage, when the system has completed a reboot, or is otherwise ready to being processing again, the most recent recovery information 165d is retrieved from the non-volatile storage and restored to the volatile memory 140. In this example, the most recent recovery information 165d corresponds to the completion of rendering the second node 530b (the state between 500b and 500c). Accordingly, the intermediate files 155 that were stored at the completion of 500b (corresponding to the rendering of the second node 530b and any previous rendering) are usable, corresponding to the state illustrated in Figure 600b, where the first two nodes 530a, b have been rendered and the remaining nodes 530c, d have not been rendered. The rendering may then continue, as in 600c with the third node 530c being rendered from the beginning of that node 530c. This state corresponds with the state in 600a. In this example, the partial rendering of the third node 530c is repeated, but other repeated rendering may be avoided. The re-rendering of the first and second nodes 530a, b may be avoided following the interruption.

[0061] In some examples it may be possible to use recovery information 165 to continue from a point prior to the most recent writing of recovery information 165. In the example of Figure 6, for example, it may be possible to make use of recovery information 165 and intermediate files written at (and before) completion of the first node 530a. In this case, after recovery the first node 530a is rendered and the second and subsequent nodes 530b, c,d are considered not rendered. The rendering would then continue by rendering the second node 530b from the beginning. In this case, the second node 530b would be rendered twice, which may reduce efficiency. However, there may be cases in which it is appropriate to start from a state corresponding to recovery information 165 other than the most recent recovery information 165.

[0062] Figure 7 illustrates a method 700 for pre-print processing of a print job according to some examples. The method begins at 710 and a print job 1 10 is received or obtained at 720. The print job 1 10 is processed at 730, and includes, inter alia, outputting 740 an intermediate file 155 to non-volatile storage 150. In response to the intermediate file 155 being written, job information or recovery information 165 is written to non-volatile storage 150. The job information or recovery information is based on information in the volatile memory 140 and is information for the use of the intermediate file 155. The job information or recovery

information may be in the form of a database, or populating an entry in a database. Where job information or recovery information 165 is written in response to the output of an intermediate file 155, the job information or recovery information 165 may be described herein as being associated with that intermediate file 155.

[0063] At 760 it is determined whether or not the processing 730 has been completed. If the processing 730 has been completed, the method 700 continues to 770. However, if the processing 730 has not completed, the processing 730 continues and the method 700 returns to 740. Although not explicitly indicated, processing may be performed before or after each of 740 and 750. In some examples, the method returns from 760 to 740 if remaining processing includes the output of a further intermediate file, but otherwise does not return to 740. If there are no further intermediate files to output, the remaining processing may be completed and the method may proceed to 770.

[0064] At 770 the print-ready content generated by the processing 730 is output, and the method terminates at 780.

[0065] For simplicity of illustration, Figure 7 shows the processing of the job as a serial process. However, elements of the job processing 730 may be performed in parallel. For example, with reference to Figure 2, rendering of one file may be performed while another is being parsed. In some examples multiple files may be rendered in parallel, or may be parsed in parallel. Some examples may permit parsing to begin before uploading of the print job has been completed, e.g. by beginning parsing of a partially uploaded file, while the upload of the file is ongoing, or in the case of a print job uploaded as multiple files, parsing an uploaded file while another file of the print job if being uploaded.

[0066] Figure 8 illustrates an example of a method 800 of recovery from an interruption, according to some examples. The method begins at 810 and at 820 it is determined that an interrupted print job is to be recovered. If there is no interrupted print job to recover, the method terminates at 850. [0067] In some examples, a processor of the print processing device may determine that preprint processing of a print job was interrupted and may recover the processing automatically. The determination that pre-print processing was interrupted may be based on the presence of or contents of recovery information and/or intermediate files in non-volatile storage 150. In some examples the print processing device may check for an interrupted print job, or perform method 800, during or in response to a reboot, restart, reset, etc.

[0068] In some examples, the print processing device may automatically determine that preprint processing of a print job was interrupted, and prompt a user to provide an input indicating whether or not to recover the interrupted processing. [0069] In some examples a user may provide an input causing the print processing device to recover interrupted pre-print processing of a print job, without the pint processing device independently determining that the pre-print processing had been interrupted.

[0070] At 830, the contents of the volatile memory 140 are restored based on recovery information 165. In some examples, the recovery information 165 to be used is automatically determined by the print processing device 100 in response to a determination that an interrupted print job is to be recovered. In some examples the determination of the recovery information to be used is based on an input from a user. In some examples the recovery information is used to restore the contents of the non-volatile memory 140 to a state corresponding to the most recent recovery information 165. However, in some examples, it may be possible to restore the contents of non-volatile memory to an earlier state at which earlier recovery information 165 relating to the same print job was written.

[0071] Following rewriting of the recovery information 165 to the volatile memory 140, the pre-print processing of the print job is continued 840 and the method terminates at 850.

[0072] If the recovery information 165 were not stored in non-volatile storage 150, there is no other record of the job information, such as which files (e.g. intermediate files) have been generated, other than in the volatile memory. Accordingly, when pre-print processing is interrupted, any intermediate files generated prior to the interruption may become orphaned when the print processing device 100 is restarted. Accordingly, if the recovery information 165 were not stored, restarting the pre-print processing from the beginning (e.g. by resubmitting the print job) would be unavoidable, and it would not be possible to make use of previously generated intermediate files. Thus, after an interruption, all partially-processed jobs would be lost after a restart/reboot.

[0073] The volatile memory 140 may store references to intermediate files, and how these files relate to the job (e.g. in the structure shown in Figure 3). In the absence of recovery information 165 stored to non-volatile storage 160 and indicating these file references and/or job structure, the file references and structure would be unavailable, except for in volatile memory 140. Accordingly, in the event of an interruption that rendered the volatile memory 140 unusable, the references and structure would be lost, resulting in orphan files that are not referenced by the available information (in volatile memory 140 or non-volatile storage 150) following a restart/reboot of the device. There would be no indication of how the intermediate files related to the job, or how the intermediate files should be used, and as such they would not be usable. Such files might be overwritten, e.g. during re-parsing or re-rendering the print job following a reset or restart.

[0074] In some examples, using recovery information 165 following an interruption may reduce the need for resubmitting a job, and/or reduce processing time by avoiding the repetition of some previously performed processing. According to some examples, where an interruption occurs after pre-print processing has been completed, the pre-print processing information would still be available, and it may be possible to avoid repetition of the pre-print processing entirely. In such cases, the print job may be able to proceed directly to physical processing following restoration of the pre-print information.

[0075] Figure 9 illustrates an example of a 3D printing process 900 following completion of the pre-print processing. The process 900 may be controlled, in whole or in part, by the print processing section 100. The process 900 starts with the pre-print processing of the print job being completed at 270. At this stage all intermediate files have been generated and the print job is ready to begin printing (physical printing). At this stage, print-ready content has been produced. The print-ready content may include some or all of the intermediate files. In some examples, print-ready content may also include additional files or information.

[0076] In some examples the printing process may be carried out at around 180C.

Accordingly, at 910 a printing bed of the printer may be warmed in preparation for printing.

When a suitable temperature has been reached, the printing 920 may be carried out, layer-by- layer across the whole bed surface. Each layer may include one or more parts, printed as 2D layers. According to some arrangements, the printing process may be based on laying a thin layer of powder, applying pigment agents on the surfaces of the layers of the parts, and applying heat so the powder on the part's surface melts 930. Once the printing has completed, the printed piece may be allowed to cool 940. The printed piece may then be removed from the printer, and in some examples the non-melted powder may be recycled. The printing process is then complete 950.

[0077] In some examples some elements of 910, 920, 230 and 940 may happen in parallel with each other, or with the pre-print processing. For example, warming 910 may begin before the pre-print processing has been completed.

[0078] At 950 the physical printing has been completed and the printed product or parts are ready for unpacking.

[0079] During the process of Figure 9, information may be accumulated on how the job is being done, for each task within the job and for the overall job itself. At various points during this process, information from volatile memory 140 may be stored to non-volatile storage 150. This stored information may be progress information, representative of progress of the physical printing process. This stored information may be used to track the building job activity in the event of an interruption during the physical printing process. [0080] In some examples, following an interruption, the printer may be able to resume the physical printing process from the point of the interruption, or a point just before the

interruption, without requiring the physical printing to restart from the beginning. For example, it may be possible to restart from the last printed layer. In such cases, the progress information may be used to facilitate resuming the physical printing. This may reduce waste by avoiding partially printed parts from being discarded, and may reduce the time to complete physical printing by avoiding restarting the printing of partially printed parts following an interruption.

[0081] Where the printer is not able to resume the partial physical printing process following an interruption, the progress information may be used to restore job information tracked during the physical printing, and to declare the job as completed with a printing error.

[0082] Whether or not the printer is able to resume a partial physical printing process, the progress information may be useful in tracking of the job and subsequent determination of what occurred during the physical printing (e.g. to determine the source of an error or crash, or to assess the viability/reliability of a part produced following resumption of physical printing). [0083] In some examples, the progress information may be stored in a job history database.

[0084] In some examples, following an interruption during physical printing, the recovery information 165 and intermediate files 155 may be used to restart the physical printing without resubmitting the print job.

[0085] Methods described herein may be implanted using one or more processors.

Instructions for causing the one or more processors to carry out the methods may be stored on computer readable medium (such as memory, optical storage medium, RAM, ROM, ASIC, FLASH memory, etc.) The medium may be non-transitory.

[0086] Throughout the description and claims of this specification, the words "comprise" and "contain" and variations of them mean "including but not limited to", and they are not intended to (and do not) exclude other components or integers. Throughout the description and claims of this specification, the singular encompasses the plural unless the context implies otherwise. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context implies otherwise.

[0087] Features, integers, characteristics, compounds, chemical moieties or groups described in conjunction with a particular aspect or example are to be understood to be applicable to any other aspect or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the elements of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or elements are mutually exclusive. Examples are not restricted to the details of any foregoing examples. Examples may extend to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the elements of any method or process so disclosed.

[0088] The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

Claims

1 . A print processing device, the device comprising:

an input to obtain data describing a print job;

a processing section having a memory, the processing section to generate at least one intermediate file based on the obtained data, and to generate print-ready content based on the at least one intermediate file;

an output to output the print-ready content for printing by a printer; and

a job recovery section to store recovery information in non-volatile storage in response to generation of the at least one intermediate file, the recovery information describing contents of the memory relating to the at least one intermediate file.

2. The device of claim 1 , wherein the print processing device is a 3D print processing device, and the print job is a 3D print job.

3. The device of claim 1 , wherein receiving the data describing the print job includes uploading at least one file to the print processing device, and

the generation of at least one intermediate file includes storing the at least one uploaded file.

4. The device of claim 1 , wherein the processing section includes a parser, and the generating print-ready content includes parsing, by the parser, the data describing the print job to generate a digested data file, and

the at least one intermediate file includes the digested data file.

5. The device of claim 1 , wherein the processing section includes a renderer, and the generating print-ready content includes 3D rendering, by the renderer, to generate at least one rendered datafiles, the 3D rendering based on the data describing the print job, and

the generation of at least one intermediate file includes the generation of the at least one rendered datafiles.

6. The device of claim 5, wherein the 3D rendering is to generate a plurality of rendered datafiles, and the job recovery section is to store the recovery information in non-volatile storage in response to generation of each of the rendered datafiles.

7. The device of claim 1 , wherein the job recovery section is to restore contents of the memory relating to the processing of a print job at the at least one state prior to the output of the print-ready content following an interrupt event that results in contents of the memory becoming unusable prior to the output of the print-ready content.

8. The device of claim 7, wherein in response to a reboot or restart of the device, the processing section is to determine whether or not the interrupt event occurred, and to cause the job recovery section to perform the restoration of contents of the memory in response to a determination that the interrupt event occurred.

9. The device of claim 8, wherein the determination whether or not the interrupt event occurred is based on the presence, absence and/or contents of the intermediate files and/or recovery information.

10. The device of claim 7, wherein restoring the contents of the memory includes creating in the memory the memory structures corresponding with memory structures that were present at the state prior to the interrupt event.

1 1 . A method of processing a print job, the method comprising:

obtaining a print job;

processing the obtained print job using memory to produce print-ready content;

at one or more stages of the processing, outputting an intermediate file to non-volatile storage; and

writing, in response to completion of outputting the intermediate file, job information from the memory to non-volatile storage, the job information including information for using the intermediate file.

12. The method of claim 1 1 , further comprising:

determining that an interrupted print job is to be recovered;

restoring contents of the memory based on the job information written to non-volatile storage; and

continuing to process the print job from the stage of processing corresponding with the completion of outputting the intermediate file associated with the job information on which the restoring was based.

13. The method of claim 1 1 , wherein the job information includes a pathname of the intermediate file.

14. The method of claim 1 1 , wherein the job information describes a relationship between the intermediate file and a job structure of the print job.

15. A printer comprising:

a communication port to obtain a print job; and

at least one processor connected with a memory, the processor to process the obtained print job to produce print-ready content;

the at least one processor to store in non-volatile storage a description of contents of the memory at various points during the production of the print-ready content, the various points corresponding to completion of intermediate files generated during the processing of the obtained print job to produce the print-ready content.