🚀 go-pugleaf

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!