erratic behavior--Help!

[Dale Yarker]

Did you determine parallel, serial, USB or USB psuedo serial yet?

If Win 10 computers with USB to serial (or parallel) converters, they could be ignoring the hand shake line and over-running buffer memory in the printers.(new computers don't come with real ports anymore, just USB)

Cheers,

[Ellen Reddick]

So, how to combat over-running buffer memory? Sounds exactly like what is happening. Can long enough pauses (see my previous post) take care of this? I suspect they are using parallel converters.

[Bud Durland]

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

What Dale said. In my library of code equates, I define %MB_OKMODAL as an or (or +) of %MB_OK and %MB_APPMODAL

I thought I had groomed out the non-standard stuff. Maybe I've been using that so long, I just forgot. Sorry for the confusion.

[Bud Durland]

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.

The pass through codes come into play when your print stream is being processed by the printer driver. When you can connect via a serial or real parallel port, the ZPL code is going directly to the printer. This is in the fragments in my code that start with IF isLPTPort and IF isComPort. But, if you look at the block that uses XPrint, you'll see this:

 XPrint "${" & LabelData & "}$"

The code wraps those pass through codes ("${" and "}$") around the ZPL. With the pass thorough enabled in the driver's advanced settings, your ZPL stream is passed unmolested by the driver to the printer. Without those pass through codes, the printer driver intercepts the ZPL and tries to print it as text, which produces gibberish -- well, gibberish to most people, but those of us who've had to wrangle these printers over the years can almost read it

In an earlier post, I think you mentioned parallel converters. I've never had good luck with them. Most of our Zebra printers are connected either by serial cable (the most reliable), or we put a cheap print server on the parallel port of the printer, and set it up as an IP printer on the windows station. In the latter case, we install the ZDesigner drivers, enable the pass through and they work flawlessly. With the serial port connection (and parallel for that matter), no driver is required at all.

[Ellen Reddick]

Don't know where to go from here. The very same code compiled in PBCC4.04 and PBCC 6 on the same computer do different things re printing. The PBCC4 prints all files correctly on both Zebra and HP. The PBCC6 cannot finish a long print job to Zebra or to HP Laser printer. They may run off 75 or so invoices on the HP Laser in a day, requiring printing 200 or so sheets of paper. On the new system, they can get through 30 or so sheets before it stops and they have to turn the printer off, back on, clean the buffer or ? and then it continues where it stopped, only to go through the same things another time or two to finish the print job. Running the older version, it finishes the job with nary a hiccup. I've been blaming the Zebra driver, but somehow begin to question if there can be something different in the files output by the two compilers or something I have yet to imagine. Any ideas greatly appreciated!

[Bud Durland]

I'll help where I can, but need some more information first. I want to make sure I'm clear on the environment. When you say "new system", is that the program compiled with PBCC6 on Windows 10 machine, vs. the "old system" which is the program compiled with PBCC4 on windows XP? Does the PBCC6 executable show these symptoms on the XP hardware, and/or does the PBCC4 executable behave well on Windows 10? In both cases, it would help to know exactly how the printers are connected.

All the programs we have at work are PB/Win 10. I talk to the label printers directly over serial (only occasionally using XPRINT), often in batches of 100 or mre. Laser chores I complete with a 3rd party library called Virtual Print Engine (VPE), which I highly recommend. I've not experienced the phenomena you are describing.

[Ellen Reddick]

Bud, thanks for your willingness to help. I will do my best to describe the setup. Easiest to describe is the secretary who prints the invoices. For 15 years she has been printing to local printer which is currently an HP Laser with I assume the proper driver for her current Win 7 computer. All employees were set up with an XP virtual machine on their Win7 computers from which both the old (PBCC4) and the new (PBCC6) are running accessing the data from a server. Old works, new has problems printing the whole job (same job, both programs running from the same virtual xp to the same zebra). Since printing to the HP has similar problems to those encountered printing to Zebra, it makes me think the problems are related although I cannot imagine there is any difference in the data stream to the printer for any given job. I live in another city and do most of my work remotely so I am at a disadvantage knowing all of the connectors. The fact that the computers and server are no longer supported by Microsoft is the reason for replacing all of the computers, server, etc. as well as my decision to move to a more modern compiler. Hence PBCC6 (baby steps! Besides they prefer the down and dirty data input environment). The idea was to have all of the new computers in place by Monday and run parallel for a couple of weeks to be sure all the kinks are out. Without the PBCC6 being able to print properly, they will have to rely on the old version. To answer your question about zebra connections: the one all the experiments were run on was on lptport (I think). Zebra guy and Calvin (IT) spent 5 hours trying various drivers and never got new version to print more than 15 in a job before it stopped. The old version had no problems. Keep in mind that the zebras are so old that Zebra hardly acknowledges them (140iIIIplus), but have never been a problem before this.

[Nick Luick]

Ellen post #1.

Have you tried running an older version of your compiled code on your Windows 10. From description your newly compiled code is failing, also when used on customers computer (Windows 7) XP mode. When did your Windows 10 last update.

Looking at specs for Zebra 140xiIII Plus its a 32 bit Risc processor and comes with parallel, serial, and USB ports, its XP unicode compliant.

https://midcomdata.com/zebra-140xiii...i-refurbished/

I'm thinking of corrupt disk area, virus, or WIndow's update. Do you have another computer to install PBCC4 on.

[Michael Mattias]

The very same code compiled in PBCC4.04 and PBCC 6 on the same computer do different things re printing.

The compiled code will not be the same.

But assuming the same main source code...
Do they use the same Windows Header files? Using different headers can result in different performance.. and if you don't do good error handling you probably won't find the problem easily.

[Ellen Reddick]

Customer has gone ahead installing all new computers and using PBCC4 code. They are double-entering (Win 10 and Win 7) just to be sure all works as it should. Zebras are now set up as network printers and are printing happily. The goal is still to transition to PBCC6 code, so I will have to solve the printer problems there. Michael, how do I find the Windows Header files? Please pardon the naive questions--it has been a few years since I was immersed in this stuff and the world moved on without me! Have to admit I am somewhat enjoying getting back into it--brain needed the exercise!

[Walt Decker]

look in PBCC60\WINAPI for pbcc6 headers and PBCC40\WINAPI for pbcc4 headers.

One thing you might try for comparison is changing the .inc path in pbcc6 to point to the pbcc4 headers.

To do that go to the Window menu item, click on options, then click the little square next to the inc file edit box.

[Bud Durland]

XP virtual machine[/B] on their Win7 computers from which both the old (PBCC4) and the new (PBCC6) are running accessing the data from a server.

Were I on-site, this is where I'd begin by taking the VM out of the mix. Using other apps (Matlab, some ladder logic stuff) in an XP VM on Win10, we've seen some goofy behaviour with the virtualization of COM and LPT ports. (yes, 'goofy' is the correct technical term), but not so much with network connected devices -- thought virtual networking and nat-ing can bring on it's own headaches. I still haven't heard how the printers are connected to the PCs. With respect to the HP lasers, are you using XPRINT?

(sorry for the delay, I was on vacation last week, and purposefully off the grid as much as possible)

[Joost Kant]

When you consider to port your software to W10 PC's, keep in mind that the LPRINT ATTACH command generates a Device Unavailable (#68) error. I solved it by using XPRINT to an Generic Text Print driver. But got lots of misprints then. Solution to that problem was to use en empty line at the beginning, and all Field data (text or barcodes) on separate lines e.q. XPRINT commands. I now can say goodby to the 17 year old XP PC's. Our printers are networked and shared.

[Bud Durland]

When you consider to port your software to W10 PC's, keep in mind that the LPRINT ATTACH command generates a Device Unavailable (#68) error.

That has not been my experience. We do a lot of printing where the connection is done through LPRINT ATTACH. 99% of it nowadays is LPRINT ATTACH \\server\printerqueue, or to an LPT port that has been created using a NET USE command. Very few modern PCs have real hardware LPT ports anymore.

[Ellen Reddick]

I begin this post with an apology. I don't know all I should know! Company pres insisted on doing whatever scheme necessary to prevent any hacking. So, IT guy has set up new server on new computer running win2K 16bit, if that is possible and if I understand him correctly. New win10 computers log in to the virtual server where the programs and data reside. All seems to work swimmingly, with one small exception (so far--not all of the new computers are installed, just the order input people and office). I have it set up so any of the myriad of reports and labels for an order can optionally be viewed onscreen. That is what they do if circumstances call for a replacement zebra label. That way they don't need to reprint 75 labels just to get one. Only one of these input computers can now select the page view with the to-be-reprinted label, select the zebra attached to that computer through the Windows installed printer dropdown and print it. When the others try it, it does nothing. I assume Calvin will eventually be able to work that out--guessing it has something to do with the print servers attached to the individual computers. At least it isn't a program problem. At the moment, everyone is running on PBCC4 version since PBCC6 seemed to be more problematic. I finally have the code for the two compilers interchangeable, so I am not trying to maintain two versions. Today, they tried printing to zebra out of the PBCC6 version, and it still stopped halfway through (29 out of 40 printed) with no error indicated--just stopped. I was so sure after the new computers/drivers were in that all would work. Obviously PBCC6 sends out something different to the zebra.

[Stuart McLachlan]

"win2K 16bit". 32 or 64 but not 16

Probably 32bit so you can still use 16bit software. (similar to how you can run 32bit software on 64bit Windows)

So the Company Pres or IT guy thinks that installing 20 year old, unsupported, workstation software on your primary server is a good way to "prevent any hacking"?

And you are responsibe for developing their software? I'd be looking for a new job somewhere else