bokonon@walt.cc.utexas.edu (Genghis Khan) (02/12/90)
Greetings! Please excuse my ignorance if this subject has been breached and solved already.... I work in a lab that has 10 Mac IIs and about 8 Mac Pluses. The IIs have 2 MB RAM and the Pluses 2.5. At the moment, we seem to have fallen victim to a bug i'd yet to see, until we started using 6.0.4. Basically, when printing to a direct connect Imagewriter, from any Mac, using any word processor (i haven't seen the error when using other programs) the first page of output will have an integer number at the top, left-hand corner, usually 16,xxx. The rest of the lines on the page will have double "o"s (stacked on top of each other), a pair on either end of each line. The only solution seems to be rebooting the Mac and turning the Imagewriter OFF and then ON. As i said, we are running sys 6.0.4 on all the machines and a Mac II file server. The file server is also running the Apple Print server program for a networked Laserwriter Plus. The INITs on the machines are fairly limited: Gatekeeper, Gatekeeper Aid, Moire CDEV & INIT, In Use CDEV and a few others, which seem to not be the cause after a little experimentation. Any help will be most gratefully appreciated! johan van Zanten (bokonon@snowwhite.cc.utexas.edu)
ih@doc.ic.ac.uk (Ian Harries) (02/15/90)
In article <24444@ut-emx.UUCP> bokonon@walt.cc.utexas.edu (Genghis Khan) writes: > > Greetings! > > Please excuse my ignorance if this subject has been breached and solved >already.... > > I work in a lab that has 10 Mac IIs and about 8 Mac Pluses. The IIs have >2 MB RAM and the Pluses 2.5. At the moment, we seem to have fallen victim to >a bug i'd yet to see, until we started using 6.0.4. > > Basically, when printing to a direct connect Imagewriter, from any Mac, using >any word processor (i haven't seen the error when using other programs) >the first page of output will have an integer number at the top, left-hand >corner, usually 16,xxx. The rest of the lines on the page will have double >"o"s (stacked on top of each other), a pair on either end of each line. > The only solution seems to be rebooting the Mac and turning the Imagewriter >OFF and then ON. > > (system details deleted ...) > > Any help will be most gratefully appreciated! > > johan van Zanten > >(bokonon@snowwhite.cc.utexas.edu) You do not say if these are ImageWriter Is or ImageWriter IIs. We run the CAP software on a Sun 3/280 here at Imperial DoC, including the ImageWriter spooler. (Side note to Alex Heatley in Wellington - I will be following up your isrv info request SOON !) The SAME phenomenon occured when spooling to an ImageWriter I, but not to an ImageWriter II. A look at the respective manuals provided the answer: The ImageWriter II has a superset of the ImageWriter I control sequences. These bytes cannot be interpreted by an ImageWriter I and so are passed on to be printed. Hence the spurious characters. e.g. (from my own experience) The ImageWriter II has a control sequence 'Set form length' as follows ESCAPE H nnnn 27 72 dddd In increments of nnnn/144 The ImageWriter I does not have this control sequence, so at the top of the first page of output on computer paper, "H1584" would appear (11" x 144 dpi). The same would almost certainly occur with ImageWriter clones, including the Grappler interface. Strictly, they should be referred to as ImageWriter I clones. Interestingly, using a serially-connected ImageWriter I with System Software 6.0.3 ImageWriter driver works fine. It is only the AppleTalk ImageWriter driver which generates ImageWriter II-specific control sequences. I can imagine the line of reasoning now - "only ImageWriter IIs can be networked, so we can use the extra control sequences in the AppleTalk ImageWriter driver. ImageWriter Is and IIs can both be used with a serial connection, so we must restrict ourselves to that set of control sequences BOTH can interpret with the (direct connect) ImageWriter driver". Not having used system 6.0.4, I do not know if it comes with a newer ImageWriter driver, but it certainly sounds to me as if the printer is getting control sequences it cannot cope with. Of course, I could be completely wrong... I look forward to hearing about it Ian Harries Department of Computing MicroComputer Support Officer Imperial College 180 Queen's Gate Janet: ih@uk.ac.ic.doc London SW7 2BZ DARPA: ih%doc.ic.ac.uk United Kingdom Uucp: ih@icdoc.UUCP, ukc!icdoc!ih Tel: +44 1 589 5111 x5052
casseres@apple.com (David Casseres) (02/17/90)
In article <1599@gould.doc.ic.ac.uk> ih@doc.ic.ac.uk (Ian Harries) writes: > Interestingly, using a serially-connected ImageWriter I with System > Software 6.0.3 ImageWriter driver works fine. It is only the > AppleTalk ImageWriter driver which generates ImageWriter II-specific > control sequences. I can imagine > the line of reasoning now - "only ImageWriter IIs can be networked, so we > can use the extra control sequences in the AppleTalk ImageWriter driver. > ImageWriter Is and IIs can both be used with a serial connection, so we > must restrict ourselves to that set of control sequences BOTH can > interpret with the (direct connect) ImageWriter driver". > > Not having used system 6.0.4, I do not know if it comes with a newer > ImageWriter driver, but it certainly sounds to me as if the printer is > getting control sequences it cannot cope with. > > Of course, I could be completely wrong... But actually you're partly right. That's exactly the logic of the AppleTalk IW driver, but the behavior doesn't sound to me like that of an IW getting invalid control sequences; more like a problem with the low-level serial communication, conceivably either a problem in the Serial Port Driver or a hardware problem. Also, note that the person with the problem said his IW's were "direct connect" so it wouldn't be the AppleTalk IW driver. Now, the direct-connect IW driver send out an interrogation command that has no effect on an IW I but gets a recognizable response from an IW II; if the response comes back within a specified interval, the driver emits IW II commands, otherwise it times out, decides the printer is an IW I, and emits only IW I commands. If there is a third-party spooler in use, this mechanism can break down (though some spoolers deal with it). Still, I don't think the problem is really a case of IW II commands being sent to an IW I. David Casseres Exclaimer: Hey!