Re: Printronix IGP mode ignore Character?? -- MIDRANGE-L

In this case "Bottom of the final label" == "Top of the next label" so NO forms movement is desired. So the 0C we are getting skips one entire label.

Other than the typical positioning within the labels there are no LF or FF commands in the labels, that part is pure IGP.

This is an internal print file provided by the application.

The single OC is being generated by IBM i at the end of the spooled file. We had a problem open with IBM and they indicate there are two options: 1) Send sufficient OA (LF) characters they believe are needed to move to top of form (What they think is needed is WAY wrong as they count the IGP commands as lines.) 2) Send a single 0C (FF) command at the end of the file. You cannot select "None of the above."

These labels print perfectly (and have for years) on Printronix P5000 printers that are TWINAX attached. The primary difference here is Network attached.

- L

On 4/30/2012 10:09 AM, Stone, Joel wrote:

"The labels are IGP graphics language and print perfectly on the page,
ending with the printer at the bottom of the final label. "

If it is ending at the bottom of the label, then the final 0C should skip to the top of a new page, ready for the next label to print.

Is there a 0C at the beginning of the NEXT spool file also?

Does the IGP command initially do a FF with the next file? Cant that be removed?

Is it an externally-described printer file? Sometimes these will give you more control of the printer.

Try one with some simple commands, see if it does less 0C form feeds.

-----Original Message-----
From: DrFranken [mailto:midrange@xxxxxxxxxxxx]
Sent: Friday, April 27, 2012 5:48 PM
To: Stone, Joel
Subject: Re: Printronix IGP mode ignore Character??

The labels are generated by an RPG program, exactly one. The program
never does form feeds only line by line output. They print perfectly on
an older P5000 printers but those are twinax connected.

The labels are IGP graphics language and print perfectly on the page,
ending with the printer at the bottom of the final label. IBM i then
sends just one single 0C character (form feed in ASCII) at the end of
the spooled file. We can Hex Dump the output and see it at the printer
we can also see it in the Comm Trace.

This is categorically not an RPG output problem. The tangle comes
because the output of RPG is IGP commands and may be 40 to 50 commands
per label, one per line (by IGP requirements) while the label is a mere
15 lines tall. In fact you can see in the trace and the Hex Dump at the
printer that IBM i is in fact sending the 0C form feed after every
fifteen lines of IGP command output. While in IGP command mode the
printer simply ignores those 0C characters. However the final 0C comes
out right after the printer flips out of command mode and back to 'dumb
printer' mode. Of course that's where it is because IBM i makes sure
it's the very last thing sent. Unfortunately the printer is already AT
top of form having just completed the last label and so it skips to the
top of the NEXT label. With hundreds of jobs per night that's a lot of
wasted labels.

The printer is SUPPOSED to have an option where you set 'Ignore Mode'
and tell the printer what character to ignore. We want to change the
character IBM i is sending as Form Feed to something that will do
nothing (i.e. Bell) and then specify that character in the printer as
the 'Ignore character' but the printer ignores the ignore and since IBM
i is inserting those characters every 15 lines they makeamess of the labels.

We're hoping someone has a workaround or knows how to tell a printronix
printer how to honor the ignore character. Their documentation is
'exceptionally light' on the topic.

- Larry "DrFranken" Bolhuis

On 4/27/2012 5:37 PM, Stone, Joel wrote:

Sounds like a pgm is creating too many form feeds.

What is creating the spool file? RPG?

Is it just one pgm - or many?

Did you look at that pgm to remove any extra form-feeds?

Does it use an external printer file? If not, can you convert to external? Then you have a lot more control.

Possibly it is encountering an overflow condition AND issuing a form feed - that would waste a form.

Printers are tough on the iseries. But if the pgm is issuing an extra formfeed, it is going to be tough to get rid of it.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Friday, April 27, 2012 3:34 PM
To: Midrange Systems Technical Discussion
Subject: Printronix IGP mode ignore Character??

Setting up new Printronix P7000 printer with IGP Ethernet connected.
Prints just fine except it form feeds an entire label at the end,
wasting it. With hundreds of print jobs per day this is unacceptable.

Went into the WSCST object (WSCSTCONT132) and retrieved that. Changed
the Form Feed '0C' to 00 and applied it. Blows up the IGP string
wherever IBM i Inserts a form feed because 00 isn't valid there. Tried
other characters (07, OD, Space, ^) with the same results. IGP mode has
an 'Ignore Char' option so we set that to the character we're using. It
seems not to honor the ignore.

From the printer config page:

087 Ignore Char
088 Ignore Mode Enable
089 Select Char 94 /* 94 is 5E Hex */

Any ideas how to get IBM i to NOT DO ANY FORM FEEDS period. Or how to
get IGP to honor the ignore character?? This is driving us nuts.

Device Description:

CHGDEVPRT DEVD(PRTPICK4)
FORMFEED(*AUTOCUT) /* Tried Continuous, generates LOTS of
LF's */
TRANSFORM(*YES)
MFRTYPMDL(*WSCST)
PPRSRC1(*NONE)
USRDFNOBJ(*NONE)
USRDTATFM(*NONE)
USRDRVPGM(QGPL/TSPLPRD)
WSCST(QGPL/PRINTRONIX)

Our WSCST: (compiled to PRINTRONIX above)

:WSCST DEVCLASS=TRANSFORM.

:TRNSFRMTBL.
:INITPRT
DATA ='00'X.
:SPACE
DATA ='20'X.
:CARRTN
DATA ='0D'X.
:FORMFEED
DATA ='5E'X. /* 5E is the ^ Character. Not used
by IGP */
:LINEFEED
DATA ='0A'X.
:EWSCST.

iDeas??

- Larry "DrFranken" Bolhuis

________________________________________________________________________
This inbound email has been scanned for all viruses by the MessageLabs SkyScan
service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________