I am having difficulty in reliably implementing printing via a LAN
connection using port SLPR1. I am just throwing this query to the
newsgroup at the moment in case anyone has a quick answer.
It seems that at any time after boot, the first print attempt will
succeed. Subsequent print jobs will also succeed provided that the time
interval is not more than about 10-20 minutes. After some undetermined
period of inactivity, further attempts to print jobs will fail with the
port complaining that the printer is offline or out of paper (which is
not true). If I then reboot the system, any outstanding jobs immediately
print on reboot.

Any ideas?

On 01/04/2021 08:49, Peter J. Seymour wrote:
> I am having difficulty in reliably implementing printing via a LAN
> connection using port SLPR1. I am just throwing this query to the
> newsgroup at the moment in case anyone has a quick answer.
> It seems that at any time after boot, the first print attempt will
> succeed. Subsequent print jobs will also succeed provided that the time
> interval is not more than about 10-20 minutes. After some undetermined
> period of inactivity, further attempts to print jobs will fail with the
> port complaining that the printer is offline or out of paper (which is
> not true). If I then reboot the system, any outstanding jobs immediately
> print on reboot.
>
> Any ideas?

Well, following through with this problem, it has emerged that a likely
cause is that legacy print drivers cannot bring a modern printer out of
"deep sleep" mode. I suspect this is more a timing issue than a command
set one, but I don't know. A workaround is to only switch on the printer
to actually use it and switch off again afterwards. This is the way I
had always worked until recently, so it is only recently that I have
become aware of a problem. I will revert to my previous practice.

I would welcome any comments on other possible solutions.

Peter J. Seymour schrieb:
> On 01/04/2021 08:49, Peter J. Seymour wrote:
>> I am having difficulty in reliably implementing printing via a LAN connection using port
>> SLPR1. I am just throwing this query to the newsgroup at the moment in case anyone has a
>> quick answer.
>> It seems that at any time after boot, the first print attempt will succeed. Subsequent
>> print jobs will also succeed provided that the time interval is not more than about
>> 10-20 minutes. After some undetermined period of inactivity, further attempts to print
>> jobs will fail with the port complaining that the printer is offline or out of paper
>> (which is not true). If I then reboot the system, any outstanding jobs immediately print
>> on reboot.
>>
>> Any ideas?
>
> Well, following through with this problem, it has emerged that a likely cause is that
> legacy print drivers cannot bring a modern printer out of "deep sleep" mode. I suspect
> this is more a timing issue than a command set one, but I don't know. A workaround is to
> only switch on the printer to actually use it and switch off again afterwards. This is the
> way I had always worked until recently, so it is only recently that I have become aware of
> a problem. I will revert to my previous practice.
>
> I would welcome any comments on other possible solutions.

This maybe an explanation for your yet unknown printer with your yet unknown 'legacy
driver', whatever you mean by that.

I don't see such behavior with my different printers over the years (HP, Xerox, Tektronix)
and non of the different versions of the postscript driver over the last > 10 years.

Regards, Andi

On 06/04/2021 15:13, Andi B. wrote:
> Peter J. Seymour schrieb:
>> On 01/04/2021 08:49, Peter J. Seymour wrote:
>>> I am having difficulty in reliably implementing printing via a LAN
>>> connection using port
>>> SLPR1. I am just throwing this query to the newsgroup at the moment
>>> in case anyone has a
>>> quick answer.
>>> It seems that at any time after boot, the first print attempt will
>>> succeed. Subsequent
>>> print jobs will also succeed provided that the time interval is not
>>> more than about
>>> 10-20 minutes. After some undetermined period of inactivity, further
>>> attempts to print
>>> jobs will fail with the port complaining that the printer is offline
>>> or out of paper
>>> (which is not true). If I then reboot the system, any outstanding
>>> jobs immediately print
>>> on reboot.
>>>
>>> Any ideas?
>>
>> Well, following through with this problem, it has emerged that a
>> likely cause is that
>> legacy print drivers cannot bring a modern printer out of "deep sleep"
>> mode. I suspect
>> this is more a timing issue than a command set one, but I don't know.
>> A workaround is to
>> only switch on the printer to actually use it and switch off again
>> afterwards. This is the
>> way I had always worked until recently, so it is only recently that I
>> have become aware of
>> a problem. I will revert to my previous practice.
>>
>> I would welcome any comments on other possible solutions.
>
> This maybe an explanation for your yet unknown printer with your yet
> unknown 'legacy driver', whatever you mean by that.
>
> I don't see such behavior with my different printers over the years (HP,
> Xerox, Tektronix) and non of the different versions of the postscript
> driver over the last > 10 years.
>
> Regards, Andi

Tnaks for your comments.

I was trying to understand the general picture rather than dive in with
possibly misplaced specifics as I was not confident I had identified the
real picture. Some tedious and lengthy investigation seems to point to a
different cause (the printer) than at first seemed.

The printer in question is a Brother HL-L2360DN (a non-postscript
printer) and is using the Brother HL5170DN laserjet driver as that
seemed a suitable match in the absence of an exact match. The
combination works correctly except for the sleep issue.

I have also tried to use the CUPS system with a brlaser driver matched
to the printer, but I have been unable to get that working. For example,
plain text all comes out as one superimosed line, and more substantial
composed text seems to simply disappear between the print queue and the
printer. I suspect that the CUPS/brlaser combination is failing when
trying to convert from postscript to laserjet. I feel that I do not have
the time for seemingly endless investigation so I use my earlier
laserjet setup which works as stated.