How to add PCI Parallel card to Openserver 5
Chris Schmidt
PCI 3.3V LPT cards. Well I finally got them, and managed to get them
working in a Proliant ML350 with The latest release of United Linux.
Now, the actual machine they need to go in is the same Compaq Server
ML350 but in a tower config so should be the same hardware setup. I
need the two cards to be /dev/lp1 and /dev/lp2. The builtin parallel
is /dev/lp0 and is in use.
The cards used the following hardware setup:
builtin port: 0x378 irq7
card 1: 0x3400 irq 10
card 2: 0x3410 irq 5
How do I go about adding these to an Openserver 5.0.6 system? Will
there be any problems using the above addresses and irqs?
These cards are plug and play and there is no way to disable that, but
they should always get the above addresses and irq's from the system
because there will be no further hardware added to this server. It
would be nice if they had a legacy mode but they don't and Sunix is
the only one right now who is making 3.3V cards for the newer PCI bus.
Lava does not have one yet, they are all 5 Volt and will not work.
They worked fine in Linux, so should work fine in Openserver. I
didn't need any special drivers in linux, just
# insmod parport.c
# insmod parport_pc.c (or .o whatever) io=0x378,0x3400,0x3410
irq=7,10,5
And then add them as regular printers in cups.
Bela Lubkin
You should be able to do this with `mkdev parallel`.
Things you need to know:
- It supports at most three parallel ports. Your kernel is probably
already configured with three at addresses 378, 3bc, 278. Tell it to
remove the latter two.
- It will ask for an "end base address". It's not very important, but
give it 340f and 341f.
- The ports should be configured for the oldest/stupidest parallel port
style they support (if you have any control at all over this).
- You'll probably run `mkdev parallel` a total of 4 times -- two to
delete the old ISA addresses, two to add the new ones. Tell it not to
relink the kernel until the last time.
- The OSR5 parallel driver is not the slightest bit PCI-aware until
OSR507. By hardwiring the addresses and IRQs, you are relying on the
kindness of the BIOS to always configure them to the same address.
>Bela<
Tony Lawrence
> Okay, a while back I think I posted a message looking for some newer
> PCI 3.3V LPT cards. Well I finally got them, and managed to get them
> working in a Proliant ML350 with The latest release of United Linux.
>
> Now, the actual machine they need to go in is the same Compaq Server
> ML350 but in a tower config so should be the same hardware setup. I
> need the two cards to be /dev/lp1 and /dev/lp2. The builtin parallel
> is /dev/lp0 and is in use.
>
> The cards used the following hardware setup:
>
> builtin port: 0x378 irq7
> card 1: 0x3400 irq 10
> card 2: 0x3410 irq 5
>
> How do I go about adding these to an Openserver 5.0.6 system? Will
> there be any problems using the above addresses and irqs?
Bela addressed this directly, but I'll ask the obvious: wouldn't it be
easier just to buy an inexpensive print server with two or more ports?
Please note new phone number: (781) 784-7547
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
Chris Schmidt
> You should be able to do this with `mkdev parallel`.
>
> Things you need to know:
>
> - It supports at most three parallel ports. Your kernel is probably
> already configured with three at addresses 378, 3bc, 278. Tell it to
> remove the latter two.
Remove them in mkdev parallel if they are there correct?
> - You'll probably run `mkdev parallel` a total of 4 times -- two to
> delete the old ISA addresses, two to add the new ones. Tell it not to
> relink the kernel until the last time.
Why not relink the kernel until the last time? Just to save an extra
relink/reboot? Just wondering.
> - The OSR5 parallel driver is not the slightest bit PCI-aware until
> OSR507. By hardwiring the addresses and IRQs, you are relying on the
> kindness of the BIOS to always configure them to the same address.
>
> >Bela<
Yeah, there should be no further changes to this machines hardware so
those io's and irq's should stay.
Thanks for the help!
Brian K. White
> Chris Schmidt wrote:
> > Okay, a while back I think I posted a message looking for some newer
> > PCI 3.3V LPT cards. Well I finally got them, and managed to get them
> > working in a Proliant ML350 with The latest release of United Linux.
> >
> > Now, the actual machine they need to go in is the same Compaq Server
> > ML350 but in a tower config so should be the same hardware setup. I
> > need the two cards to be /dev/lp1 and /dev/lp2. The builtin parallel
> > is /dev/lp0 and is in use.
> >
> > The cards used the following hardware setup:
> >
> > builtin port: 0x378 irq7
> > card 1: 0x3400 irq 10
> > card 2: 0x3410 irq 5
> >
> > How do I go about adding these to an Openserver 5.0.6 system? Will
> > there be any problems using the above addresses and irqs?
>
> Bela addressed this directly, but I'll ask the obvious: wouldn't it be
> easier just to buy an inexpensive print server with two or more ports?
forget the cost, parallel ports are not nice things to saddle a
multi-user system with. network printers don't interrupt the cpu the
way parallel ports and non-intelligent serial ports do. Parallel ports
are there because it's part of the ix86 "platform", but although
several unixes run on this platform now, the platform still has a lot
of junk that really only belongs on the OS the platform originated to
service, DOS. That is, single user, one process at a time, it's ok if
the user just sits there and waits while the printer runs, they would
probably only do that anyways, no one will ever need more than 640k,
DOS. Another probable reason for the parallel port's existance is that
it is very easy to use, programming-wise. very simple, but therefore
very crude and very inefficient.
Bela Lubkin
> > - You'll probably run `mkdev parallel` a total of 4 times -- two to
> > delete the old ISA addresses, two to add the new ones. Tell it not to
> > relink the kernel until the last time.
>
> Why not relink the kernel until the last time? Just to save an extra
> relink/reboot? Just wondering.
Relinking replaces /stand/unix, renaming it to /stand/unix.old. A
second relink destroys the kernel you booted from, unless you take
evasive action which is pretty obvious, but would only add clutter to
"recipe" type text. Better just to recommend linking only once.
Destroying your original kernel is bad because you might have configured
the new kernel in such a way that the system is no longer bootable.
Less obviously, some system utilities need to look at the kernel, and
most are smart enough to go to unix.old if unix has been replaced. That
breaks down if neither name still refers to the booted kernel.
>Bela<
Bill Vermillion
>> > - You'll probably run `mkdev parallel` a total of 4 times
>> > -- two to delete the old ISA addresses, two to add the new
>> > ones. Tell it not to relink the kernel until the last time.
>> Why not relink the kernel until the last time? Just to save an extra
>> relink/reboot? Just wondering.
>Relinking replaces /stand/unix, renaming it to /stand/unix.old. A
>second relink destroys the kernel you booted from, unless you take
>evasive action which is pretty obvious, but would only add clutter to
>"recipe" type text. Better just to recommend linking only once.
>Destroying your original kernel is bad because you might have
>configured the new kernel in such a way that the system is no
>longer bootable.
And many - if not most of us - have been bitten by something like
that in the past. That's why I always copy a known working kernel
to some other name before I do much work. It also is a life-saver
when another SW vendor comes to a site and add something that
doesn't work.
It's the belt, suspendors and staples approach. It's like never
having too many backups.
Bill
--
Bill Vermillion - bv @ wjv . com
Chris Schmidt
> > easier just to buy an inexpensive print server with two or more ports?
>
> forget the cost, parallel ports are not nice things to saddle a
> multi-user system with. network printers don't interrupt the cpu the
> way parallel ports and non-intelligent serial ports do. Parallel ports
> are there because it's part of the ix86 "platform", but although
> several unixes run on this platform now, the platform still has a lot
> of junk that really only belongs on the OS the platform originated to
> service, DOS. That is, single user, one process at a time, it's ok if
> the user just sits there and waits while the printer runs, they would
> probably only do that anyways, no one will ever need more than 640k,
> DOS. Another probable reason for the parallel port's existance is that
> it is very easy to use, programming-wise. very simple, but therefore
> very crude and very inefficient.
The problem with network print servers is that they will not work with
the Real World Software that is in use on this machine. We have been
through this over and over with the Jetdirects (what it has now).
Before upgrading to a new server they were using ISA parallel cards
for the three printers. When we changed it over to the new server we
used jetdirect 300's. They are not "direct" enough for printing
forms, and doing page aligns in Real World. One Real World expert we
spoke with said we will never get the jetdirect's to work right with
Real World. He did mention something about an LPS-1 print server but
it required some software backend to work correctly. We chose the
path of least resistance which was to get some Parallel cards. Far
less expensive than a network print server and being that the users
are accustomed to waiting on the print jobs to complete it is no big
deal.
Thanks for the Help Bela and others.
Tony Lawrence
> br...@aljex.com (Brian K. White) wrote in message news:<60bd4c6b.02120...@posting.google.com>...
>
>>Tony Lawrence <to...@pcunix.com> wrote in message news:<asi3o7$hee$1...@pcls4.std.com>...
>>
>>>Bela addressed this directly, but I'll ask the obvious: wouldn't it be
>>>easier just to buy an inexpensive print server with two or more ports?
>>
>>forget the cost, parallel ports are not nice things to saddle a
>>multi-user system with. network printers don't interrupt the cpu the
>>way parallel ports and non-intelligent serial ports do. Parallel ports
>>are there because it's part of the ix86 "platform", but although
>>several unixes run on this platform now, the platform still has a lot
>>of junk that really only belongs on the OS the platform originated to
>>service, DOS. That is, single user, one process at a time, it's ok if
>>the user just sits there and waits while the printer runs, they would
>>probably only do that anyways, no one will ever need more than 640k,
>>DOS. Another probable reason for the parallel port's existance is that
>>it is very easy to use, programming-wise. very simple, but therefore
>>very crude and very inefficient.
>
>
>
> The problem with network print servers is that they will not work with
> the Real World Software that is in use on this machine.
Yes, they will.
See http://aplawrence.com/SCOFAQ/scotec7.html#netdevice
How can I make a device that will print to a network printer?
The ONLY problem you ever have is alignment masks, and for laser
printers you don't need any.
--
Chris Schmidt
> > the Real World Software that is in use on this machine.
>
>
> Yes, they will.
>
>
> See http://aplawrence.com/SCOFAQ/scotec7.html#netdevice
> How can I make a device that will print to a network printer?
>
> The ONLY problem you ever have is alignment masks, and for laser
> printers you don't need any.
Okay, update. Today I got the PCI cards installed and working.
However, we still have problems. The same problems as before with the
jetdirects. Seems the problem is not with the jetdirect boxes at all,
it is with either the way that Real World is printing to the spooler
or the way that the spooler is talking to the printers.
What is happening is that if someone prints a one page job it almost
always comes out right. However, if someone prints a more than one
page job, things like this are happening:
1. Extra lines appear at the top of the pages
2. Print jobs continue onto the next page then skip a bunch of lines
then start the next page. This happens on the dot matrix and the HP
laser 5.
3. Print jobs continue onto each other (one after the other without
telling it to start printing on a new page, it just starts printing
the next job at the end of the last job on the same page)
I am fed up with this and am willing to try whatever at this point to
make it work. Someone mentioned netcat in the past, but I have never
used it, don't know anything about it except it looks somewhat
complicated.
Tony, I looked over that url you sent me, looks like some good
information. Do you think that using the cat device will fix my
problems? Or do I just need to add something to the end of the print
filter?
The printers are all using the "standard" model when I set them up in
print manager. That is how they were setup on the old system. We had
problems with the "standard" that came with 5.0.6 so I copied the
"standard" filter from the old 5.0.5 system and same problem.
This has been a nightmare, and I fail to understand why it worked fine
on the old system (5.0.5) but is not working on the new (5.0.6)
system.
Tony Lawrence
>>>The problem with network print servers is that they will not work with
>>>the Real World Software that is in use on this machine.
>>
>>
>>Yes, they will.
>>
>>
>>See http://aplawrence.com/SCOFAQ/scotec7.html#netdevice
>>How can I make a device that will print to a network printer?
>>
>>The ONLY problem you ever have is alignment masks, and for laser
>>printers you don't need any.
>
>
> Okay, update. Today I got the PCI cards installed and working.
> However, we still have problems. The same problems as before with the
> jetdirects. Seems the problem is not with the jetdirect boxes at all,
> it is with either the way that Real World is printing to the spooler
> or the way that the spooler is talking to the printers.
>
> What is happening is that if someone prints a one page job it almost
> always comes out right. However, if someone prints a more than one
> page job, things like this are happening:
>
> 1. Extra lines appear at the top of the pages
What kind of "extra lines"? Headers???
>
> 2. Print jobs continue onto the next page then skip a bunch of lines
> then start the next page. This happens on the dot matrix and the HP
> laser 5.
That sounds like a mismatch of line length and is easily fixed.
>
> 3. Print jobs continue onto each other (one after the other without
> telling it to start printing on a new page, it just starts printing
> the next job at the end of the last job on the same page)
Not sending form feed.
>
> I am fed up with this and am willing to try whatever at this point to
> make it work. Someone mentioned netcat in the past, but I have never
> used it, don't know anything about it except it looks somewhat
> complicated.
It's not complicated at all but it would have nothing to do with these
problems. http://aplawrence.com/SCOFAQ/scotec7.html#getnetcat is about
as straightforward and simple as it can possibly get, and you probably
SHOULD be using this rather than parallel cards but again: it has
NOTHING to do with the problems you described.
>
> Tony, I looked over that url you sent me, looks like some good
> information. Do you think that using the cat device will fix my
> problems? Or do I just need to add something to the end of the print
> filter?
>
> The printers are all using the "standard" model when I set them up in
> print manager. That is how they were setup on the old system. We had
> problems with the "standard" that came with 5.0.6 so I copied the
> "standard" filter from the old 5.0.5 system and same problem.
>
> This has been a nightmare, and I fail to understand why it worked fine
> on the old system (5.0.5) but is not working on the new (5.0.6)
> system.
The problems are in the printer interfaces. You need to understand them
- http://aplawrence.com/SCOFAQ/scotec7.html can help with that. If
reading and editing interface scripts is beyond your capabilities, then
you need to hire someone else to help you : see
http://aplawrence.com/consultants.html
If you had copied the actual interface scripts rather than
model/standard, they probably would still be working fine.
Tony Lawrence
> Chris Schmidt wrote:
>>
>> 2. Print jobs continue onto the next page then skip a bunch of lines
>> then start the next page. This happens on the dot matrix and the HP
>> laser 5.
>
>
> That sounds like a mismatch of line length and is easily fixed.
>
I meant PAGE length. Although it could be lpi also.
It shouldn't take much work to see where the problem is.
Brian K. White
those symptoms are a generic sort of problem that can and does happen
to just about any/every application under the sun. not ven limited to
unix either.
first you have to take one step back and recognize the basic problem,
and and see that there are multiple possible solutions, pick one, and
then step closer again and focus on the nitty gritty of the chosen
solution.
the basic problem is that realworld is sending print jobs and it does
not know how many lines per page the printers can print.
just a few of the possible causes are:
- change to the printer itself. most printers can be set to print at
least 60 or 66 lines per page, and often there are even more possible
settings like 45, 55 or any arbitrary number. if the printer used to
print say, 60 line per page, and realworld was painstakingly adjusted
so everything lined up with that, but now the printer prints 66 lines
per page, you get some of the symptoms you describe. same goes if the
two numbers are reversed.
- change to the printer interface script. the interface script on the
old box may have been hand customized to send special escape codes to
the printer to put the printer into a particular mode of operation
before every print job. the new stock printer interface may not have
these tweaks. This would be perhaps codes to put the printer into a
particular non-default lines-per-inch setting.
- different sort of change to the printer interface script. the
printer interface script on the old box may have been tweaked to send
specific commands to the printer _after_ every print job, such as a
form feed (or similarrly, but not necessarily the same thing, a "page
eject"), printer reset, printer init, etc... or it may have been
tweaked to _remove_ such end-of-job reset codes. a common scenario is
to manually remove a form-feed command from the end of the interface
script for instance.
let's assume for now that realworld hasn't changed in any way from the
old machine. this is not a safe assumption, but we can table the
possibility until the others are eliminated.
sounds like maybe you need to _add_ form feeds between print jobs, to
get the printer to advance to the next top-of-page before printing the
next job, and/or, physically count the lines on an old report, are the
number of lines from top edge to bottom edge the same as what's
comming out of the printer now?
the fix may be as simple as editing a default value near the top of a
printer interface script to either enable or disable form feeds,
and/or set a particular lines per inch. or it may even be as simple as
moving a line-spacing lever on the side of the printer between 1 - 1
1/2 - 2 or changing a setting in the printers front-panel setup.
we can suggest the next action based on your answer to the above
question about the old vs current actual printed line counts.
Scott McMillan
Copied from /var/spool/lp/model?
The 'standard' models are identical between my 5.0.5 (rs505a, oss497c,
oss600a) and 5.0.6 (rs506a) systems. Take a look at the actual
interface that the printer is using
(/var/spool/lp/admins/lp/interfaces/<printername>) on your 5.0.5
system and see what changes have been made, if any. If there were
changes, apply them to the
/var/spool/lp/admins/lp/interfaces/<printername> interface on your
5.0.6 system, and see if that solves the problem.
>This has been a nightmare, and I fail to understand why it worked fine
>on the old system (5.0.5) but is not working on the new (5.0.6)
>system.
Scott McMillan
Chris Schmidt
Thanks for the help, I really appreciate it. I know little or nothing
about manually "forcing" printers to work. They have just never given
me problems in the past. I have been doing this for about 7 years and
have done mostly hardware and admin duties, I am no programmer. If I
was I probably would have figured it out by now. So thanks for
helping me.
Now, The Real World files "should" be untouched, as we just made a
backup of the rwc directory and copied it onto the new server.
Tony, you mentioned that I should have copied the "actual" interface's
not just the model/standard. I'm not sure what you mean. I am pretty
sure the file I copied from the old machine was:
/opt/K/SCO/Unix/5.0.5Eb/usr/spool/lp/model/standard
I looked at this file, it doesn't look too terribly hard to
understand. If there is another file somewhere I should have copied
then please let me know where it would be.
As for the questions about page length, I'm not sure how long the
pages were before, but I can probably get my hands on an old copy to
see. After seeing what it does, and taking into account what you guys
have suggested, I think the problem is that it is not sending a
"reset" command to the printer after completing a job. Or an "End of
Job" command or a "page break" command, forgive me for not being
familiar with the lingo. It doesn't print every page bad, just some.
Also my reason for believing this is because if they turn the printers
off, then back on before printing everything seems to come out just
fine.
Chris Schmidt
>
> Copied from /var/spool/lp/model?
>
> The 'standard' models are identical between my 5.0.5 (rs505a, oss497c,
> oss600a) and 5.0.6 (rs506a) systems. Take a look at the actual
> interface that the printer is using
> (/var/spool/lp/admins/lp/interfaces/<printername>) on your 5.0.5
> system and see what changes have been made, if any. If there were
> changes, apply them to the
> /var/spool/lp/admins/lp/interfaces/<printername> interface on your
> 5.0.6 system, and see if that solves the problem.
Thanks Scott! I'm going to look into that in the morning. So does
SCO not look to the model but rather copy the model "standard" to the
lp/admins/interfaces/<printer_name> ? I looked on a 5.0.5 server I
have here and it looks like an exact copy of the model/standard file.
I was not aware of that. Please forgive my ignorance. Printers
aren't my best subject.
Tony Lawrence
> Tony, Brian,
>
> Thanks for the help, I really appreciate it. I know little or nothing
> about manually "forcing" printers to work. They have just never given
> me problems in the past. I have been doing this for about 7 years and
> have done mostly hardware and admin duties, I am no programmer. If I
> was I probably would have figured it out by now. So thanks for
> helping me.
>
>
> Now, The Real World files "should" be untouched, as we just made a
> backup of the rwc directory and copied it onto the new server.
>
> Tony, you mentioned that I should have copied the "actual" interface's
> not just the model/standard. I'm not sure what you mean. I am pretty
> sure the file I copied from the old machine was:
>
> /opt/K/SCO/Unix/5.0.5Eb/usr/spool/lp/model/standard
>
> I looked at this file, it doesn't look too terribly hard to
> understand. If there is another file somewhere I should have copied
> then please let me know where it would be.
/usr/spool/lp/admins/lp/interfaces/printername(s)
One file for each printer,
>
> As for the questions about page length, I'm not sure how long the
> pages were before, but I can probably get my hands on an old copy to
> see. After seeing what it does, and taking into account what you guys
> have suggested, I think the problem is that it is not sending a
> "reset" command to the printer after completing a job. Or an "End of
> Job" command or a "page break" command, forgive me for not being
> familiar with the lingo. It doesn't print every page bad, just some.
> Also my reason for believing this is because if they turn the printers
> off, then back on before printing everything seems to come out just
> fine.
Yeah, that sounds like it. Most likely someone modified the interface
scripts a long time ago.
--
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Linux Skills Test: ftp://aplawrence.com/pub/linuxquestions.zip
Tony Lawrence
> Scott McMillan <sm...@usa.net> wrote in message news:<n7nuuug0p9bi920ra...@4ax.com>...
>
>>Copied from /var/spool/lp/model?
>>
>>The 'standard' models are identical between my 5.0.5 (rs505a, oss497c,
>>oss600a) and 5.0.6 (rs506a) systems. Take a look at the actual
>>interface that the printer is using
>>(/var/spool/lp/admins/lp/interfaces/<printername>) on your 5.0.5
>>system and see what changes have been made, if any. If there were
>>changes, apply them to the
>>/var/spool/lp/admins/lp/interfaces/<printername> interface on your
>>5.0.6 system, and see if that solves the problem.
>
>
> Thanks Scott! I'm going to look into that in the morning. So does
> SCO not look to the model but rather copy the model "standard" to the
> lp/admins/interfaces/<printer_name> ?
Yes. And then people often modify and forget it.
What I do is:
edit the /var/spool/lp/admins/lp/interfaces/<printername>
cp <printername> /usr/spool/lp/model/<printername>
/usr/lib/lpadmin -p <printername> -m <printername>
--
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Scott McMillan
/var/spool/lp/model:
SCO copies the interface that you defined when
creating the printer (in your case 'standard')
from here
/var/spool/lp/admins/lp/interfaces/<printername>:
into here. This is the file used by lp, so any changes
necessary would need to be made here.
We created a few of our own interface scripts, with unique names so as
not to confuse them with the stock SCO scripts. You may want to do
the same - Grab the
/var/spool/lp/admins/lp/interfaces/<workingprinter> from your 5.0.5
system, place that into /var/spool/lp/model/<RealWorldStandard> (some
name you'll understand) on your 5.0.6 box. When creating printers for
RealWorld, use the <RealWorldStandard> interface. Avoids confusion in
the future, unless someone makes changes in the
../admins/lp/interfaces hierarchy, and does not include them in the
model directory.
Scott McMillan
Chris Schmidt
understand what SCO does with them.
However, the files are identical from the old system to the new, even
in /usr/spool/lp/admins/lp/interfaces.
We have narrowed down the only problem it really has, which is:
After printing one job, the next job starts about 8 lines too far down
the page.
If they turn off the power on the printer, and turn it back on before
it each job it prints perfect.
So if there is a command to tell the printer to reset after completing
each job that should fix it. It does not mess up in the middle of a
job. And it actually straightens itself back out after printing the
first two pages or so even though the first page or two will be off.
So say you printed a 1 page job, if you turned off the printer before
you started, it will come out fine, same if you print a 50 page job
after turning off the printer and turning it back on. But, if you
print a second job without turning the printer off, the first page
will start about 8 lines from the top of the page, roll over onto the
second page, then about the third page it will straighten up and print
the rest of the job just fine.
Scott McMillan
>Scott, thanks for the help in finding the correct files and helping me
>understand what SCO does with them.
>
>However, the files are identical from the old system to the new, even
>in /usr/spool/lp/admins/lp/interfaces.
>
>We have narrowed down the only problem it really has, which is:
>
>After printing one job, the next job starts about 8 lines too far down
>the page.
>If they turn off the power on the printer, and turn it back on before
>it each job it prints perfect.
>
Sounds like the printer may be set to print < XX lines per page, and
the print job has XX or greater lines per page. Try setting lines per
page to 66 on the printer.
Are the printers new, or are they the _exact_ same ones that were
working fine on the OSR 5.0.5 system?
>So if there is a command to tell the printer to reset after completing
>each job that should fix it. It does not mess up in the middle of a
>job. And it actually straightens itself back out after printing the
>first two pages or so even though the first page or two will be off.
>
We placed
echo "\033E\c"
into our interface script to perform a soft-reset on our PCL printers
(HPLaserJets). Not sure what would be required for the dot-matrix
printers, that would depend on the model.
>So say you printed a 1 page job, if you turned off the printer before
>you started, it will come out fine, same if you print a 50 page job
>after turning off the printer and turning it back on. But, if you
>print a second job without turning the printer off, the first page
>will start about 8 lines from the top of the page, roll over onto the
>second page, then about the third page it will straighten up and print
>the rest of the job just fine.
Is there some printer setup within the application that has been
missed? Something to affect the number of lines printed per page?
Just a thought.
Scott McMillan
Chris Schmidt
> >it each job it prints perfect.
> >
> Sounds like the printer may be set to print < XX lines per page, and
> the print job has XX or greater lines per page. Try setting lines per
> page to 66 on the printer.
>
> Are the printers new, or are they the _exact_ same ones that were
> working fine on the OSR 5.0.5 system?
The printer is set to 60 lines per page, but like I said it only
messes up on the first page or two then it finishes the job (no matter
how many more pages) perfectly aligned. If the page length was off
wouldn't it mess up every page?
They are the exact same printers. No changes have been made to them.
> >So if there is a command to tell the printer to reset after completing
> >each job that should fix it. It does not mess up in the middle of a
> >job. And it actually straightens itself back out after printing the
> >first two pages or so even though the first page or two will be off.
> >
>
> We placed
>
> echo "\033E\c"
>
> into our interface script to perform a soft-reset on our PCL printers
> (HPLaserJets). Not sure what would be required for the dot-matrix
> printers, that would depend on the model.
A soft reset would probably do. The laserjet is an HPLaserjet 5. It
is using the standard printer interface, not the HPLaserjet, would
that command still tell it to perform a reset? In what section of the
interface script would I put that command to try it?
> Is there some printer setup within the application that has been
> missed? Something to affect the number of lines printed per page?
> Just a thought.
No, there is nothing in there as far as we or the software manual
knows about telling it page length etc... It's RealWorld 2000.
Chris Schmidt
> >
> > echo "\033E\c"
> >
> > into our interface script to perform a soft-reset on our PCL printers
> > (HPLaserJets). Not sure what would be required for the dot-matrix
> > printers, that would depend on the model.
In what section of the "standard" interface script could I place this
command to try it?
Scott McMillan
Well, looking at the stock 'standard' interface I see (around line
902)
<-------------------- Start 'standard' stuff ---------------------->
# WARNING: The standard output of the following loop is directed
# to $LPTELL, not the printer. To send something to the printer,
# direct it to channel 3. E.g. echo "output" 1>&3
#
# WARNING: Because this loop is the first in a pipeline, it is in
# a sub-shell. To propagate an exit code to the original shell,
# copy it into the file ${EXIT_CODE}.
##########
exec 3>&1
i=1
while [ $i -le $copies ]
do
<-------------------- End 'standard' stuff ---------------------->
I would try it before the 'while [ $i -le $copies ]' line, for
starters. (We don't use the 'standard' as our model, so I've not
tried this)
You may want to try it after the 'do', but that would perform the
reset before each copy, which may not be necessary.
Note the first warning above - You would want to use something like:
echo "\033E\c" 1>&3
Here's the snip from our interface (based on the 'dumb' model):
<-------------------- Start 'our' stuff ---------------------->
copies=$4
shift; shift; shift; shift; shift
files="$*"
i=1
echo "\033E\c" <------ This is our addition
while [ $i -le $copies ]
do
<-------------------- End 'our' stuff ---------------------->
Scott McMillan
mile
I am working with Proliant DL580 servers, and I need to get
PCI 3.3V LPT cards. Does anyone know where I can get them?
--
Posted via http://dbforums.com