Announcement

Collapse
No announcement yet.

erratic behavior--Help!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    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,
    Dale

    Comment


    • #62
      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.

      Comment


      • #63
        Originally posted by Ellen Reddick View Post
        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.
        Real programmers use a magnetized needle and a steady hand

        Comment


        • #64
          Originally posted by Ellen Reddick View Post
          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:

          Code:
           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.

          Real programmers use a magnetized needle and a steady hand

          Comment


          • #65
            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!

            Comment


            • #66
              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.
              Real programmers use a magnetized needle and a steady hand

              Comment


              • #67
                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.

                Comment


                • #68
                  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.


                  Comment

                  Working...
                  X