  |
|
Thermal Transfer Bar Code Printer Test: Achieved Print Speed Performed by Bert Moore A report on achieved time-to-label of five thermal transfer printers printing bar code and graphics labels in very short run applications using both sophisticated label design and standard Windows®-based graphics software.
Introduction
Two observed trends spurred this testing program.
First, with the popularity of Windows-based programs (e.g. Excel and Access) and graphics programs (e.g. Adobe Illustrator and CorelDraw), and the ability to print bar code labels from within them, companies with limited labeling needs may choose to employ these general purpose programs rather than sophisticated label generation software for limited-run label production.
Second, with increased shipping of small orders, both from e-commerce and traditional businesses, very short runs of shipping labels (one or two at a time) are becoming more common.
For these very short run applications, print speed, expressed in inches-per-second, may not be an adequate predictor of the time it takes to produce labels under these conditions.
This report is the result of a testing program to determine "time to print" for 5 different thermal transfer bar code printers.
The hypothesis was that print speed, expressed in inches-per-second, is an inadequate predictor of performance under very short run (one to five labels at a time) conditions.
In addition, the test was to determine whether printing graphic-rich labels directly from a Windows-based program offered a viable alternative or whether there was a significant time penalty for this application.
Test Design and Methodology
Label Design
The test was to determine actual label production times for very short runs that would simulate "real world" applications. The test included two different label formats: a shipping label and a product label.
Label size was set at 4 x 6 inches as a common size for shipping labels. Product labels were produced in the same size.
Note: Figures reproduced in this report are 300 dpi graphics that have more detail than will be displayed in a browser. This detail can be seen if the figures are printed or displayed at greater magnification.
Figure 1 shows the shipping label, based on the RPS Multi-ship label, as a "real world" example. The label was printed in "picket fence" or "drag" mode. This label contains a PDF 417 symbol and three linear bar codes, including a UCC/EAN SSCC-18 with variable data. This label was produced with LabelMatrix software which incremented the package number portion of the SSCC-18.
 Figure 1: Shipping Label Note: Although the RPS specification calls for the data in the PDF 417 symbol to be variable, the program was not intended to measure the efficiency of LabelMatrix (or any other) label production software. Therefore, data in the PDF 417 symbol remained static (based on the assumption that the software would take the same amount of time to calculate PDF 417 symbol data for all printers and doing so would simply add complexity and increase testing time).
Figure 2 shows one of the product label which is based on an actual product (the name of the company was changed). This label was printed in "ladder" mode (that is, rotated 90°). This label was produced directly from CorelDraw 9.0, a popular Windows-based graphics package. All elements on the label, including text and the bar code symbol, were treated as graphic elements during output.
 Figure 2: Product Label (shown rotated 90° from print direction)
Methodology
Four separate runs of labels were tested: single labels and batches of 5 labels for both shipping and product labels. Sample labels were verified to determine that at least an ANSI "C" grade was achievable under these conditions. The CorelDraw labels achieved lower grades than did the symbols produced by LabelMatrix (which were typically "B" or better). However, insofar as this was not a test of print quality, no further attempts were made to refine the bar code graphic beyond determining that it could have been done if the symbol were optimized for each printer being tested.
Resident fonts in the printers were not used nor were proprietary printer control languages allowed in LabelMatrix. LabelMatrix was selected because it is not supplied with the printer by any of the printer manufacturers.
The program was designed to test Windows drivers (latest versions downloaded from the various companies' web sites), printer data communications speed, and printer processing time, all of which are contributing factors in actual label production time. Although the program included 3 variables, these variables are intrinsically inter-linked. That is, all three factors must be included in producing a label for a novice or advanced user.
For multiple shipping labels, a typical application was identified as 5 cartons of identical products on the same purchase number. This number was chosen arbitrarily for the purposes of testing only. Again, the concept was very short runs of labels. Therefore, the same label was printed 5 times with LabelMatrix incrementing the SSCC-18. For multiple product labels, 5 different labels were created in a single file and printed. Testing of the same label printed 5 times was not done.
Timing was done using a stop watch with a lap counter (for the multiple labels). Practice runs were made until the researcher felt confident in being able to produce consistent timing. Timing began when the "print" command was effectively issued to the computer (e.g., after the "Preflight test" was completed in CorelDraw) and ended when the printer stopped.
For multiple labels, timing of each "lap" was determined as the printers would pause momentarily between labels.
Both visual and auditory cues were used to determine end time.
It is acknowledged that hand-timing is not an entirely precise method for recording times and that variations of up to 1/10th of a second are very likely. To help mask this variation, times were recorded and calculations performed with 2 digit precision and, using standard rounding, reported to one digit precision. It was also observed that 1/10th of a second is a very noticeable amount of time. Any events where times were felt to be inaccurate (because of operator error) were discarded.
It was also felt that variations of up to 1/10th of a second would be non-significant. That is, print times that varied by only that much would have no impact in a real-world environment.
To further limit variability, the mean of 50 label printing times was reported. In the case of multiple labels, the mean of 10 batches of 5 is reported.
Results
Five different printers, with speeds of 6 ips and 10 ips, were tested. The results are summarized in Table 1 below. The first row reports time for single labels. The second row, with multiple entries, reports the results of the batch of 5 labels.
Speed 6 ips 10 ips Printer SATO Zebra DataMax SATO Zebra 5.6 13.5 7.0 5.1 11.2 Shipping Labels: Single Label & Batch Notes:
1. Times reported for single labels represents the average (mean) of 50 labels. Times for multiple labels represent averages (means) of 10 batches of 5. Times reported for multiple labels are: time to print first label; average time to print each of labels 2-5 (average of 4 individual times); total time to print 5 labels; mean time of each label (total time divided by 5).
2. Zebra printers enjoyed extremely preferential treatment from LabelMatrix and times are therefore not reported. While LabelMatrix produced files of 144K for the other three printers, files of only 4K were produced for Zebra printers despite the fact that all proprietary formatting languages were disabled in LabelMatrix.
This test demonstrates that there is a time penalty for printing "pure" graphics labels from Windows-based programs. Enabling proprietary printer control languages and resident fonts would increase print speed. However, the ability of a printer (and driver) to accept pure Windows printer files and produce adequate bar code symbols has been demonstrated.
Optimally, it takes 1 second to perform the actual printing a 6" high label on a 6 ips printer and 0.6 seconds on a 10 ips printer. Subtracting these values from the observed times, it becomes clear that front-end processing is the most time-consuming activity.
Observations
Clearly, inches-per-second is a meaningless measure in light of these results. The SATO CL408e (6 ips) printer out-performed all other printers except its 10 ips "cousin" – the SATO M-8400RVe – but lagged behind it only marginally and equaled its performance in the batch printing of the shipping labels. DataMax's I-4206 (6 ips) printer also outperformed Zebra's 6 and 10 ips printers for the product labels although it fared less well with the shipping labels. It is interesting that the DataMax achieved much more consistent time-to-label for both the LabelMatrix and CorelDraw labels whereas both SATO and Zebra printers were much quicker with the LabelMatrix labels.
Zebra's printers exhibited considerable variation in achieved print times. This variation is in contrast to much more consistent times recorded for the two other manufacturers' printers, with the minimum variation for Zebra being nearly double that (or more) of the variation for other manufacturers. Variations are shown in Table 2. Values reported are the difference between the high and low times recorded.
Single Product 0.2 sec. 1.0 sec. 0.4 sec. 0.3 sec. 1.0 sec. Single Shipping 0.3 sec. 0.7 sec. 0.4 sec. 0.4 sec. 0.7 sec. Batch 5 Product (total) 0.4 sec. 0.8 sec. 0.2 sec. 0.5 sec. 1.0 sec. The variance is more than can be attributed to operator error. The raw data show a very high degree of correlation between high and low values for SATO and DataMax printer times with a very few exceptions. For Zebra, this is not the case, with values showing wide variance and no apparent correlation of where in the print run they occurred.
These variations can only be accounted for in how the data was handled by either the Windows print spooler or the Zebra's Windows driver – or the interaction of the two.
The Windows print spooler was observed to act erratically during testing – sometimes not showing the print job until after the printer had finished printing! At other times, it would report as little as 8K of data spooled initially or as much as 128K, with values in between.
Other problematic factors were also observed.
Testing was initially begun with a year-old Packard Bell with a 300 MHz Cyrix MII processor, 94 Mb of memory, Windows 98 and a new high-speed PCI parallel interface. During setup and configuration of the printers, a reference set of 5 graphic labels produced from Microsoft Word was used to verify correct setup. That's where the first problem was observed.
These labels took nearly 13 seconds to print with the Packard Bell. The same labels produced from a Sony notebook with a 300 MHz Celeron processor and 64 Mb of memory took about 5 seconds.
A remanufactured Dell computer with a 500 MHz Pentium III and 128 Mb of memory was secured for testing. This was chosen as a good "middle of the road" PC which would mirror "real world" applications. The reference labels printed in a little less than 6 seconds.
Interesting in this scenario is that the raw power of the CPU had little effect on achieved print speed, with the slower notebook producing labels more quickly than the 500 MHz desktop.
Subsequent to testing, it was discovered that the drivers for the SATO printers were not defaulting to sending RAW data, causing the PC to do processing that would have been more efficient in the printer. In testing the reference labels, a compatible – but different – driver was used on the notebook. The default setting on that driver was to pass RAW data. The default setting of these drivers in all probability accounts for the difference in achieved print times for the reference labels between the Sony notebook and Gateway desktop.
Artifacts
There were a number of residual observations from the test which have no bearing on the hypothesis or the results but which, nonetheless, are worth noting.
Another indication that there were problems with the I/O on the Packard Bell was that set-up of the Zebra printers was very difficult. Following normal procedures of connecting cables then powering up the printer, the Zebra printers appeared to be locked up in a data download. Turning them on and off had no affect. Only removing then reattaching the cable with the printer powered up cleared the problem. Neither the SATO nor DataMax printers experienced this condition.
During testing, the Zebra 105se defaulted to a "pure" 6 inch high label, ignoring the 1/10th inch space between labels. This resulted in labels not printing exactly on the label stock (becoming mis-aligned by 1" over the course of 10 labels). Attempts to restore defaults and even clean and reset optical sensors failed. It was observed that the top and bottom sensors could move independently which might have contributed to the researcher's inability to properly align them. (The researcher also concluded that this was not a good idea.) In any event, it was decided to continue the test, allowing the 1/10th inch "bonus" in printing time since, at 6 ips, the time differential would be, at most, 0.017 seconds.
It was also observed that the Zebra printers were, frankly, annoying to set up. The printer driver required the printer's firmware version number, a number that could only be obtained by printing a label. However, unless a value was entered for the version number, the printer could not print a label. (The researcher eventually determined that hovering the mouse pointer over the fill-in box brought up an example of how the version number should be entered. Using this value, a label could be printed and the correct version number then inserted.)
Testing was done in a home office – often late into the night. The researcher found that both DataMax and Zebra printers were quite noisy (in this environment), with the Zebra producing a loud motor sound (a sort of whine) and the DataMax emitting a definite metallic "thunk" on finishing each label. The SATO printers, by comparison, were noticeably quieter. Therefore, late-night testing was reserved for the SATO printers.
Implementation of proprietary printer languages, use of vendor-supplied label production software, and use of resident or downloaded bar code and text fonts would certainly have improved performance. However, results of such conditions could not be completed within the parameters of this test. Subsequent testing for these conditions would be a very positive step forward in evaluating true printer performance.
Because of the variation in PC and Windows front-end processing, standardized label production times can not be reported by manufacturers with any more meaning than the inches-per-second number. Uniform testing by a third party, using the same equipment, software, label formats and data, would be required to produce a "sample" and "optimized" time-to-print value.
Conclusion
The hypothesis that inches-per-second is an insufficient predictor of performance in single label and short-run batch production applications is proven. The majority of the time involved in label production is not in printing – it's in everything that precedes actual printing.
Further, although there is typically a significant time penalty versus a dedicated label design software package, accurate printing from within purely Windows-based programs is entirely feasible. Use of resident and downloaded fonts would likely reduce this penalty.
For the single label and small batch operations, time-to-label is the only "real" measure. And there are no adequate predictors. Only testing in the actual application will provide meaningful data.
Acknowledgements:
A summary of this report was published in the October 2000 issue of Frontline Solutions.
Funding for this study was provided by SATO America, Inc. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||