erratic behavior--Help!

[Ellen Reddick]

Nothing is easy! Now, the IT guy tells me he cannot install 32 bit driver for the Zebra printers on new 64 bit print server. The PBCC 6 is 32 bit code sending ZPL (Zebra Programming Language) data which prints out as jibberish on the labels. I don't know enough about the IT end of things to even make suggestions.

[Bud Durland]

Nothing is easy! Now, the IT guy tells me he cannot install 32 bit driver for the Zebra printers on new 64 bit print server. The PBCC 6 is 32 bit code sending ZPL (Zebra Programming Language) data which prints out as jibberish on the labels. I don't know enough about the IT end of things to even make suggestions.

We print literally thousands of labels a day to network attached Zebra printers via PB/Win apps. I installed the 32 bit drivers on our 64bit Win2012 server, so suspect your IT guy needs to revisit that. We've found that the 'ZDesigner' flavor of the drivers works best, and if you are sending ZPL, the driver has to have 'pass through mode' enabled (and your code has to wrap the ZPL in the passthrough code). Without that, you will get gibberish.

Whenever possible, I buy the Zebra printers with the embedded print server, then define that as an IP printer on the client.

[Ellen Reddick]

Thank you Bud Durland! I will pass that along.

[Michael Mattias]

I am glad this issue is solved, or at least well on the way to resolution.

I'm glad this thread's time has come and gone because; frankly, I was a little worried when I saw the thread title "erratic behavior--Help!" this was going to be a complaint about one or more of our members.

MCM

[Steve Hutchesson]

He he, we have more enlightened management these days and I have never got a complaint about "Fluzi (Ab)user" yet so common sense seems to have prevailed. Strange what happens when most people have a sense of humour.

[Albert Richheimer]

Well, when I put in the sleep statements, it fixed the labels. No, there was no garbled data, just missing labels, although in every case, the last label was printed correctly. How do I correct a missing handshake?

The garbled data was just a thought – but this applies more to old-fashioned line printers, when data is lost on the way. The Zebra language interpreter might skip all labels that are incomplete, so you won't see garbled labels, you just encounter missing lables. What does the ZPL manual say about malformed label data?

Re handshake: You won't be able to do anything about the hardware level. This is a matter of the printer driver. BTW, how is the lable printer connected to the server? Ethernet, USB?

[Bud Durland]

What does the ZPL manual say about malformed label data?

A ZPL stream begins with a "start command" and end with an "end command" (I don't recall them off the top of my head). Generally, if either of those is missing, you get nothing. Nearly everything you put on a label in ZPL is a "field" or "barcode". If any of the commands for laying out the elements is malformed, the element is skipped.

[Ellen Reddick]

Major problems with printing to Zebra printers. Each customer service person has a laser printer and a Zebra printer attached to her computer. IT guy (hereafter called Calvin) has installed zebra designer driver (with passthrough checked) on each new Win10 computer. I am using PBCC6. On some orders, perhaps 15 out of 30 labels print successfully before it stops. On small orders all print correctly most of the time. If they go back to old PBCC4 code running from 16bit XP virtual machine using the exact same code to generate the same order's labels and use the old driver, all 30 print correctly. So, both versions of the program generate the same ZPL data, indicating it is not the code being sent but the driver. The Zebra printer salesman (who seemed to know his stuff) was on site today working with Calvin. Together they tried every driver available--never achieved success. Incidentally, the program gives the option to screen view the labels. These can then be printed to the Zebra by choosing Zebra in the dropdown list of installed computers. All labels in the file print just fine. I tried just sending this rendition of the labels straight to the Zebra from the program but it wouldn't print.

Hoping someone out there has run into similar problems and can tell me their solution.

[Bud Durland]

Major problems with printing to Zebra printers. Each customer service person has a laser printer and a Zebra printer attached to her computer. IT guy (hereafter called Calvin) has installed zebra designer driver (with passthrough checked) on each new Win10 computer. I am using PBCC6. On some orders, perhaps 15 out of 30 labels print successfully before it stops. On small orders all print correctly most of the time. If they go back to old PBCC4 code running from 16bit XP virtual machine using the exact same code to generate the same order's labels and use the old driver, all 30 print correctly. So, both versions of the program generate the same ZPL data, indicating it is not the code being sent but the driver. The Zebra printer salesman (who seemed to know his stuff) was on site today working with Calvin. Together they tried every driver available--never achieved success. Incidentally, the program gives the option to screen view the labels. These can then be printed to the Zebra by choosing Zebra in the dropdown list of installed computers. All labels in the file print just fine. I tried just sending this rendition of the labels straight to the Zebra from the program but it wouldn't print.

Hoping someone out there has run into similar problems and can tell me their solution.

How are the Zebra printers connected to the PC's? If an order has 30 labels, is it 30 different contents, or 30 copies of the same label (except perhaps for a 'label x of y' type counter).

[Ellen Reddick]

Bud, I forgot to ask Calvin what cable connected the zebra. When I asked the office manager, she thought it was a parallel cable. I can find that out tomorrow. An order of 30 would have 30 different labels. If the order was for 30 of one item, there would still be 30 labels in the batch being sent, they would all just happen to be alike.

[Albert Richheimer]

If they go back to old PBCC4 code running from 16bit XP virtual machine using the exact same code to generate the same order's labels and use the old driver, all 30 print correctly. So, both versions of the program generate the same ZPL data, indicating it is not the code being sent but the driver.

I believe you are talking about 32bit XP, not 16bit.

In order to pinpoint the problem, did you try to run the newly (PBCC6) compiled program on the virtual XP machine? And, vice versa, what happens if you run the old (PBCC4) program on the Win10 machine? If the new program fails also on the XP system, it might(!) be a compiler problem. If the old program fails also on the new Win10 system, it is a communications / driver / handshake problem on the hardware's or the driver's side.

[Dale Yarker]

PBCC4 compiled to 32 bit executables.

The compiler itself was 16 bit in v4.01. I believe it changed to 32 bit at v4.03 (but repeat, the compiled programs were 32 bit)

Yes, how does PBCC 4.xx compiled code run on Win 10?

Cheers,

[Ellen Reddick]

I am waiting for the answer about current driver and if passthrough is checked. (I am in a different city and can't check these things myself). PBCC 4 was running fine on Win10 test computer when tested with small order--didn't give it a chance to fail on large order, not anticipating it stopping before all were printed. Now, new Win10 computer has replaced old in customer service locations. They are managing to get orders out by screen printing labels, then printing them to the zebra. Thank goodness I had included code to screen print! Anyway, as it is now set, neither PBCC4 (4.04) nor PBCC6 can print to the zebra. All other reports are printing on laser just fine. Plant 3 is still using PBCC4 and old driver and all is well there. Plant 2 gets there zebra output from the plant 1 entry and therefore is receiving printout via printing from the screen print at original order entry computer at plant 1. Confused? Me too. Will have more info for you this afternoon. Thanks for looking!

[Bud Durland]

Bud, I forgot to ask Calvin what cable connected the zebra. When I asked the office manager, she thought it was a parallel cable. I can find that out tomorrow. An order of 30 would have 30 different labels. If the order was for 30 of one item, there would still be 30 labels in the batch being sent, they would all just happen to be alike.

If the printer is indeed connected via a parallel port (somewhat rare these days) or serial port (less rare, especially with point of sale or industrial computers), you're task just became much easier. Using LPT or COM ports bypasses all the Windows driver issues, and simply shoots the data to the printer. This is the basic function I use for printing labels. It presumes that the 'LabelData' string has been constructed with the appropriate ZPL code. Substitute in your own 'DebugLog' function to get informational messages, or just remove the lines.

Forgive the formatting; how to get the post to follow what I paste is eluding me.

FUNCTION Printalabel(BYVAL LabelData AS STRING, BYVAL LabelPrinter AS STRING) AS LONG
'------------------------------------------------------
' send pre-constructed data to the label printer
'
' If the Label printer (LabelPrinter) is an LPT port,
' use LPRINT commands to send the data directly out
' the port
'
' if it looks like a "real" printer name, use XPRINT,
' and prepend / append the passthrough codes
'------------------------------------------------------
LOCAL tStr1,tStr2         AS STRING
  LOCAL IsfilePort          AS LONG
  LOCAL isLPTPort           AS LONG
  LOCAL isCOMPort, hComm    AS LONG

  IF UCASE$(LEFT$(LabelPrinter, 3)) = "NUL" THEN GOTO ExitPAL

  isLPTPort = %False
  isComPort = %False
IF LEFT$(UCASE$(LabelPrinter),3) = "LPT" THEN
DebugLog LabelPrinter + " appears to be an LPT printer; using LPRINT"
isLPTPort = %True
  ' Note - the server should have the 32 bit driver available
ELSEIF LEFT$(LabelPrinter,2) = "\\" THEN
DebugLog LabelPrinter + " appears to be a network printer; using LPRINT"
isLPTPort = %True
ELSEIF LEFT$(UCASE$(LabelPrinter),3) = "COM" THEN
LabelPrinter = TRIM$(LabelPrinter, ANY " :")
isComPort = %True
ELSEIF UCASE$(LabelPrinter) = "FILE" THEN
LabelPrinter = "C:\TEMP\LABELDATA_{t}.TXT"
REPLACE "{t}" WITH FORMAT$(Timer) IN LabelPrinter
    isFilePort = %True
ELSE
DebugLog LabelPrinter + " appears to be a direct printer; using XPRINT"
isLPTPort = %False
END IF

  IF isLPTPort THEN
    LPRINT ATTACH LabelPrinter
    tStr1 = LPRINT$
    IF LEN(tStr1) = 0 THEN
tStr2 = "Error {" & FORMAT$(ERRCLEAR) & "} connecting to the label printer (" & LabelPrinter & ")" & $CRLF + _
"Try reprinting the label; if the problem persists, contact the IT department"
MSGBOX tStr2,%MB_OKMODAL,"Printer Error"
GOTO ExitPAL
END IF

DebugLog USING$("LPrint # bytes of data to port &_, hdr: &", LEN(LabelData), LabelPrinter, LEFT$(LabelData,24))
LPRINT LabelData
LPRINT CLOSE
  ELSEIF isCOMPort THEN
'   Uses default factory serial parameters for the printer
hComm = FREEFILE
    COMM OPEN LabelPrinter AS #hComm
COMM SET #hComm, BAUD     = 9600   ' 9600 baud
COMM SET #hComm, BYTE     = 8      ' 8 bits
COMM SET #hComm, PARITY   = %FALSE ' No parity
COMM SET #hComm, STOP     = 1      ' 1 stop bit
COMM SET #hComm, TXBUFFER = 2048   ' 2 Kb transmit buffer
COMM SET #hComm, RXBUFFER = 4096   ' 4 Kb receive buffer
COMM PRINT #hComm, labelData
COMM CLOSE #hComm
ELSEIF isFilePort THEN
    TRY
      hComm = FREEFILE
      OPEN LabelPrinter FOR OUTPUT AS #hComm
      PRINT #hComm, LabelData
      CLOSE #hComm
    CATCH
      MSGBOX USING$("Error # writing file &", ERRCLEAR, LabelPrinter
      GOTO ExitPAL
    END TRY
WRITEAFILE LabelPrinter, LabelData
ELSE
    XPRINT ATTACH LabelPrinter
    tStr1 = XPRINT$
    IF LEN(tStr1) = 0 THEN
tStr2 = "Error {" & FORMAT$(ERRCLEAR) & "} connecting to the label printer (" & LabelPrinter & ")" & $CRLF + _
"Try reprinting the label; if the problem persists, contact the IT department"
MSGBOX tStr2,%MB_OKMODAL,"Printer Error"
XPRINT ATTACH CHOOSE, "AddrLabel"
END IF

'    DebugLog Using$("XPrint # bytes of data to printer &_, hdr: &", Len(LabelData), LabelPrinter, Left$(LabelData,16))
'
'   Change this to whatever passthrough codes you've defined in the driver;
'   these are the zerbra standard values
'
XPRINT "${" & LabelData & "}$"
XPRINT CLOSE
  END IF

ExitPAL:


END FUNCTION                 

[Albert Richheimer]

I am waiting for the answer about current driver and if passthrough is checked. (I am in a different city and can't check these things myself).

In addition to Bud's code... Once I was in the situation to send a virtual LPR stream (from a Novell Open Entrerprise Server in a virtual machine) to a real line printer - LPT1. First of all, you need to identify if there is a real printer attached to the system, such as is done in Bud's code above. For helping you (and Calvin) during your investigations, here is the PBCC code "test.bas" for checking the printers:

#compile exe
#dim all
function pbmain () as long
    local lTemp  as long
    local sTemp1 as string
    local sTemp2 as string
    for lTemp = 1 to printercount
        sTemp1 = printer$(name,lTemp)
        sTemp2 = printer$(port,lTemp)
        stdout "name = "+sTemp1
        stdout "port = "+sTemp2
    next lTemp
end function

On a system with only network printers, this will show up (my usual work place):


On a system with a real LPT this will show up (the server with various virtual systems, e.g. Novell etc.):

[Ellen Reddick]

Bud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value? Won't compile.

[Dale Yarker]

Bud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value?

No where, or made up for that bit of code.

MSGBOX is PBWin not PBCC, so it will give you problem anyway.

Two of the styles for MSGBOX are %MB_OK and %MB_APPMODAL, they're either ORed and that code not included in sample code, or it is a big typo of the style names.

(not a dumb question)

Cheers,

[Ellen Reddick]

The Zebra printers are 140iIIIplus printers -- obviously been workhorses there for a long time and I can understand that drivers that marry Win10 to such old equipment isn't top on Zebra's list of things to do. The Zebra expert (sales rep) and Calvin tried all drivers they could find including a Seagull driver. My client company is having such trouble getting out orders that Pres has had them put the ancient Win7 computers back on the Customer service desks and they are now running the PBCC4 version in a virtual XP window in order to smooth out operations. They have always run in a virtual XP machine to be sure hackers could not access company data--at least I think that was the reason. At the suggestion of the Zebra guy I removed the "${ }$" brackets and had the one Win10 computer still in service try to print to the zebra. Printed just fine without the brackets, although it stopped after 27 of the 60 labels in the job. I cannot put in Bud's code until someone tells me about the %MB_OKMODAL, but logic tells me that it isn't the PBCC6 program at fault or it couldn't be printing anything correctly. Also, the point where it fails isn't consistent. I still don't understand why sending the screen print of the labels to the zebra works--what does that do that I cannot do from my code? Also, thinking a timing issue must be the cause, I tried doing a

' SLEEP 3000
' XPRINT CLOSE
' SLEEP 1000
' XPRINT ATTACH zPrinter

after every 15 labels and that made no difference. There just has to be a solution somewhere, as I cannot imagine this is the first time this printer has been used on a Win10 machine.

[Dale Yarker]

I cannot put in Bud's code until someone tells me about the %MB_OKMODAL,

Bud put PBWin code. And there is no such thing as %MB_OKMODAL in PBWin either.

[Dale Yarker]

To convert Bud's code to PBCC replace the MSGBOXs with PRINTs and print the strings. Forget %MB_OKMODAL.