Subject: P1394> RE: [PP1394:00048] Printers and SBP-2

From: Fumio Nagasaka <[email-masked]>
Date: Thu, 26 Jun 1997 05:16:47 +0900

Peter, Danny, thank you for your helpful information.

* This sounds like unsolicited status to me; covered by SBP-2.

Actually some printers are needed to have reverse directional data transfer.
The reverse directional (printer --> PC) data flow is intended to designed to
service status. And we also would like to use reverse direction as pure
data flow. One of the good example is printer cluster which is consisted by
tow or more printers. When one of these printer has some trouble (due to 
lacks of paper or some other reason), other printer may perform printing
instead it.

For this sort of application, IEEE P1284.4 has capability to service reverse
data flow. Off cause this feature could be convenient even for status reporting
from a printer.

I think "Normal command block ORB's" are supporting full feature of reverse
data flow. Thus I believe SBP-2 can cover "Credit Base Transaction (CBT)"
of IEEE P1284.4.

I guess we may enclose our packets in data buffer associated by ORBs.
I have a question to implement SBP-2 for printers. Can we have multiple
fetch agent in a target device. I am curious whether we can enclose particular
packets those have a tag as a header of each packet, and also can have
a particular fetch agent which seeks special packets those have the tag.

If it is possible it could be helpful to make priority queue style linked ORBs.
-------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to [email-masked]

-----Original Message-----
From:	[email-masked] [SMTP:[email-masked]]
Sent:	Tuesday, June 24, 1997 11:37 PM
To:	pp1394 ML
Subject:	[PP1394:00048] Printers and SBP-2

Printer-reflector folk:

I've copied two messages that went back and forth between Danny Mitchell and
me. I thought they might be of general interest to the groups.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

[email-masked]

************************************************************
In a message dated 97-06-19 00:17:33 EDT, [email-masked] (Danny Mitchell)
writes:

<<Some of the discussions here indicate that a printer might need to be both
initiator and target??  The discussion is along the line of compatability
with the 1284 protocols that have been developed for printers.  I am still
investigating that,  I do not really see the need for this type of complexity
for sending status data.>>

I haven't been part of the discussions about the necessity for a printer to
be a "targiator" and fulfill both roles, so perhaps I am missing something
when I say I do ot see the need for that sort of complexity, either.

Is the printer you contemplate FUNDAMENTALLY different from the model
implemented by parallel SCSI printers today? If it's much the same, there is
no need for the printer to be anything other than a target. The SBP-2 status
mechanisms, both that associated with a particular ORB and unsolicited
status, should be adequate.

Regards,

Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA  94602

(510) 531-5472
(510) 531-2942 FAX

[email-masked]
************************************************************
In a message dated 97-06-22 01:27:36 EDT, [email-masked] (Danny Mitchell)
writes:

<<What about the case where the printer would want to send data back to the
host for status reporting ( paper out,  status of job,  etc.  ) and other
things that the printer group has defined using the 1284 specification  ( I
believe it defines bi-directional communication channels ).>>

This sounds like unsolicited status to me; covered by SBP-2.

<<Can I assume that a printer could provide "read" functions like a HDD
would?>>

You can provide any commands you want; for any one command the data can
either move from the initiator (e.g., PRINT) or to the initiator (e.g.,
REQUEST SENSE).

What are the addresses of the various PWG reflector(s)? I should be answering
these questions for the whole group.

Regards,

Peter
************************************************************

---

From: Danny Mitchell <[email-masked]>
Date: Wed, 25 Jun 1997 18:55:03 -0500

Nagasaka-san,

I think that SBP2 will work for your application just fine.  You could have
a printer cluster that has multiple logins for example,  or have a
controller that fetches each job and assigns the job to the appropriate
printer that is funcitonal and let that printer perform the fetch.

SBP2 spec has any combination of status sent back after each ORB or the PC
can pick the ORB that it desires status to be sent back.  Since the PC can
determine when/how much status is needed you should be able to get as much
or as little status as you need.  

>If it is possible it could be helpful to make priority queue style linked
ORBs.
Regards,  Danny Mitchell  ( Dallas, TX )

 BuS Solutions SW Manager
 www.ti.com/sc/1394 
 Ph: 972-480-3411     
 Fx: 972-480-3160     
 Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243