JMP Mail Archive: JMP> Re: Further Clarifications on counting

JMP> Re: Further Clarifications on counting

Tom Hastings (hastings@cp10.es.xerox.com)
Tue, 2 Dec 1997 12:38:10 PST

At 11:23 12/02/1997 PST, Harry Lewis wrote:
>There is ambiguity in our definition of attributes like
>impressionsCompletedCurrentCopy and currentCopyNumber in terms of how to
>synchronize them. Basically, the first is a trailing edge function, the
second
>is leading edge. This results in undefined states between the last impression
>of a copy and the first impression of the next copy.

In other words, if the currentCopyNumber advanced as the device starts
to work on the next copy, but the impressionsCompletedCurrentCopy remained
at the number of impressions in that copy, it would look like the new copy
had done a whole bunch of impressions at once.

So both attributes need to be changed on the same event as you point out.

>
>I would like to rename currentCopyNumber to sheetCompleteCopyNumber and make
>sure the definition clearly points out that all "currentCopy" attributes
>trigger off the SAME event, which is basically a sheet stacking. The
>sheetCompleteCopyNumber should start with a value of -1 or -2 to indicate it
>has no meaning until at least one sheet has stacked. When the sheet stacks
then
>the values impressionsCompletedCurrentCopy = 2 and sheetCompleteCopyNumber
= 1
>make sense. The sheetCompleteCopyNumber should always refer to the copy
number
>of the last sheet stacked and never point forward to some future copy
which is
>being worked on.

Sounds good.

How about changing the name from currentCopyNumber to stackedCopyNumber,
instead of sheetCompleteCopyNumber?

Also, why can't the value of stackedCopyNumber be 0 before the first
sheet of the first copy is stacked, instead of -1 or -2?

So the possible values for each are through time:

stackedCopyNumber impressionsCompletedCurrentCopy

0 0
1 1
1 2
1 3
2 1
2 2
2 3

The last values stay that way until the job is deleted.

>
>Harry Lewis - IBM Printing Systems
>
>