US 20050060650 A1
Methods for a graphic user interface within a document production system, including a method for associating electronic data files to particular document components and a method for providing a graphical representation of a job model for a document. Included within these methods are methods for checking the progress during production of a job through production processes having a plurality of devices as well as methods of checking the status of components of the document and status of devices during production. Also included in these methods are methods for selecting among a plurality of possible arrangements of devices capable of producing the document.
1. In a controller for a document production system, such controller having an associated display, a method for providing a graphical representation of a job model for a document, comprising:
a) inputting into the controller an identifier for the document to be represented;
b) retrieving job model data regarding the identified document from a database;
c) displaying a graphical view of the job model arranged as a hierarchical tree of the document and a plurality of its document components.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. The method of
10. The method of
11. The method of
12. The method of
a) retrieving job model data arranged as a sequence of nodes associated with a plurality of job segments within the document; and
b) using a recursive algorithm to inquire concerning the status of the job segments within the document.
13. The method of
14. The method of
15. The method of
16. The method of
a) associating a unique identifier for each item displayed within the hierarchical tree; and
b) manipulating at least one unique identifier by changing its representation on the display.
17. The method of
18. The method of
a) the production system comprises a plurality of finishing operations;
b) the document may be finished using a plurality of possible threads of such finishing operations; and
c) the step of displaying the job model as a hierarchical tree further comprises displaying a plurality of threads using a perspective view of representations of a plurality of finishing devices arranged as threads
19. The method of
20. The method of
21. The method of
22. The method of
23. The method of
24. In a finishing system having at least one database for storing information concerning the job model for a job, including identification and descriptions of the job and job segments stored as nodes of information within the database, a graphical user interface, comprising:
a) a opening screen with user options to select a database, a job stored in the database, and a type of report for displaying information concerning the job;
b) an optional display a selected job in a hierarchical view with multiple nodes arranged in a tree view showing the relationship of each node to other nodes within the same job; and
c) an optional display of information describing the status of each job segment within the job.
This is a divisional of U.S. application Ser. No. 09/858,385 filed May 16, 2001 by the same inventors, and claims priority therefrom. This divisional application is being filed in response to a restriction requirement in that prior application. Priority is claimed from Provisional Application No. 60/204,471, filed May 16, 2000.
Reference is made to commonly-assigned copending U.S. Provisional Patent Applications, Ser. Nos. 60/204,716, filed May 16, 2000, entitled: Finishing Module Coordinator Apparatus and Method for Assembler/Finisher Systems, by Ryan, et al; 60/204,460, filed May 16, 2000, entitled: Production Monitor Controller Apparatus and Method for Assembler/Finisher Systems, by Ryan, et al; 60/204,720, filed May 16, 2000, entitled: Database Apparatus and Method for Assembler/Finisher Systems, by Ryan, et al; 60/204,624, filed May 16, 2000, refiled Apr. 25, 2001, as U.S. Ser. No. 09/841,089, entitled: Apparatus and Method for Describing, Planning, and Automatically Programming Complex Finishing Tasks, by Ryan et al., the disclosures of which are incorporated herein.
It is believed that the present invention is applicable to the electronic management and control of a wide range of finishing processes characterized by input from multiple production operations and equipment that, depending upon the job, may be variably applied to work pieces that themselves are highly variable between different jobs. Although the present invention is explained in relation to printing and finishing operations for printed documents, the present invention may apply to such industries, without limitation, as include textile production (which may include printing, cutting, sewing, and finishing), packaging operations for various consumer and industrial products, printed wiring board production, etc. In particular, the present invention is applicable to many operations where processes for production of work pieces are managed separately from processes for finishing and packaging of such work pieces.
Creation and production of printed documents often involves many production and finishing operations that are highly variable with each job. In general, the various operations can be grouped into three major phases: 1) creation of the document information, including prepress operations that render the document in a form suitable for printing, 2) printing of the information onto some form of media such as paper, and 3) finishing of the selected media into a completed document. These 3 major phases often have many sub-phases, and the entire process may vary from relatively simple to extremely complex. The present invention deals with techniques by which a user may provide detailed instructions for each of the three phases such that instructions may be created as early as during the first phase that are sufficient to guide the entire process through to completion of the third phase. Although of potential use in many printing operations, the present invention is particularly applicable to automated systems for creating, printing, and finishing complex documents within a multi-printer, completely digital environment using digital printers.
Traditionally in phase 1, when a document is composed, the person doing the composition will create one or more electronic image files that represent the parts of the document to be produced. These electronic image data files may be stored in many different formats by many different document creation and manipulation programs. For instance, for a complex document such as a book that utilizes color printing for book covers and pictorial inserts, any of a variety of Page Description Languages (PDLs), such as Postscript®) and Postscript-compatible languages, may be used to render the color images in printable form. Often different components within a document will utilize different PDLs. For instance, the cover may be created by a different work team or upon different equipment than photographic reprints or other internal color components. Each prepress team or prepress device may utilize a PDL optimized for its use. For pages comprised of simple monochrome text, a desk-top publishing program may be utilized to render such pages or a simpler word processing language may be utilized. Still other prepress formats may be utilized for printing of inserts, dividers, and other possible components internal to the finished document. There also may be included in the assembly/finishing job non-printed components such as, without limitation, plastic separators, previously printed sheets retrieved from inventory, photographically produced sheets, or specialized media such as vinyl disk holders or perfume sample packs.
Examples of documents with different components and levels of complexity will now be shown by reference to
Obviously, documents may vary greatly in complexity depending upon the number and order of components, finishing options chosen, etc. Typically, various prepress devices create individual components of the document and digitally render these components in formats that are suitable for printing. PDLs such as Postscript™-compatible languages are often used for such purposes. Subsections of the job that require different prepress or printing operations are typically divided by an operator at an early point in the process. After completion of prepress operations for each portion of the job, the operator(s) send the various portions of the job to printers appropriate for each such portion, thereby initiating different “paths” that each portion of the job my take.
It is important to note that in many jobs, receiving feeder bins such as 42 a, 42 b, 42 c, and 43 a have stack height constraints that are less than the total stack height of a particular portion of the job that was printed. In the prior art, an operator typically manually separates a stack of printed sheets into smaller stacks that will fit within the constraints of the receiving bins.
Much prior art deals with operations that automate tasks internal to each of equipment and processes described above. In particular, much work has been done to provide automatic linkages between prepress operations and digital printing processes, including output from printers at intermediate finishing stations with capabilities such as collating. One aspect of such prior art includes creation of virtual job tickets to electronically convey information from prepress apparatus through to intermediate finishing operations of the selected digital printers. See, e.g., U.S. Pat. No. 5,995,721 issued to Rourke et al. U.S. Pat. No. 5,615,015 issued to Krist et al.; U.S. Pat. No. 5,760,775 issued to Sklot et al. In Rourke et al., for instance, prepress processes examine the attributes of a print job in order to determine which of a variety of printing apparatus are capable of printing each particular portion of the job in accordance with the specified attributes. The instructions governing printing of each specific portion are provided to each printer pursuant to a virtual job ticket. In Rourke and in other prior art, however, digital tracking and control linkages between the paths of various job portions sent to different printers is generally lost after each portion is sent to a different printer. The virtual job ticket is used only during the printing process itself and during any post-printing processes directly linked to the printing phase of the job. Thereafter, the parsed portions of the job are re-integrated not by use of a virtual job ticket providing instructions to offline finishing but by dropping sheets of one parsed portion into “holes” left in the printing queue of a second portion. See Rourke, column 13, line 11-39. Another characteristic found in Rourke and in other prior art is that a job is parsed into portions based upon printing characteristics and not upon constraints to be encountered during the entire printing and finishing process.
Although two-way digital tracking and control linkages are common within printers that are physically integrated with their own intermediate finishing stations, there are no two-way digital tracking and control linkages between a stand alone printer system and offline assembler/finisher apparatus such as shown in
The need in both the prior art and in the present invention is to efficiently convey to and program the appropriate assembler/finisher systems with the above assembly/finishing data, then to track progress of the job through the finishing operations, and finally to maintain integrity of the job in order to detect and/or prevent defective finished documents.
The prior art teaches several methods for accomplishing the above tasks with varying degrees of satisfaction. A very common approach is for a human operator to separately program the assembler/finishing system. Often, the information to program the finishing operation is provided to the operator in a written or printed sheet or set of sheets, called a traveler sheet, that incorporates information describing assembler/finishing operations for all portions of the job. When preparing to load the stack into the finishing equipment, the operator reads the traveler sheet for the relevant assembly/finishing instructions, including the order in which the components are to be assembled in the finished product. A complete set of attributes for each component is not provided since the skill and experience of the operator enables the operator to select proper bins, parse stacks, orient sheets, and similar tasks when preparing and programming the assembler/finisher device. A more modern version of this same basic system uses a traveler sheet that is encoded with barcodes or other machine readable coded information. When ready, the operator places the traveler sheet before a digital reader which then displays the information to the operator for manual programming. Yet another version of this idea is to place a machine-readable code such as a bar code or glyph on a sheet associated with each job. This sheet may be a cover sheet placed on each stack of sheets. The code is read by a digital reader and its information is used to set up equipment for the job. Even with the ability to encode some job information digitally, the information required in conjunction with moderately complex jobs for programming of off-line assembler/finisher equipment is so complex that in the prior art some manual programming is required.
The complexity of interrelating and automatically programming all of the above printing, assembling, and finishing operations can be understood by contemplating the innumerable parameters and operations that must be coordinated during the course of a reasonably complex printing job, especially one involving multiple printers and multiple finishing operations and assembler/finisher devices. In addition to all of the variables relating to paper selection (e.g. size and type), PDL or other page descriptions, and other parameters and operations applicable from prepress Phase 1 through completion of printing Phase 2, the assembly/finishing Phase 3 requires programming of information that both (1) specifies the complicated details of assembly and finishing operations to be performed upon each sheet or set of sheets within the job and (2) relates each sheet or set of the job to every other sheet and set of the job. Especially when the sheets are arriving from different sources such as from multiple printers or from both printers and inventory, existing systems have only been able to automate a portion of these programming tasks or have succeeded in performing both of these programming tasks only in very carefully prescribed circumstances.
For instance, in U.S. Pat. No. 5,859,711, issued to Barry et al., the problem is discussed in the special case where all of the pages of a document are sent to a job controller as one job and are then divided at page breaks such that each page is treated as a separate print job. By dividing the one job into a plurality of jobs on a page-by-page basis, the various pages can be allocated to a multitude of printers such that one or more printers can be operated as one virtual printer. The advantages include greater speed and the ability to send color pages to color printers and monochrome pages to monochrome printers, thereby optimizing the use of each. In the above manner, Barry teaches a method of optimizing production of a job through the printing Phase 2. Barry does not, however, teach a method for optimizing the assembler/finisher portion of the production or for arranging the printing, separating, and stacking of portions of a job with a view to the capabilities and constraints of the assembler/finisher equipment. At column 18, lines 37-47, Barry provides part of its solution to the problems created when a job has been parsed to different printers and needs to be reassembled: “It is only important that, when the stacks are defined within a given printer, there is some indication, such as a separator page, that will allow the particular stack created between separators, to be assembled with another stack from another printer in the desired print job output.” (lines 42-47) At columns 37 and 38, a second portion of Barry's solution is disclosed by teaching that a distributor control can operate to configure and reconfigure the automatic finishing device in response to how a job is divided into stacks, with each stack being treated “as individual entities and queuing them up and processing them independent of how fast another job stack in a given job is processed through an adjacent print engine.” Column 37, lines 12-15. Barry also teaches that a distribution control can configure automatic finishing devices or such devices may be configured by reading instructions printed on each separator sheet in bar code form.
Thus, Barry is concerned with a method of dividing a job into portions that can be routed to different printers for more efficient printing operations. Its finishing teachings are limited to methods for recombining the separated portions of a job back into the correct order for final finishing. There is no teaching concerning how to combine the job portions except how to collate the portions arriving from different stacks. There is no teaching of how to combine printed sheets with non-printed or previously printed sheets taken from inventory. There is no teaching concerning how to break a stack apart except in response to the job portions created for optimized printing. If further divisions of stacks are necessary after printing in order to enable assembly/finishing operations, Barry lacks any method for analyzing or implementing such divisions. Most importantly, Barry does not teach that the capabilities and constraints of assembler/finishing equipment can be used to divide a job into portions.
Perhaps the most complete attempt to provide a structure for automated programming of certain specified types of print jobs is the International Cooperation for Integration of Prepress, Press, and Postpress (CIP3) Print Production Format issued by the Fraunhofer Institute for Computer Graphics. The web address for CIP3 is: http:IHwww.cip3.org. First issued in 1995, CIP3 provides an ability to create a digital “traveler sheet” written in the Postcript language. CIP3 enables a complete digital description of a document and all of its production steps. It is a proposal for a description language, not a control algorithm. As a description language, CIP3 provides one method of relating each page of a job to every other page of the same job. As described in the Specification of CIP3, the CIP3 format is intended to enable automatic programming of assembler/finisher equipment. What is missing in CIP3, however, is the automatic programming itself. What is also missing is an ability to match described production operations with the capabilities and constraints of the particular equipment available in conjunction with this job. CIP3 is therefore not useful in selecting or optimizing the actual equipment to be used when planning the job. CIP3 also lacks the ability to inter-relate the production effects of one job to a second job, and CIP3 is therefore of limited value in production planning of multiple jobs. Also, by failure to divide a job into subparts that conform with the constraints of the actual equipment to be used, CIP3 is limited in the depth of its ability to relate each sheet of a job to all other sheets that have been prepared as part of the job.
The ability to track and associate the complex data associated with each or stack of sheets within a complicated print job is greatly hindered by the innumerable equipment and processing parameters that characterize and constrain use of each piece of equipment. For instance, every item of equipment shown in
The problem of coordinating equipment constraints is further complicated because of inherent mismatches between the output of printers and the constraints of assembler/finisher equipment. For instance, when a stack of sheets from a printer has more sheets than can be received in the assembler/finisher feeder bins, then a human operator or a machine conveyance system typically divides the larger stack by grabbing whatever number of sheets appear to fit within the feeder bin capacity. This means that the various assembler/feeder bins are filled with unequal numbers of sheets. It also means that a stack of printed sheets gets divided and separated. The separated stacks are typically stored in intermediate bins and must be stored, tracked, and retrieved when needed. Even where large stacks of sheets are divided by a manual or automated counting procedure such that each separated stack is maintained with a known quantity of sheets, there is no ability in the prior art to dynamically adjust the size of such stacks to conform to the varying constraints affecting each particular printing job and the particular equipment selected for that job. Moreover, stacks of pre-counted sheets are of little use when responding to sheets that are found defective, missing, or damaged. Lastly, where a job can be routed to one of a variety of assembler/finisher systems, each having different constraints, it would be desirable to dynamically change the stacks of printed sheets in order to optimally conform to the constraints of the particular assembler/finisher equipment that becomes selected. This would be especially desirable when managing queues of finishing jobs in systems that are capable of rerouting assembler/finisher operations in response to equipment breakage or unavailability due to use of initially selected equipment with other jobs.
As described above, another task required during the print production process is effective tracking and integrity checking. Within individual printer systems, these tasks are well understood. For instance, in typical production printing systems such as the Docutech® Model 6155 marketed by Xerox Corporation, sheets are counted when fed from the system input feeder and are timed or recounted during or after every major operation performed within the machine. In the event that a sheet does not arrive at a designated station within the time constraints permitted by the system or is otherwise detected as missing, a jam is declared and the portion of the machine apparatus operating prior to the jam is paused. An operator is then directed to clear the jam by removing all sheets residing in the paper path. Since the system controller has tracked and counted each sheet, it knows the number and image file identity for each sheet that has been removed. When the system detects that all sheets have been cleared, the controller directs the re-imaging and processing of each of the removed sheets. For duplicator systems with recirculating document feeders (RDFs), the same concepts apply except that the controller directs the RDF to circulate the input document pages until the first missing document page returns to the top of the imaging queue.
For print jobs requiring use of multiple printers, the above tracking and integrity functions are less completely managed in the prior art. For instance, in the state-of-the-art Book Factory® system launched by Xerox Corporation in 1999, a primary production printer based upon a Docutech Model 6180 printer system is physically integrated with assembler/finisher apparatus capable of any of the following finishing operations plus appropriate combinations of these operations: Collecting, Folding, Trimming and Adhesive Binding. The Book Factory system also comprises an assembler with a manually loaded input tray for accepting inventory sheets, including covers, printed or prepared by other printers or processes. Although the Book Factory assembler/finisher apparatus can count and time the progress of sheets in much the same way as described above in relation to single printer systems, there is no two-way communication concerning job status to the printer or inventory systems that supplied the manually input sheets. Thus, in the event a jam is declared, there is no method by which other printer systems may automatically be directed to reprint the removed sheets. In normal operations, operators prepare for missing or destroyed sheets by printing extra copies. Where extra copies are not available, then an operator must reprogram the other printer system and reprint the job. In any event, the result is typically waste of extra or removed sheets, consumption of extra consumables such as paper and ink, and expenditure of valuable time by operators and expensive printers.
In sum what is missing in the prior art is:
One aspect of the present invention is a method in a controller for a document production system for associating electronic data files to particular document components of a document, comprising: a) creating a document node as a parent node; b) selecting one of a set of document forms to apply to the document; c) creating a document component node as a sub-node of the document node; and d) associating an electronic data file with the document component node.
Another aspect of the present invention is a method for providing a graphical representation of a job model for a document in a controller for a document production system, such controller having an associated display, a, comprising: a) inputting into the controller an identifier for the document to be represented; b) retrieving job model data regarding the identified document from a database; c) displaying a graphical view of the job model arranged as a hierarchical tree of the document and a plurality of its document components.
For purposes of the present invention, the following definitions shall apply:
A “document component” shall mean a collection of one or more sequential sheets of media that have similar qualities or characteristics and thus would be printed or non-printed and would be finished or produced in a similar manner. Examples of document component types are covers, bodies and inserts. When collected together in a specific order, a collection of document components may form a complete “document”. Each document component may require its own intermediate finishing operation before its final assembly/finishing into a “document”. For instance, a cover sheet may require lamination in an intermediate finishing process before conveyance to the final assembly/finishing apparatus.
A “document” shall mean a collection of one or more document components placed in a specific order and finished in a manner that relates the various document components to each other.
A “document form” shall refer to the manner in which the various components are finished into a composite form, including such operations as folding, cutting, stitching, binding, and gluing. Each document form requires unique image imposition, printing, finishing process requirements and physical identifying characteristics. The structure of most typical documents can be classified into one of 7 standard “document forms”:
Other document forms can be specified as needed.
A “constraint” shall mean a limitation of a device based upon its design or use. A “constraint” may be permanent or temporary. Examples of permanent constraints would be inflexible bin heights or widths, temperature limits for laminators, bin type (set feeder or sheet feeder), method of feed (e.g., top or bottom feeder), required order (n-to-1 or 1-to-n), face up, face down, required orientation (e.g., leading edge must be long or short dimension), paper path width; thickness for folding and trimming, transformations enabled within the device (e.g., face up to face down, lead-edge reversal to trial-edge), landscape to portrait orientation, etc.) and similar limits related to a device's design. Examples of temporary constraints include: a period of time that a piece of equipment or part of equipment, such as a particular bin, is not available due to a broken part or use for another job; or (b) the type of media, glue, binder material, etc., then available for use within a particular piece of equipment.
A “job segment” shall mean a stack of sheets produced by a common printing or finishing process and conforming to the same printing and finishing constraints. A “job segment” may contain a single document component, a portion of a large document component, or a collation of several document components. As will be explained below, “job segments” are identified in order that document components with similar printing and/or finishing requirements are grouped together for efficient printing, handling, and finishing. For example, if a document has two 8.5″×11″ monochrome body components, both body components may be grouped in the same job segment in order that they will be printed on the same printer at the same time. Depending upon requirements, these components may be output at the printer as collated or non-collated stacks and, if the components are collated, the collated stacks may be placed in an offset manner in order to indicate separation between the collated sets. As another example that is particularly pertinent to the present invention, it an input bin of the selected finishing apparatus has a stack height constraint of 2.2 inches, then the maximum stack height of a “job segment” will be 2.2 inches even if the total stack height of a particular document component or of a collated stack of components is much higher. For this situation, a “job segment” during printing Phase 2 may comprise all of the sheets that are printed at the same printer. Within this large job segment stack, however, smaller “job segments” limited to 2.2 inches in height may be separated in an offset manner or separated by separator sheets. Thus, segmentation of a job would be done based upon an offline finishing constraint that does not otherwise affect the operations of the printer system.
As used herein, “finisher” and “assembler/finisher” shall both refer to systems designed to perform assembly and/or finishing operations.
As used herein, a “system” shall mean any organization of devices, hardware, and software that can be operated cooperatively to accomplish performance of a job.
A “node” means each unit of a job arranged within a hierarchy of units, i.e., the job itself, each document within the job, each document component within each document, each stack, sheet, set of sheets, etc. The hierarchy descriptors found in CIP3 can be useful in identifying many of the “nodes” of a job. When used in conjunction with object-oriented software, a “node” may be treated as an “object” that can moved or manipulated by itself or may be opened into subparts that themselves are objects that can be moved or manipulated.
One aspect of the present invention is a software architecture by which the assembly and finishing Phase 3 of a complex document can be managed as early as during the initial Phase 1 set up of the job by use of an architecture in which the document is represented as a series of individual document components that, when assembled in a specific order, can be classified in one of the specified document forms.
Turning now to
The data for each VFJT is recorded by the PMC in a Virtual Finishing Job Ticket Database (VFJTDB), shown in
The type of data and instructions required in a VFJTDB 501 for each job are information such as but not limited to: accounting and administration information, sheet, set and job level finishing instructions, color and print quality control data, registration data, etc. The data and instructions also contain a description of the job segments (stacks and stacks of sets) of the job being produced and instructions on how to reassemble these pieces to complete the processing of the job. Additionally this information can enable the automatic setup of the finishing device(s), integrity control and monitoring throughout the full scope of the production processes. The VFTDB provides the basis for a direct link between the offline finishing operations and the integrity control functions of online printing and intermediate finishing systems. The VFJTDB data can take on the form of a proprietary format or an industry standard format such as but not limited to a modified form of CIP3. More information concerning the structure and use of the VFJTDB 501 is contained below.
Returning now to
Boxes 201-204 of
As shown in
Another aspect of the present invention is the association of a unique Job Segment Identifier (JSI) with each job segment. In
A JSI can assume any form that can be associated with a job segment throughout the finishing and other applicable printing processes. Among such forms are copies stored in (a) a printed sheet printed and placed on top of a printed job segment, (b) system memory such as hard drives, (c) magnetic media such as floppy disks or magnetic strips, (d) optical memory such as CD-ROM or CR-RW disks, (e) bar code symbols printed on sheets associated with the Job Segment, or (f) any other means by which machine or human readable identifying information may be associated with a Job Segment. A JSI may be machine, human readable, or both depending upon the phase of the job. Indeed, in the event that a scanner is capable of reading the top printed page of a job segment in such manner that the job segment can be uniquely identified, then no special symbols or special top page would be necessary. Thus, each JSI contains, at a minimum, a job and job segment number or other identifier that uniquely identifies the job segment from all other job segments. Typically, the JSI comprises both a unique job number and a Job Segment Identifier Code (JSIC). The job number uniquely identifies the print job from all other print jobs and the JSIC uniquely identifies the job segment. In one embodiment, the JSIC comprises recognizable unique text on the top sheet of a job segment, which JSIC forms a vector to a JSI that remains encoded in digital memory. Whichever form a JSI takes, the JSI serves as a reference pointer to the portion of the VFJTDB that describes the contents of the identified job segment. The JSI remains associated with the applicable job segment when it is transported from the printing device(s) to other finishing processes. This enables tracking of the job segment from the printing device(s) to the assembler/finisher apparatus. Whether or not the job segments are part of a job that requires prints to be produced on one or more printing device(s), each JSI will have a common job number but a different JSIC that uniquely identifies each particular job segment of the job.
Phase 3 of the printing process comprises the final assembly and finishing phase wherein the various document components are gathered from output trays or bins 201B-203B and 204D, assembled in a particular order, and finished into a specified document form. In the prior art, where multiple printing devices are used, operators configure and operate these Phase 3 steps separately from operations performed in each of Phases 1 and 2. Only in those instances in which all of the assembly and finishing is accomplished within a single digital printer and governed by a unified print/finisher controller does the prior art teach that Phase 3 can be configured and controlled automatically. In
In the present invention, each job segment arrives at the assembler/finisher apparatus with a JSI reference pointer. As noted above, this typically will appear on a JSIS although any form of JSI will suffice. The purpose of the JSI is to identify a particular job segment to a Finishing Module Coordinator (FMC), 700, which is a controller of the present invention that directs the assembler/finisher operations. In
Details of the PMC, shown as Box 100 on
Each of the steps shown in
At step 71, attributes are assigned automatically or by the user to each “node” identified in the high level job model received by the PMC. “Node” is defined above to mean each unit of a job arranged within a hierarchy of units, i.e., the job itself, each document within the job, each document component within each document, each stack, sheet, set of sheets, etc. The hierarchy descriptors found in CIP3 can be useful in identifying many of the “nodes” of a job. When used in conjunction with object-oriented software, a “node” may be treated as an “object” that can moved or manipulated by itself or may be opened into subparts that themselves are objects that can be moved or manipulated. At step 71, the identifiable nodes are typically at the job, document, and document component levels.
At step 72, the operations to be performed on each node are identified. Again, CIP3 may be a useful tool for identification of certain operations. Next at step 73, source files for each of the document components are assigned. Next, at step 74, printers that are available to output the job are assigned. At step 75, finisher/assembler devices available for the job are assigned. At step 76, the PMC evaluates whether intermediate finishing operations such as collation should be assigned to printer systems having such capabilities or whether such operations should be performed by non-integrated assembler/finisher equipment. At step 77, the key step of generating job segments occurs. As will be explained in more detail below, job segments for each operation of the job are determined based upon the attributes and operations associated with each document component plus the capabilities and constraints of the various printers and assembler/finishers that may be used for the job. At step 78, various outputs from the PMC are shown. At step 78A, instructions for printing and/or other preparation of an intermediate job segment is shown. An example of such an intermediate job segment might be the initial printing of JSIS or other sheets that will ultimately run through two or more printers. After such JSIC or other intermediate preparation, the initial job segment may be broken apart or combined into different job segments that are appropriate for the next printing or assembler/finisher step. At step 78B, instructions for final printing of each job segment are provided. At step 78C, a copy of the job model and job segment descriptions is sent to the Finishing Module Coordinator (FMC) via the VFJTDB (boxes 700 and 501, respectively, in
Turning now to
Turning now to
At step 89, the user is asked whether an additional document component will be added to the job. If yes, the user interface returns the user to step 84. If not, the PMC algorithm proceeds to step 90 where a “Document Form Rule” operator compares attributes of all the document components to each other and to a list of attributes that are either specifically permitted or prohibited for components within the selected document form. For instance, if the imposition attributes of the various signatures are not consistent with each other (e.g., the gutters and fold locations are not aligned), then the “Document Form Rule” operator 90 will notify the user at step 91 of a violation of the document form rules and will prevent finalization of the job model until corrected or overridden by the operator. If the document and its document components all conform to their respective Document Form Rules, then the job is passed to step 92, where the document model is deemed complete. If instead a violation of Document Forms Rules is detected, the user is returned to step 89 where he/she is asked to make appropriate corrections via a return to step 84. When a job has been passed to step 92, the user is interrogated, at step 93, whether another document is to be added to the job. If yes, then the user is returned to step 82. If not, processing continues to step 94, where the job model is deemed complete.
Turning now to
At steps 107-110, the various possible threads are matched and compared in order to eliminate or minimize equipment utilization conflicts and to determine the optimal selection of threads for implementation of the job. The optimization process can be accomplished by any number of algorithms that provide values for the various devices and evaluation criteria for determining preferences. For instance, if optimization is to be determined on the basis of the shortest time for completion of the job, then a possible algorithm for such optimization would assign a time period for each operation performed by each device on each sheet or job segment that flows through the thread. The sums of all time periods attributable to each thread would then be computed, and the combination of threads that results in the shortest production time would be selected as the optimal mapping of threads. Similarly, optimization algorithms and VJTDB data can be established for optimizing the estimated cost of a job, for optimizing or minimizing the use of a specific device, for any similar priority goal, or for any combination of optimization goals. Step 109 indicates a particular portion of the optimization process wherein the intermediate finishing capabilities of the various printers within the threads are compared and optimized. For instance, if a printer can print two separate document components in collated, non-collated, or collated set form, these three possibilities comprise three different possible threads requiring different assembler/finishing operations. These different threads may then be compared for optimization purposes. Such different threads may be created whenever printers are capable of multiple output or finishing options. At step 110, another aspect of the optimization process is determining which, if any, document components can usefully be combined into a single job segment during a printer and/or finishing operation and to thereby be treated as a single node having two subparts. For instance, if two monochrome document components identified as A and B can be printed by the same printer, one thread may exist that treats these as a combined job segment that outputs the document components in collated, offset, stacked form: A,B; A,B; A,B; etc. If the subparts A and B will subsequently be separated, they may also be offset within their respective sets. Once separated, the thread may provide that document components A and B are recombined with other document segments to form new job segments applicable for the subsequent assembler/finisher operations. At the conclusion of steps 107-110, the PMC at step 111 presents to the user a recommendation for the optimal selection of threads, including information if desired of job segments, estimated time, estimated cost, etc. In one embodiment indicated by
At steps 112-114, the user is prompted to review and approve the recommended threads prepared by the PMC. If accepted, the job goes to the integrity and tracking features of the PMC that are shown in
Alternatively, column B of step 200 describes the processes applicable when an integrity descriptor is created before the PDL files are delivered to the PMC. At step B200A, the integrity descriptor is read from the PDL file. At step B200B, the integrity descriptor is encoded into the VJTDB or other database.
At step 201, the PMC uses the job model to determine if the document component comprises preprinted or non-printed sheets or other items that must be added to the workflow from inventory in order to complete the job. Among the items that may be noted are separator sheets, binder materials, preprinted pictorial inserts, perfume-containing scent cards, and similar items that are not printed as part of the current job. Since stacks of such inventory materials typically do not have a traveler sheet prepared for this job, the PMC at step 201 generates a Fetch Sheet PDL and directs its printing if necessary.
At step 202, the Job Segment Identifier Code (JSIC) for the job segment is generated. The JSIC is a unique identifier code that enables the FMC in Phase 3 to lookup a description of the job segment within the VFJTDB. A JSIC may be generated by combining a job number with a sequentially generated number that represents the stack number within the job. More details concerning the JSIC and its use are provided below. At step 203, the PMC directs the generation of a PDL file for printing of a Job Segment Identification Sheet (JSIS) if required. The JSIS will contain the JSIC, a human readable instruction sheet for processing of the job taken from the job model, and lists of document and document component attributes. It should be noted, however, that in systems where the identity of a job segment can be determined or tracked without the printing of a JSIS, then some or all of step 203 may be eliminated. For instance, where the contents of the top sheet of a stack can be automatically read by a VJTR and matched against a database of expected top sheets, the FMC then could identify and track the job segment by reading such top sheet as it moves through the various production phases without the need for a special JSIS or even special JSIC on the top sheet, i.e., the contents of the top sheet itself would form a JSI.
At step 204, the PMC stores the JSIC, the job segmentation, and the selected job segment thread information in the VJTDB. At step 205, the PDL files covering a JSIS, if any, is added to the PDLs and other files required for printing of the applicable job segment and such files are delivered to such printer for printing. Phase 2 of the printing production process is thereby commenced. At step 206, fetch sheets for the job are also sent to appropriate printers in order that they be available to the human operators as the job is produced. At step 207, the PMC determines whether the job has additional job segments to process. If yes, then steps 200-206 are repeated again for each job segment. Once processing of all job segments has been completed, then at step 208, the PMC directs creation of a traveler sheet PDL and its printing in order that all of the information required to produce and process the job and each of its job segments and/or document components is placed in human readable form for the human operators. Such traveler sheets typically stay with the job jacket as it moves around the print shop.
More details concerning the VJTDB will now be discussed in relation to
The job description portion of the VFJTDB is best understood as a database having a hierarchical tree structure with each level of the tree having one or more discrete nodes.
On the next level below Sig1 is node P1 which is the node containing descriptors for a particular document to be produced as part of Job Sig1. There is no limit to the number of documents that may be stored under a particular job, and nodes P2, P3, etc. could exist. Turning now to node P1, such top level document node contains an identifier of the document form governing the document. By designating such document form, a table of attributes for such document form and a set of Document Form Rules are associated with P1, and these rules and attributes will be used by the PMC when mapping production of the job. As noted above, node P1 also identifies each of its children nodes. An important aspect is that each node P1 contains information detailing the order and manner in which each of the children nodes relate to each other, e.g. cover C1 is identified as the document component that will ultimately be on the outside of the document. Since the example shown in
The job model register will also contain information, conforming to the applicable Document Form Rules, for programming A/F #6 to perform all of the scoring, folding, stitching, trimming, etc. operations that will result in final production of the signature booklet described in node P1. Among the typical parameters encoded for such operations will be the identity of the operation and the location for its operation on the work piece, the type and temperature of any lamination step, any pressure requirements for scoring, folding, binding, etc., the type and location of binding, etc.
Each node at the level below node P1 will contain information relevant to the job segment represented by such node. Such information will include the printer and bins from which such segment is derived, the number of sets or sheets in the job segment, its current location, attributes of the segment such as whether it is collated or not collated, face up or face down, orientation, sheet weight, color, type and thickness, etc. Of particular note in the shown example is node B1 which comprises a single job segment of two collated document components arranged in interleaved offset sets. Each of these document components may be described in their own separate nodes as indicated by node S1. There is no limit to the number of nodes or levels of nodes in the present invention. In the event that each of the document components represented in B1 were sourced from separate printers, then each would comprise a separate job segment with a separate node which then became combined into a new job segment at node B1. Note that when delivered from node B1, the job segment stack was disassembled and its components were rearranged into a new job segment P1. Obviously, for complex books comprising many signatures, inserts, covers, etc. many nodes and levels of nodes would be represented in the VFJTDB.
Turning now to
The FMC begins its investigation of equipment readiness at step 608. At step 608, the FMC identifies from the job model each device necessary for the next set of finishing operations. In most cases, assembler/finishing operations will be designed to produce finished products in a continuous assembler/finisher process. Where the assembler/finisher process may conveniently be broken into non-continuous phases, however, the FMC need only identify the assembler/finisher devices necessary for the next phase of operations. Also as part of step 608, the FMC extracts from the job model any device configuration attributes that the job model requires in order for the job to be implemented. For example, if an assembler device permits different input bin configurations and the job model specifies a specific configuration, then this data would be extracted from the job model. Similarly, if paper path guides or scoring and folding apparatus, etc. need to be in specified locations that are not adjustable through automatic programming, such attributes are identified through the job model. At step 609, the FMC interrogates the listed devices to determine whether they and the specified configurations are available for aprocessing of the job. The interface between the FMC and the assembler/finisher devices may take many forms. One such interface protocol is the Modular Feeding and Finishing Architecture (MFFA) of the Xerox Corporation. The MFFA is described in the following U.S. patents: U.S. Pat. No. 5,701,557 issued to Webster, et al.; U.S. Pat. No. 5,631,740 issued to Webster, et al.; U.S. Pat. No. 5,617,215 issued to Webster et al.; U.S. Pat. No. 5,604,600 issued to Webster; U.S. Pat. No. 5,559,606 issued to Webster et al.; U.S. Pat. No. 5,363,175 issued to Matysek; U.S. Pat. No. 5,682,247 issued to Webster et al. If the devices and configurations are not currently available, the FMC inquires, at step 610, whether the MFFA or other interface protocol combined with the programmability of the device enables the FMC to program the applicable devices to make each device and its specified configuration available. If yes, then the FMC returns to step 609. If not, then at step 611, the user is notified. If the user can and chooses to place the devices in the desired status, then step 612 indicates that the user implements these changes. Once implemented, the user signals that the changes have been made, and the process returns to step 609. If the user cannot or elects not to make the required changes, then the job is paused unless the user elects to create a different job model using different threads that avoid the constrained condition. To do so, at step 613, the user returns the process to step 105 shown on
Once it is determined, at step 609, that the required devices and configurations are available for the job model first selected or for a subsequent revised job model, then the FMC proceeds, at step 614, to specifically define where and how the various job segments are to be loaded into each of the devices selected for use. Some of this information may have been determined by the PMC processes described in relation to
Beginning at step 618, the control, tracking and integrity functions of the FMC begin. At 618, the FMC issues a Run Command to start the assembler/finisher processes. Alternatively, the FMC issues a Run Release signal to the operator that notifies the operator the assembler/finisher devices are in a ready condition. Once operations are initiated, the FMC, at step 619, monitors and tracks performance of the job and at step 620, issues appropriate control commands in response to tracking and performance data. Part of the tracking function uses the sheet counting capabilities of various devices to count sheets. The FMC similarly may track each job segment by its JSI as it moves through the process. In so doing, the FMC may issue calls for job segments to be loaded into devices in sequential order, e.g., issue orders to refill bins even before “bin empty” signals are generated or orders to empty bins filled with completed products or job segments. The FMC may also be in contact with performance of each device and may issue commands to adjust feed rates in order to maintain feed sequences within optimal ranges. The FMC may also monitor consumption of supplies such as binding materials and issue calls for reloading of such supplies when appropriate.
Integrity and control functions are indicated at steps 621-625. At step 621, the assembler/finishers are programmed to send to the FMC jam or job stop notices. The FMC then coordinates appropriate pauses in other devices dependent upon the jammed or stopped device. At step 622, the FMC interrogates the stopped or jammed device for error analyses. At 623, the FMC issues instructions to the operator. These instructions may as simple as informing the operator which device is the cause of the problem or might be as complex as providing full recovery instructions. At 624, the FMC verifies whether the jam or stop conditions have been removed. If not, then the sequence returns to step 622. If the conditions have been removed, then the FMC at 625 issues restart commands which may include reloading and reconfiguration commands to the operator and/or devices. Once restarted, the FMC returns to step 621 where the process continues.
At step 626, the FMC maintains integrity data. Based upon count data and job segment status data obtained in steps 619 and 620 plus the stop and jam recovery data from steps 621-625, the FMC tracks which sheets have been lost, destroyed, or are unaccounted for during the assembler/finisher process. The FMC also tracks which job segments or finished products may contain missing sheets based upon the counting and tracking data. Based upon this integrity data, at step 627, the FMC issues instructions for additional printing and/or assembler/finisher operations. These instructions could be automatic to the appropriate devices or may be instructions to the operator regarding manual reprogramming of certain portions of the job. One advantage of having an FMC that is capable of tracking even complex jobs through all parts of the assembler/finisher operation is that there is less incentive to print extra copies of each document component, thereby saving printing and inventory cost. The lowered incentives result because the FMC's ability to track job segments and sheets within job segments enables operators to more precisely know when and where defects have occurred.
At step 628, the FMC sends its tracking and integrity data to a central database such as the VFJTDB in order that a record of the job performance be kept. This step 628 will occur upon completion of the production run but could occur at any interim step. The PMC or other controller can use this data to account for the number of completed finished units, the amount of wasted sheets, time for production, and any other criteria that is desired to be monitored and recorded. Lastly, at step 629, the FMC automatically updates the VFJTDB concerning any new capability and constrain data relating to the devices. Such data may include reliability data, out-of-service data, new information regarding feeding constraints, etc. In sum, by breaking an assembler/finisher job into trackable job segments, the FMC enables the systematic control and integrity monitoring of offline assembler/finisher devices that until now have only minimally been digitally connected to each other or to devices such as printers.
An embodiment of key portions of software for the present invention will now be described. As described above in relation to the VFJTDB, each job may be comprised of an indeterminate number of document components and/or job segments. This indeterminate feature necessitates software algorithms that do not use predefined limits and boundaries, such as static memory buffers. Instead, the software algorithms recursively search the job model in the VFJTDB or other database based on a job key sequence. The job key sequence is provided from a data base record related to an individual job segment. By using a Microsoft Visual Basic 6.0 Predefined TreeView Component, the “Node Key” is constructed and stored using the job key sequence. This allows the user to select a node on the graphical display in the form of an icon and for the job sequence key to be retrieved in the form of the “Node Key”. The data base job model can then be recursively searched to facilitate processing requirements.
The following software demonstrates the recursive algorithm used to build the graphical TreeView representation of the physical product being built. The Node Key is constructed as the sequence of parent node keys. Any time after the node icon is selected, the Node Key can be accessed and used to efficiently locate the Node in the over all job model. This subroutine builds the tree from the root down by recursively calling itself and stops at each branch of the tree when no more children exist. The advantages of using this algorithm are:
This software code is as follows:
Another algorithm of the FMC portion of the present invention presents a subroutine that recursively calls itself to check that all Nodes in the tree are in a required state. Every Node in the entire job model tree is checked until one is found not in the ready state. For instance, the finishing equipment may be checked to see if each relevant bin is in the LOADED state. The function CheckSegments in the following algorithm returns a TRUE or FALSE value. The actual purpose of this subroutine can be easily modified by simple substituting a new function in place of CheckSegments. This allows this algorithm to be cloned and used for a number of purposes in the FMC.
The advantages of using this algorithm are:
An example of the software follows:
Turning now to
The DCW also prompts the user to enter whether or not the component is Variable Component. A Variable Component is a component whose image data will change from one copy of the document to the next copy of the document in the print job. A Static Component one whose image data will not change from one copy of the document to the next copy of the document in the print job. If the component is designated as a Variable Component, the user would have to designate a form file name and a data file name. All of this data would be stored in a database.
The DCW allows the user to designate whether any document components are External Components or whether all components are to be generated from an image data file. An “External Component” is one that is produced or printed through some other process but is not to be printed as part of this job. If designated as an External Component, then the DCW prompts the user for an integrity descriptor for the preprinted document component. The integrity descriptor is entered or read from a file if the user enters the integrity descriptor file name. All of this data is stored in a database.
Turning now to
This GUI of the present invention provides detailed information required by an operator who has no previous knowledge of the document to be constructed by the finishing equipment. The interface provides information ranging from a simple job overview to very detailed component status information. Information is presented to the operator describing the product and each of its components. The operator is also guided through how to load and operate a variety of finishing equipment. The GUI also permits the operator to interact with a VFJTDB or other database. The GUI is designed to enable the user located at the finishing equipment location to both run and load the finishing equipment and also to stage jobs. This user interface can also be used to facilitate a materials packaging task at the output location of the finishing device(s) or printers. For example: Machine operators could use this GUI to assist in palettization of boxes of output being shipped to other locations. The GUI can also be used at the printer output location for the purpose of packaging segments to be transported to a remote finishing location.
Turning now to
Turning now to
Use of the GUI of the present invention is typified as follows: First, a user scans a Job Segment Identifier Sheet (JSIS) or otherwise enables the system to determine the JSI for a job segment using the procedures described above. As described above, the PMC, working in conjunction with the VFJTDB or other database, is able to reassemble the job model and all of its nodes from a single JSI. Once the job and all of its nodes have been identified, the PMC, FMC, or other terminal can create the Job Assembly View for the job if the user selects “Segment Notification”.
Second, the user can view a status list of jobs in a standard combo box and pick which job is desired to view.
Third, the user will be able to edit the Job Assembly View graphical tree by using a tool box drag and drop action. For example the user may add or take away components from the product.
Fourth, an unlimited number of Job Assembly View windows can be displayed. This feature will be useful for staging jobs for latter processing.
Fifth, the main form of the GUI will display the job status, which is the printer and/or assembler/feeder device queue status.
Sixth, segment identifiers such as JSICs may be displayed and edited by using the keyboard.
Seventh, when a user requests that a job be run, the System software (which may reside in the PMC, FMC, both or other clients) will direct the GUI to display a status check of each job segment and will notify the user should there be missing or incomplete job segments. This feature of the GUI was described above in relation to the FMC.
Eighth, a system diagnostics form will be enabled and accessed from the main form.
Ninth, the type and level of information for every node or level of the job model may be selected by the user, including, without limitation, information relating to the job node, document node, document component nodes, job segment nodes, etc.
Tenth, the product tree representation shown by the Job Assembly View of the present invention is unlimited in size and the number of levels . For example, the highest level could be a pallet of boxes filled with a variety of documents, books, and other objects (such as CD ROM disks ) while the same Job Assembly View tree could have a lowest level comprising a single page of a signature book. As described above in relation to the PMC, specific PDLs will be associated with such sheet and can be identified and extracted from the Job Assembly View tree GUI.
In sum, what has been presented is a system for electronic management and control of a wide range of finishing processes characterized by input from multiple production operations and equipment that, depending upon the job, may be variably applied to work pieces that themselves are highly variable between different jobs. The present invention has been demonstrated in relation to printing and finishing operations for printed documents. The principles of the present invention, however, apply to such production and finishing systems as, without limitation, textile production (which may include printing, cutting, sewing, and finishing), packaging operations for various consumer and industrial products, and printed wiring board production, etc. The present invention is particularly applicable to many operations where processes for production of work pieces are managed separately from processes for finishing and packaging of such work pieces.
Among the advantages demonstrated are:
It is, therefore, evident that the present invention fully satisfies the aims and advantages set forth above. While the invention has been described in conjunction with several embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications, and variations as fall within the spirit and broad scope of the appended claims.