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.
Announcement
Collapse
No announcement yet.
erratic behavior--Help!
Collapse
X
-
Originally posted by Ellen Reddick View PostNothing 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.
Whenever possible, I buy the Zebra printers with the embedded print server, then define that as an IP printer on the client.Real programmers use a magnetized needle and a steady hand
Comment
-
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
Michael Mattias
Tal Systems (retired)
Port Washington WI USA
[email protected]
http://www.talsystems.com
Comment
-
Originally posted by Ellen Reddick View PostWell, 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?
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?„Let the machine do the dirty work.“
The Elements of Programming Style, Brian W. Kernighan, P. J. Plauger 1978
Comment
-
Originally posted by Albert Richheimer View PostWhat does the ZPL manual say about malformed label data?
Real programmers use a magnetized needle and a steady hand
Comment
-
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.
Comment
-
Originally posted by Ellen Reddick View PostMajor 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.
Real programmers use a magnetized needle and a steady hand
Comment
-
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.
Comment
-
Originally posted by Ellen Reddick View PostIf 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.
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.„Let the machine do the dirty work.“
The Elements of Programming Style, Brian W. Kernighan, P. J. Plauger 1978
Comment
-
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!
Comment
-
Originally posted by Ellen Reddick View PostBud, 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.
Forgive the formatting; how to get the post to follow what I paste is eluding me.
Code: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
Real programmers use a magnetized needle and a steady hand
Comment
-
Originally posted by Ellen Reddick View PostI 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).
Code:#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 a real LPT this will show up (the server with various virtual systems, e.g. Novell etc.):
„Let the machine do the dirty work.“
The Elements of Programming Style, Brian W. Kernighan, P. J. Plauger 1978
Comment
-
Bud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value? Won't compile.Last edited by Ellen Reddick; 16 Sep 2020, 01:31 PM.
Comment
-
Originally posted by Ellen Reddick View PostBud: Dumb question:
%MB_OKMODAL is an undefined equate. Where does it get its value?
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,Dale
Comment
-
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
Code:' SLEEP 3000 ' XPRINT CLOSE ' SLEEP 1000 ' XPRINT ATTACH zPrinter
Comment
Comment