Copier Paper Path Simulator

Since we are building a copier simulator, first we need to have a physical model of how the copier operates.  For our purpose, the copier consists of a number of components with materials (such as paper, cardboard dividers etc.) moving through them.  The diagram below shows a conceptual model of the paper path structure for a particular copier. Dashed lines indicate the paperpath – paths along which paper moves through the copier.

Copier Paper Path Component Description

The operation of each component is indicated below.  This description is primarily for understanding how copiers work, more details on the simulation are provided later.

• Feeder1, Feeder2 are paper trays which store paper and feed it on demand.  They each contain a motor, a sensor, and an output port through which they push the paper out.  The application software starts up the motor, and this causes the feeder to push the paper out.  The application software is also responsible for stopping the motor, otherwise the feeder will continue feeding sheets.  The trays have a capacity, in terms of how many sheets they hold.  They are loaded with a certain number of sheets, which they feed one at a time.  When all the sheets are exhausted, the sensor is triggered to indicate the Feeder is empty.  (We are not modeling the reloading of paper, for simplicity).
  
  
• FeedPath is a component representing the portion of the machine that moves the paper from the feeders towards the marker.  It contains a sensor and a motor.  The FeedPath’s sensor triggers when it senses the paper moving past it – this will happen a few milliseconds after it has been fed from the feeders.  Once the paper enters the FeedPath, it stays there until the application starts up the motor to move the paper out.   FeedPath has two input ports (from Feeder1 and Feeder2) and one output port, which is connected to PathMerger1, the next component down the line.
  
  
• PathMerger1 is a component which also has two input ports, one from FeederPath and another from the Duplexor unit.  It has one output port, the input to Marker.  All it does is take paper from either input port and send it out of the output port (a few milliseconds elapse between input and output).  It has no sensors or motors, and it cannot hold paper inside it.
  
  
• The Marker is the component that puts the image on the paper.  It has one input port, one output port, a sensor, a motor and a command signal.  A few milliseconds after the paper enters, the Marker’s sensor is triggered.  When the command is received from the application, the Marker transfers the image to the paper.  When the motor is started up, the paper goes out of the output port (if the motor is already on, the paper will just continue moving through).
  
  
• PathSplitter1 is a component with one input port and two output ports.  The command from the application decides which output port the paper leaves through (it controls a physical valve-type level which directs the paper one way or the other).
  
  
• The Duplexor is a component that flips the paper over.  It has one sensor, two motors, one input and one output port.  The paper moves into the duplexor and triggers the sensor.  When the application starts up the first motor, it moves into the long vertical area.  When the application starts up the second motor, it moves out of the area and towards PathMerger1, having flipped over in the process.  (This is a simplification of real copiers, where it is the same motor, but it can run in forward or reverse.  We have split that into two motors for modeling simplicity.  Also the design indicated will turn the paper around so that the printing on the paper will be upside down – real duplexor designs have a more complex mechanical design).
  
  
• The Fuser is a simple component with one input and output port, a sensor and a motor.  It retains the paper until the motor is started up to send the paper out of the output port.  Its function is to apply heat in order to melt the toner granules onto the paper.
  
  
• PathSplitter2 is basically identical to PathSplitter1.
  
  
• The Stapler has two sensors, a motor and a command signal.  The paperpath sensor and motor operate the same as for the Marker.  One difference is that the Stapler stacks the sheets arriving through its input port.  When the command is received, it staples all the sheets received so far.  When the motor is started, it sends out whatever it is currently holding.  Thus it is a component that receives many items through a single output port, combines them, and sends it out as a single item for the further processing.  The Stapler also has a consumable (like the Feeders).  A certain number of staples are loaded initially, and when they are exhausted, the empty sensor is triggered.
  
  
• The OutputBin simply stacks all the input it receives.

You are not simulating the scanner, which scans the images on the sheets to be copied.

Copier Configuration

This phase of the project will simulate the functioning of the above copier configuration.  It will plan and execute simple jobs, involving feeding sheets from feeders, moving them through each of the components in turn, stacking and stapling them if needed and delivering them at the output.  In this version of the simulator, paper movement is sequential i.e. a second sheet of paper will not be fed until the first sheet of paper has completed its movement and either been stacked at the stapler or delivered to the TopTray.

The initial machine state is predefined:

• Feeder1 starts with 5 sheets of paper, size “Letter”
• Feeder2 starts with 3 sheets of paper, size “Legal”
• Stapler starts with 50 staples.

Job Description

The description of a printing job can be described by the following regular expression

BEGINJOB [STAPLE] { SHEET { LEGAL | LETTER } string1 [ , string2] }+ ENDJOB

• The job is demarcated by the keywords BEGINJOB and ENDJOB.
• It includes the optional keyword STAPLE at the beginning of the job, to indicate that the pages must be stapled together.  Stapled jobs are delivered to the OutputBin, while unstapled jobs are delivered to the TopTray.
• A job consists of one or more sheets.  Each sheet includes a size specification, followed by either one string or two strings separated by a comma.  (For simplicity, each string is purely alphanumeric, with no whitespaces in between i.e. it will be one word).  The strings represent the images being transferred onto the sheet.  If a sheet has two images, then it must be duplexed i.e. it must pass through the duplexor, get reversed and have the second image transferred onto it as well.
• All tokens are separated by whitespace which could be spaces, tabs or newlines.

Below is an example job:

BEGINJOB

STAPLE

SHEET LEGAL side1content side2content

SHEET LETTER sheet2side1image

ENDJOB

Your simulator must execute this job correctly, feeding the first sheet from Feeder2, mark it with the first image, duplex it, put the second image on it, then stack it at the stapler.  Then it must feed the second sheet from Feeder1, mark it with its image, and send it to the stapler.  Then the stapler staples the sheets together and delivers the resulting job to the output bin.

Timing Aspects in the Simulator

Your simulation must also include timing aspects.  The copier has the following timing characteristics:

• Feeder1 sends the sheet to its output 10ms after its motor is turned on.
• The FeedPath sensor is triggered 30ms after the sheet enters the FeedPath.
• Once the sheet has reached the FeedPath sensor and triggered it, it stops until the FeedPath motor is turned on.  If it is already on, the paper keeps moving.  From that point, it takes 20ms to reach the FeedPath output.
• The PathMerger, path splitter take no time (they are conceptual components, modeling the levers/valves, they have no physical width).
• Marker sensor goes off 10ms after entry.  Image transfer happens 20ms after Marker sensor goes off.  Sheet stops at that point until Marker motor turned on.  It takes 20ms from that point to reach Marker output.
• Duplexor sensor goes off 30ms after entry.  Paper stops at that point until Motor1 is turned on.  It reaches the end of the vertical area 50ms later, and stops until Motor2 is turned on.  It reaches the output of the duplexor 80ms later.
• The Stapler sensor triggers 10ms after entry.  The sheet moves for another 20ms and then stops.  Stapling should only happen when there are no moving sheets.  Once the stapler motor is turned on, the stapled set takes 20ms to reach the output.
• For both the top tray and the output bin, the sheet takes 30ms to reach its final position from the time it enters.

Testing Your Simulator

To test your simulation, you will need to create some simple application software to drive it.   This software reacts immediately to sensor triggers, issuing the needed commands to the motors or devices at the right time, either immediately or at the instant that the devices need to perform their operation (where a delay is appropriate).  In addition to starting and stopping motors, the application software sends commands to certain devices: the Marker, Stapler and PathSplitters.  These commands are in the form of packets (like network packets – in a physical machine these would be actual packets sent over the link to the device) containing the command and parameters (if any).  You may invent your own format for the packets.

The output of your simulation should include a description of the job produced, together with event and event timing information.  For example, the job indicated might have output that looks something like this:

SET STAPLED

SHEET LEGAL

  Side1: side1content

  Side2: side2content

   0: feed Feeder2

  10: Feeder2 exited

  10: FeedPath entered

  40: FeedPath sensor triggered

  40: FeedPath motor turned on

  60: FeedPath exited

  60: PathMerger1 entered

  60: PathMerger1 exited

  60: Marker entered

  70: Marker sensor triggered

  90: Marker transferred “side1content”

 …

END SHEET

SHEET LETTER

   Side1: sheet2side1image  

   nnn: feed Feeder1

   …

END SHEET

END SET

General Information

• This project will be implemented in C++. It must run either under Linux on linus.se.rit.edu or Windows XP using g++ and the cygwin toolset.
• This is a simulator, so performance is not critical.  Evolvability is the key attribute.
• This is the first phase of this copier simulator project, with very basic functionality and several simplifying assumptions.    Your team plans to eventually expand this into a generic copier paper path simulator that will support among other possible features a variety of copier configurations, a wider assortment of components, and other performance enhancements available on high-end copiers.
• You are not being graded on minute details of the functional behavior.  As long as you broadly get the functionality right, that is enough.  You are graded primarily on quality of design and your implementation of it, how well you have achieved fitness for the purpose and your discussion of the rationale behind your design choices.
• You may rework the input and output formats, if so desired, as long as you provide documentation of these changes with your submission.

Assessment

Component	Percent	Comments
Presentation	20	Quality of the team's presentation of their product (including prototype demonstration).
Design Quality	50	Quality of the product design, including the degree to which it addresses the functional and non-functional requirements, the appropriate use of patterns, and adherence to proven software engineering design principles.
Design Diagramming	10	Quality of the design diagrams provided in the documentation and presentation. Elements of this grading will be readability of diagrams at 100% zoom and when projected during the presentation, provision of the necessary complement of diagrams (component, class, sequence, collaboration) to understand the design, and correlation between the diagrams and delivered code.
Implementation	20	Quality of the implementation in implementing the functionality of this simulator. An element of this will also be the adherence of the implementation to the design described in the diagrams and presentation, and to C++ coding style standards from previous coursework. Variations to these conventions must be approved by your instructor, and, if approved, must be adhered to by all team members.

Submission Instructions

1. A zip file named p362-unit2project-SSX.zip where SS is the section number and X is your team letter (lower case), where the zip file contains:
   1. The final design documentation will be submitted as a single Word document, including at a minimum:
   2. 1. Title information, including the name of your team, the name of your product, the date, and a list of all the team members.
      2. A short overview section describing the product and the features included.
      3. A UML class diagrams showing the main classes and interfaces in your design, along with inheritance (generalization), association, aggregation, and composition relationships. Include cardinality and role indicators as you deem appropriate to make the diagram clear. DO NOT include state or method information. You will need several class diagrams at different levels of abstraction and for different subsystems to completely document your design in a way that the reader can physically see and intelligently understand.
      4. Other UML diagrams (e.g., sequence charts, collaboration diagrams) to provide insight into the key dynamic characteristics of your design.
      5. A table summarizing the responsibility(ies) of each major class. A table of the object data defined by the class and the signatures of the methods in the class other than the accessors and mutators.
      6. A narrative outlining how the design reflects a balance among competing criteria such as low coupling, high cohesion, separation of concerns, information hiding, the Law of Demeter, extensibility, reusability, etc. This should include a discussion of the design patterns used to achieve this balance in the context of expected further product development.
      7. A short reflection on the two strongest and the two weakest aspects of your design.
   3. A copy of the final PowerPoint presentation.
   5. All the C++ source files required to compile, link, and run your project. A Makefile or script file to rebuild the system must be included.
   6. A Testing directory which contains a set of test input files and files with the associated output generated by the system when each test was executed. In this directory place a file place a spreadsheet TestIndex.xls that lists the name of each test input/output file and provides a short description of the test and the results. In TestIndex.xls tests that pass simply need to be labeled as such; if a test fails provide a description of the nature of the failure. Test output files will be annotated. After capturing the output generated by the implementation into a file open the file in an editor. Add annotations, i.e. comments, to the test output that will guide the reader to understand the results being shown. You can consider this annotation to be what you would say in your response to your instructor's question when reviewing test output, "Describe why you think this works/fails."