TYSON@SRI-STRIPE.ARPA (Mabry Tyson) (10/11/86)
We just got a new Imagen 3320 installed today. It is a 20ppm Canon
engine with the standard Imagen interface (Image Processor). Ours
arrived with version 3.3 of the Imagen software (which wouldn't talk to
our 8/300 (now 2308?)) so we are going to have to live with 2 different
protocols for awhile...
The 3320 is 24"d x 27"w x 22"h and weighs something like 400 pounds. It
puts out a lot of heat (as compared to our old Imprint-10) and has a fan
that, while it might not be classed as noisy, is quite noticeable. It
uses dry toner. The 3320 has 2 input trays (and the Image Processor
will automatically switch between them if one becomes empty) with about
250 sheets each. The machine will take paper up to B4 size but we
didn't get anything but letter size cassettes. In the 3320, the paper
runs straight across the print engine and comes out face up.
Imagen offers an upgraded version of this printer called the 7320 that has
multiple output trace with face-down offset stacking, duplex printing (ie,
it reverses the paper internally) and a 2000 page input tray. It would
appear that the face-down stacking might be a separate option but I'm not
aware of Imagen offering it. It appears the duplex printing option (essentially
a whole new base) is required for the 2000 page input tray. The upgrade is
something like $10K. I believe the retail price of the 3320 is $23K or so.
My first impression of the output was that it was distinctly less dense
than what we were getting on the 8/300. Looking at some 10pt output,
I'd say it was visually 25% less dense. That made me suspect I had been
mistaken about its being a write-black printer. But Imagen's software
is for a Type-1 printer, same as the 8-300, while their software for the
write-white printers is different.
I turned up the density to 3 (1 being most dense, 9 being least dense)
and it looked only slightly better. That's the setting I believe is
about 25% less dense than the 8/300. (By the way, I *HATE* the generic
symbols that are used for idiots who can't read or by companies who figure it
is too expensive to make multilingual versions. The symbols on the density
control make no sense to me! (And, have you ever seen the sign beside the
highway warning you there are weaving drunks up ahead???))
My only guess now might be that the laser is focused more tightly and so the
dots are slightly smaller??? I did not that there was a paper sticker inside
the machine saying "300dpi". I wonder if it can go to a higher resolution??
The paper path is quite straight. We did manage one jam so far in the
600 pages we printed today (there were 600+ pages on the printer before
we got it). It was easy to clear. It appeared as though two pages had
fed at once. It looks like maintenance of this machine will be similar
to standard copiers.
There was one small glitch in installation. The fan (mentioned above) started
to bottom out on its plastic shroud. The installer at first thought someone
had moved the print engine by pushing on the back of it. (The sheet metal on
the back of the engine is much too thin!) But the contact was because of
vertical movement of the fan or the shroud so it was unlikely to have been
caused by pushing on the back of the engine. The installer was able to adjust
the shroud eventually.
Our old, venerable Imprint-10 is now retired with 1.1Meg pages. We had been
beating our 8/300 to death. The repairman indicated that its page counter (yes,
Virginia, it does have a page counter of sorts hidden in there) was over 130K
pages (up against its stop, I'd guess). (By the way, we were offered an
overhaul on the 8/300 for about $750. Sometime back one person complained
that no overhaul was available and another said he was quoted $2000+. I guess
those other complaints helped!) Recently we've become used to the 8ppm speed
and are quite impressed with 20ppm! I don't know whether it was that or the
speed-up of the ethernet code in version 3.3, but it seemed that the pages
were processed (ie, before printing) much faster.
I haven't yet gotten a chance to see if the ethernet-dies-in-6-minutes
bug/misfeature is still in version 3.3. It looks like there might be some
change there (but is it just a hack?) so there is hope.
I do not like the new header page format in 3.3. They reduced the size
of the USER, etc lines to just 14pt and filled the rest of the page with
such useful info as the "at," "window," "imagespace," etc... Another
change was to put the USER, etc lines in reverse order in which they
were in the @DOCUMENT line. I had to go through and change our spoolers
to cause the USER's name to come out first rather than last. Version
2.2 (and earlier) did it the other way around. (It does make some sense
though. The system-wide headers would usually come before the individual
job's headers if they were added around it. ie @document(<sys>)@document(
<particular output>))
Our Kellerman&Smith spooler for VMS doesn't yet know about a 3320 or version
3.3 and doesn't have such niceties as INPUTBIN built in. Worse yet, if the
style type has a DOCUMENT_HEADER("INPUTBIN NORMAL") and the user specifies
the DOCUMENT_HEADER("INPUTBIN LETTERHEAD"), it gets put ahead of the NORMAL
specification. That would work in 2.2 but loses in 3.3.
I was a little disappointed to find that when two letter trays were in
with one named "normal" and the other "letterhead", then if the "normal"
ran out of paper, the printer would switch to using the "letterhead"
tray. I hope Imagen will consider that a bug and not a feature.... (We
only have letter-sized trays. The documentation indicates that switch
will happen. I certainly hope that means that it won't happen if the second
tray has legal paper in it.)
I did see one failure where a connection was left open with no data
transfered (I opened one of the engine's doors just as a connection
opened). The connection was reported (by the console) to be processing
the document control info. I could find no way to abort that connection from
the console 15+ minutes later. All I could do was boot the machine (Are you
listening, Imagen??). I can't be sure that the problem was actually at the
Imagen end as opposed to the requestor's end but it was a very real problem
that the connection didn't go away.
We were one of the first to have the Imprint-10, then the 8/300, and now the
3320. Each time we have been pleased with our decision to go with Imagen.
(P.S. I would like to put my own fonts onto the Imagen system floppy.
Anyone know exactly how to do that? ie, what format do they have to be
in when shipped down to the printer? I wouldn't imagine Imagen would
try to prevent you from downloading your own fonts.... would they?)geof@apolling.UUCP (Geof Cooper) (10/14/86)
Some quick comments on Mabry's well written product overview. > ...version 3.3 of the Imagen software (which wouldn't talk to > our 8/300 (now 2308?)) so we are going to have to live with 2 different > protocols for awhile... Well, 2 different versions of the IMAGEN software. The protocols (TCP-IP, etc) are the same). > ....The machine will take paper up to B4 size but we > didn't get anything but letter size cassettes.... I'm sure you can order the bigger cassettes. We use them here in R&D. > My first impression of the output was that it was distinctly less dense > than what we were getting on the 8/300. The output from our in-house LBP-20 is about the same as our 8/300. The LBP-20 uses a new drum developed by Canon. It is the first laser printer to have that drum, and the drum was the last element of the printer to be debugged. I seem to remember that we found that copy darkened after the drum was "broken in" (a few thousand copies). But complain if it doesn't happen to yours in a month or so (I'm sure SRI will put enough copies through it in that time!), maybe there is some tweaking to be done. Anyway, it is a write-black machine (like the LBP-CX). Try it out on textures to really see this. > I haven't yet gotten a chance to see if the ethernet-dies-in-6-minutes > bug/misfeature is still in version 3.3. It looks like there might be some > change there (but is it just a hack?) so there is hope. The timer is still there. Its function is to make sure that the printer is not "bated" into diminished service by a host that sends data at a very slow rate (or a spooler that gets into a loop not sending data at all). Or maybe (if my memory serves me) you are referring to the misfeature in TOPS-20, Apollo's, some BSD's, etc., that causes a TCP connection to be reset if it is held in zero window for more than a certain amount of time? Tops-20's timer was 5 or 6 minutes. The apollos crap out after about 30 seconds. The printer now plays some tricks to try and get around this problem. Primarily, it forces the window open one byte every 25 seconds (as memory permits -- it can do this for a few hours) to convince such brain-damaged hosts that there is still some point in continuing the connection. Hope this improves things for you. > ....They reduced the size > of the USER, etc lines to just 14pt ... The 14 pt characters <<are>> harder to see. Actually, the reason we changed the size was that the old, larger font was so large it would not fit into the disk buffer area, so it was being re-read from floppy every page. We found that we could dramatically increase the speed of printing of job headers by using a smaller font. In the case of a 20 ppm printer, the delay caused by V2.2 job headers was about 3-4 LBP-20 page times. Needless to say, this changed the complexion of the printer at sites where most jobs contained 1-2 pages + header. V3.3 prints the headers faster. > ... and filled the rest of > the page with such useful info as the "at," "window," "imagespace," etc... I don't know whether you are being sarcastic, but we did find that customers were unable to debug problems with document control language (DCL) options, especially when a spooler or application was putting things into the stream for them. We added all this info to make this kind of debugging easier. > I was a little disappointed to find that when two letter trays were in > with one named "normal" and the other "letterhead", then if the "normal" > ran out of paper, the printer would switch to using the "letterhead" > tray. I hope Imagen will consider that a bug and not a feature.... (We > only have letter-sized trays. The documentation indicates that switch > will happen. I certainly hope that means that it won't happen if the second > tray has legal paper in it.) This is all "soft" -- check your manuals or call application support, there is a way to define what action the printer is to take. The default is to just switch trays when one is empty (this allows continuous printing). It is possible to arrange for a very flexible set of actions, including aborting or holding a job if the desired paper is not installed. > I did see one failure where a connection was left open with no data > transfered (I opened one of the engine's doors just as a connection > opened)..... (Are you listening, Imagen??).... Ooops, sounds like there's at least one bug left in the system. Probably that clever 3.3 TCP coaxed the other side into holding the connection open where 2.2 would have reset it. Sounds like there was a bug in interpretation (did the document have a legal DCL header, by the way?). I'll pass it on. > We were one of the first to have the Imprint-10, then the 8/300, and now the > 3320. Each time we have been pleased with our decision to go with Imagen. Thanks. Hope your 3320 lasts as long as your Imprint-10!! > (P.S. I would like to put my own fonts onto the Imagen system floppy. Call application support. I think that they can help you. - Geof Cooper IMAGEN
ss%wanginst.edu@RELAY.CS.NET (Sid Shapiro) (10/16/86)
In article <861011030720.7.TYSON@ELCAPITAN.ARPA> TYSON@SRI-STRIPE.ARPA (Mabry Tyson) writes: >We just got a new Imagen 3320 installed today. We got our just a couple of weeks ago. >I was a little disappointed to find that when two letter trays were in >with one named "normal" and the other "letterhead", then if the "normal" >ran out of paper, the printer would switch to using the "letterhead" >tray. I hope Imagen will consider that a bug and not a feature.... (We >only have letter-sized trays. The documentation indicates that switch >will happen. I certainly hope that means that it won't happen if the second >tray has legal paper in it.) In the Programmer's Guide Supplement in the section on Selecting Paper Trays, there is a document header keyword called "papermismatch" whose values include "hold" - this causes the printer to hold the job until an operator does something, e.g. changes the paper and releases or aborts the job. This is on a per-document basis. However, one of the configuration opitions is default document header parameters - presumably you could specify "papermismatch hold" as a default. Of course a held job hold up all jobs until is taken care of... -- Sid Shapiro -- Wang Institute of Graduate Studies ss@wanginst.EDU (ss%wanginst.CSNET@Csnet-Relay.ARPA) (617)649-9731 decvax!wanginst!ss