[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::postscript_printing

Title:Digital PostScript printers and their associated software
Moderator:REGENT::LASKOHER
Created:Wed Jan 24 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:7230
Total number of notes:31971

7093.0. "How to make OLCOT as default for NT LPS?" by NECSC::HARVEY (Printserver Support- America's Zone) Mon Feb 24 1997 12:22

    Customer bought a LPS32+ with the optional LCIT and LCOT options. They
    are booting it from a NT 4.0 server with the LPS 51-12I kit. He has set
    the printer up as a LPS32 Plus with a mailbox. He selected the output
    as mailbox1 to try selecting the OLCOT. However this does not work...
    
    He has setup LPR queues from the NTserver to print directly on the
    LPS32+. All these print jobs go to the top output tray, not the OLCOT.
    Their main goal for printing is to print PCL to the printer and would
    like to send the output to the OLCOT. 
    
    Have already addressed the lack of a PCL default to the OLCOT or
    Mailbox options (may never happen). I asked the customer to edit the
    registry data for the LPS network port and try setting the default
    there. Does not change the printers behavior.
    
    All ideas welcome.....
    
    Renis
T.RTitleUserPersonal
Name		DateLines
7093.1REGENT::WOLFTue Feb 25 1997 16:484
    That is a tough one Renis as I do not believe there is a PCL command
    for addressing the OLCOT.
    
       jeff
7093.2Need to set the OLCOT as postscript defaultNECSC::HARVEYPrintserver Support- America's ZoneTue Feb 25 1997 20:0622
    Jeff,
    
    
    	I know that the PCL selection of the OLCOT may never be
    resolved....
    
    However the problem is how to make the OLCOT a postscript default
    output tray for a LPS32+ booted from a NT 4.0 server? I had the
    customer edit the registry and change the /OutputType (Upper) to
    /OutputType (OLCOT). Then using the lps console from the NT server
    to reconfigure the printer. It claims that it loaded the defaults file
    again.... It is assumed that the registry data is what is loaded. 
    
    Our test is to send a postscript file to a LPD queue. It always prints
    to the top tray. So I asked the customer to stop the spooler and try
    reloading the defaults. Still fails. So the customer went and rebooted
    the NT server and the printer too. Still the output goes to the top 
    output tray.
    
    Ideas?
    
    Renis
7093.3working...REGENT::WIMBERGWed Feb 26 1997 11:045
    
    I'm testing out a theory. I'll try to get back to you today.
    
    Nancy
7093.4Works for me!7708::WIMBERGWed Feb 26 1997 18:1948
    


OK - I've done my testing and I was able to get the OLCOT to be the default
output tray for both PCL and PostScript.

First, I set the default output tray with a piece of PostScript code that I
sent directly to the printer. It looks like this:

	serverdict begin (yourpasswordhere) exitserver
        <</OutputType (OLCOT)>> setpagedevice

    [ I don't know how you send a PostScript job like this to a printer on
    NT, so you'll have to figure that out yourself, sorry]
    
After I did that all jobs that I sent to the printer went to the output stacker
unless I specified the output tray. That includes PCL and PostScript jobs.

Second, I set the default output tray with the defaults file and the reconfig
command. I changed the default output tray back to Upper first with a PostScript
file. Then, in the lpsdefaults.nodename file, I changed the /OutputType string
to OLCOT. Ran the mc lps$console nodename and did the reconfig command. Works
just like I expected!

You probably did these simple things but please check the following:

      o That the printer knows the OLCOT is installed. Use the config command
        of the remote console for the list of installed devices.

      o That the customer used the string OLCOT with all caps - As you know
        PostScript is case sensitive.

      o That the input tray is set to one of the supported paper sizes and 
        rotations for the OLCOT. They are a4 and letter in both orientations
        and legal, short edge fed only. 

    If I have to I can make one of the other engineers rconfigure my
    printer from NT but that'll take time.
    
    
    One other thing about the info you gave in .0, According to Tim Lasko
    there is not a LPS32+ driver for NT. So, they must be using the LPS32
    (level 1) driver - if I understand everything correctly.
    
    Keep me posted on the results
    
    Nancy
7093.5Thanks againNECSC::HARVEYPrintserver Support- America&#039;s ZoneThu Feb 27 1997 12:279
    Nancy,
    
    	Many thanks !!!
    
    	The custoemr is working another fire at the moment. He will be
    testing this code in a hour or so. I will let you know the status
    later.
    
    Renis
7093.6It worked however some questionsNECSC::HARVEYPrintserver Support- America&#039;s ZoneFri Feb 28 1997 12:0314
    Nancy,
    
    	That code stream did the trick! Customer can now print to the
    LPS32+ with a lpd queue and using PCL data and have it go to the OLCOT.
    His question is more related to someone who knows the LPS on NT kit.
    How can this be added to the WNT registry to load in the printer
    automatically?
    
    	Can this be added to printers resource registry section? The
    resource data is loaded at boot-time but not during a reconfig. So if 
    the customer wanted to change the output behavior they would be
    required to reboot.
    
    Renis
7093.7default output tray should be in setpagedeviceREFINE::KOSINSKIFri Feb 28 1997 13:216
    I don't have an OLCOT to try this, but in the registry under the
    printer, there is a "setpagedevice" section which has an "OutputType"
    key.  You should be able to doubleclick on this key and change it from
    "(Upper)" or "(Lower)" to "(OLCOT)".
    
    -Rich
7093.8Missing LPS32+ for WinNTREGENT::WIMBERGFri Feb 28 1997 13:4413
    
    The problem, as I understand it, is that OLCOT is not an option in the
    customer's case. Tim Lasko indicated that no drivers were made for WNT
    for the LPS32+. The drivers for the LPS32 should have work, it would
    just use the old level 1 - 4 setpapertray -  code. 
    
    What I don't understand is why the customer changing the 
    sysparams.nodename file to have outputtype OLCOT didn't work.
    I suspect one of two problems - typo (it must be OLCOT, all
    caps) or only thinking they reconfigured when they really didn't. 
    
    In any case, I'm glad it worked, I was beginning to doubt my
    understanding of the internals of the PrintServer 32+.
7093.9Here is what was triedNECSC::HARVEYPrintserver Support- America&#039;s ZoneFri Feb 28 1997 14:0727
    Rich,
    
    	I had the customer edit the registry and change the "OutputType" to
    OLCOT. It never made a difference. It always defaulted to the top tray. 
    
    Here is the order of things we tried: on a NT 4.0 server with service
    pak 2 installed:
    
    1. Edited the registry, changed the OutputTray to OLCOT
    
    2. Used the NT LPS remote console to reconfig the printer.
    
       2a. Tested the printer using a LPD postscript queue, output to top 
    
    3. Rebooted the printserver
    
    	3a. Tested the printer using a LPD postscript queue, output to top 
    
    4. Stopped and restarted the spooler, rebooted the printer
    
    	4a. Tested the printer using a LPD postscript queue, output to top
    
    5. Rebooted the NT server and rebooted the printer
    
    	5a. Tested the printer using a LPD postscript queue, output to top
    
    Renis
7093.10outputtype vs outputtrayREGENT::WIMBERGFri Feb 28 1997 14:4221
    
    
    Hi Renis,
    
    Just checking - in your previous reply (-.) you said -
    
    " I had the customer edt the register and change the "OutputType" to
    OLCOT. "
    
    then in the steps you wrote -
    
    "1. Edited the registry, changed the OutputTray to OLCOT"
    
    If the customer did the step instead of what you said in the first
    sentence, that would be the problem because outputtray is in the
    comment section of the file.
    
    Aren't these little things the most agravating!
    
    Nancy
7093.11Its OutputTypeNECSC::HARVEYPrintserver Support- America&#039;s ZoneFri Feb 28 1997 16:177
    Nancy
    
    	Just had a brain fade....
    
    	The registry entry is OutputType (OLCOT).
    
    Renis
7093.12A good ending......NECSC::HARVEYPrintserver Support- America&#039;s ZoneTue Mar 04 1997 14:2215
    Nancy,
    
    	The customer is now using the LPS32+ in his production environment
    and is able to print both PCL and PS files to the OLCOT. They now have
    replaced the HP printers that they were using for production. :-)
    
    As an interesting note he modified the start page and added your code
    stream to the beginning of the file. So when the start page prints it
    still thinks and prints out that the output is the top tray. When he
    prints it a second time or anytime after, its the OLCOT, that is until
    the printer is rebooted.
    
    Customer says many thanks. 
    
    Renis
7093.13but but but...REGENT::WIMBERGTue Mar 04 1997 15:3733
    
    That makes sense, because defaults (anything set outside the server
    loop) don't take effect until the next job. It is unusual for an
    exitserver job to contain actual mark producing code. BE CAREFUL,
    anything left on the PostScript stack or defined become part of the
    PostScript VM that is NOT cleaned up at the end of a job. Usually, 
    something like what I wrote would be sent to the printer alone.
    
    I would suggest the customer modified that code segment to use the
    level 2 startjob operator - it would be:
    
    	true (yourpassword) startjob   % outside the server loop
        pop                            % assume its worked, throw away the
                                       % result of startjob
        <</OutputType (OLCOT) >> setpagedevice  % set your output tray
                                                % persistently
        false (yourpassword) startjob  % return to inside server loop by
                                       % starting a new job
        pop                            % throw away the result again
    
       ....rest of the job ....
    
    
    
    
    Unlike the other code segment, this one is UNTESTED - may not work
    without modification.
    
    If the customer choosing to continue to use the other code with the
    startpage - there might be unpredictable problems.
    
    Nancy