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.
At 05:16 AM 6/26/97 +0900, Fumio Nagasaka wrote:
>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 genesis@hd.epson.co.jp
>
>-----Original Message-----
>From: PJohansson@aol.com [SMTP:PJohansson@aol.com]
>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
>
>pjohansson@aol.com
>
>************************************************************
>In a message dated 97-06-19 00:17:33 EDT, DMitchell@ti.com (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
>
>pjohansson@aol.com
>************************************************************
>In a message dated 97-06-22 01:27:36 EDT, DMitchell@ti.com (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
>************************************************************
>
>
>
>
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