advertisement
from the Automation List department...
Label printer driven by PLC
PLCs and related questions. topic
Posted by paul cunningham on 3 February, 2005 - 5:56 pm
Ive been asked to add label printers to our machines just for the purpose of printing the quantity (in yards) of stock produced. The operator will take this sticker and attach it to his paperwork. I need a serial printer that will let me create a short message containing the quantity, and have it print. My investigation, so far, has only turned up PC driven printers. The printers i've looked at require the data stream to construct the entire label image bit by bit. This is impractical in a PLC.
Thanks


Posted by Lance Jones on 4 February, 2005 - 5:43 pm
Depends what PLC's you are using. The AB line has serial cards you can put in the rack that will run a printer. The easiest way would be to have your operator interface print it if you are using something like Wonderware or RSView.

Lance


Posted by Ron on 5 February, 2005 - 12:31 am
Greetings Paul,

I did something like this several years ago with an Allen-Bradley PLC-5 (enhanced) processor... so what brand and model are you working with?

Anyway, I used a "serial-to-parallel" converter (from Black Box if I remember correctly) between the PLC's serial port and a readily-available parallel printer...

the basic idea is to have the PLC take the value (quantity in yards) and convert the integer into a string value... then send the string out through the PLC's serial port using the proper ASCII command... the "serial-to-parallel" converter should take the serial output and make it compatible for the parallel printer... the printer should be able to print the string...

keep in mind that this is probably going to tie up your PLC's serial port... so if you're currently using that port for programming purposes, you're going to run into a lot of aggravation down the road... the best thing to do is make sure that you can use the PLC's DH+ port for future programming and reserve the serial port for the printer's use... any other approach is likely to drive you insane...

good luck...
Ron


Posted by Anders Hansson on 8 February, 2005 - 12:08 am
Hi Paul,

I've used a serial printer connected to a PLC (OMRON in my case) using standard RS-232.

I used a printer from Custom, they have a lot of different label and receipt printers.
http://www.custom.it/ing/kiosks/index.htm

There are serial printers that takes Ascii directly. Just convert your data to Ascii and send it on your serial port. (I used a kiosk TPT52).

Very easy.


Posted by Anonymous on 9 February, 2005 - 11:51 pm
Thanks, It looks like you've sent me in the right direction...


Posted by Curt Wuollet on 7 February, 2005 - 10:26 pm
This is what many people use a "BASIC" module for, although that is a horribly expensive way to go even if you know the gizmo and can program it quickly. But, with the trend being toward less or no intelligence built into printers (Winprinters), and 232 serial being drummed out, I think you are looking for something either highly specialized or non-existant. The easiest solution would be to use a PC to accept tokens and put out the strings with all the formatting. I know there were printers for the cash register / label / ticket trade that would store a
format so you just sent the numbers, but the pointy clicky crowd obsoleted those years ago. You grabbed my interest because I have thought to make such an item just for PLC applications and others where for whatever reason it's not practical to output format strings. But, I decided that investing in the serial printer market was not a strong
idea. And I come from a serial *nix background. This is another case where the industry has hitched their wagons to MS and they promptly drove off the road. I hate to see serial being squeezed out by the duopoly as it fits many automation uses that aren't well served by the alternatives. Linux and family will always support traditional serial equipment. But that doesn't help if all the peripherals are aimed at the monopoly. I'll bet it's getting difficult to find commodity serial printers already.

Regards

cww


Posted by Michael Griffin on 9 February, 2005 - 12:19 pm
> I know there were
> printers for the cash register / label / ticket trade that would store a
> format so you just sent the numbers, but the pointy clicky crowd
> obsoleted those years ago. <

Industrial label printers still work this way as one of their operating modes. A lot of them can be used without a PC. They can store a label format which allows you to just send the variable label fields for each label. These are
probably much too bulky and expensive for the application in question though.

> You grabbed my interest because I have
> thought to make such an item just for PLC applications and others where
> for whatever reason it's not practical to output format strings. But, I
> decided that investing in the serial printer market was not a strong
> idea. And I come from a serial *nix background.
<clip>

Why produce a whole printer when all you really want is an intelligent interface to a printer? If you really wanted to make something like this, all you would actually need is a single board computer with the appropriate interfaces and some suitable software. It could take commands and data in through a serial port, and send the formatted printer file out through a USB or second serial port to the printer. If you use an SBC with a Linux OS, this should supply you with the printer drivers.

The label formats would be created off line by label software (e.g. KBarcode, etc.) and downloaded to the SBC. The PLC could talk to the interface box either via special ASCII protocol strings, or perhaps via Modbus. The embedded application would substitute the data from the serial port into place holders in the stored format, and print to the printer via the configured printer driver.

> I'll bet it's getting difficult to find commodity serial printers already.
<clip>

You can still buy dot matrix serial printers, but they are becoming expensive. The market is limited to people who are using old software to print multi-part forms. This is a fairly limited market.


Posted by Curt Wuollet on 10 February, 2005 - 2:20 pm
Hi Michael

Agree on making a whole printer, but the sbc thing would be doable, The trick would be to make it versatile yet simple to use. Some type of simple form creator and a lock down mode where all it does is grab data and frame it. But, I'd probably use the parallel port for output with a
USB option. Linux would be sort of like using a sledgehammer to drive tacks, but with foomatic and all you could get really elegant. Even to the point of embedding barcodes etc.Too bad there are so many crippled half printers (Winprinters)out there. What's a BASIC module cost these days? That would set your price point.

Regards

cww


Posted by Michael Griffin on 14 February, 2005 - 12:14 pm
<clip>
> Some type of simple form creator and a lock down mode where all it
> does is grab data and frame it. <

For a "form creator", you would use standard label creation software. You would draw the label on the screen and save it as a label definition file. There is no need to create any new software for this. For Windows versions,
be prepared to pay through the nose and put up with dongles. Linux versions are free of course, so you can't complain about that.

> But, I'd probably use the parallel port for output with a
> USB option. <

The more interfaces, the merrier. You could offer parallel, serial, USB, and ethernet if they are available. Since the point of this proposal is to be able to use one of the many document style printers available though, USB
would be important to support. Parallel printer ports are disappearing on the personal printers which would be one of the likely low cost targets for this sort of thing.

> Linux would be sort of like using a sledgehammer to drive
> tacks, but with foomatic and all you could get really elegant. Even to
> the point of embedding barcodes etc. <

No, it wouldn't be a "sledgehammer". The whole point of the idea of using a full featured OS like Linux was to take advantage of all the printer drivers for it. It would be impractical to attempt write your own printer drivers and rather silly to think of doing so when they are already there for free in an OS that you can still embed.

> Too bad there are so many crippled half printers (Winprinters)out there. <

I think you are referring to "host based printers". They would be the wrong sort of printer to use anyway. Since the "driver" for these is often very model specific, you would have to install a new driver if you replaced the
printer hardware with even a slightly different one. The sort of embedded interface box that I am suggesting would not be very convenient for this as it wouldn't have a keyboard, screen, or CD drive built in.

It would be better to use a "real" printer, as the driver interface to them tends to be more stable over a range of models and over time. This makes replacing a broken printer with a newer model less of a computer expert job,
and more of a routine maintenance department repair job (just unplug the broken one, and plug in the new one).

The "host based" (Winprinters in your words) don't seem to be any cheaper than comparable "real" printers, so there are plenty of reasons to avoid them and no good ones for using them.

> What's a BASIC module cost these days? That would set your price point.
<clip>

I don't see the relevance of the cost of a Basic Module to this. You could use a Basic Module to interface the PLC to this hypothetical printer "interface box", but a Basic Module could not itself do what this "box" does - interface to a wide range of modern laser or ink jet printers to provide sophisticated output. This is letting you use a cheaper printer for the same sort of applications as an industrial label printer. It wouldn't give you thermal transfer print quality, or roll-feed or peel-off capabilities, but it would still have applications where you want to print off move tickets and other lower quality paperwork without having to add a PC plus custom application to the system just to provide a printer interface.

What I had in mind as to how such a device would be used was as follows. You would design a label on your PC, using standard label design software (you probably have a few K-this or Gnome-that label programs on your PC without
realising it). For the data fields, enter some place-holder data values (e.g. <PART-NUMBER> instead of the real part number).

You would next download this into the interface box via serial, USB, ethernet, or some other means (perhaps by FTP). You could store a number of different label formats to be selected as required.

The interface box would be connected to the PLC via RS-232, or ethernet (depending upon what is available, and what protocols are supported). The PLC would then talk to the interface box via some protocol such as Modbus. Certain registers would be defined as "command registers", while others would just be "data registers".

To use the part number example, the PLC would write the part number data into the appropriate data registers, and then write the necessary commands to the command registers. Some fairly simple software in the interface box would interpret the commands, fetch the requested label format, substitute the place-holders in the stored label with the actual data in the data registers, and then send the resulting file out to the printer via the printer driver. Bar codes could be dynamically generated and substituted into the label in a similar manner (I believe bar code generators are availalble which can be used like this).

The above example used Modbus. Other protocols would work as well. It would probably be a good idea to also have a special simple ASCII protocol for applications using a simple PLC serial port or Basic module.

As for your question on cost, the target should be for less than $500. It would need a single board computer, power supply, case, flash card or flash DoC, and software. The hardware should be low powered and fanless. There may
be ready made hardware systems which are suitable for this. The software should not be too difficult. You would need the PLC protocol interfaces, register map, command interpreter, and label reformatter (to substitute in the real data on command). The printer drivers of course come with the OS.

A variety of different hardware could be used with this idea. The software could of course also be be hosted on the same PC as a softlogic system without a hardware PLC.


Posted by Curt Wuollet on 17 February, 2005 - 11:21 pm
Hi Michael

On February 14, 2005, Michael Griffin wrote:
> On February 10, 2005, Curt Wuollet wrote:
> <clip>
>>Some type of simple form creator and a lock down mode where all it
>>does is grab data and frame it. <
>
> For a "form creator", you would use standard label creation software. You
> would draw the label on the screen and save it as a label definition file.
> There is no need to create any new software for this. For Windows versions,
> be prepared to pay through the nose and put up with dongles. Linux versions
> are free of course, so you can't complain about that. <

I would be the last to complain :^)

>>But, I'd probably use the parallel port for output with a
>>USB option. <
>
> The more interfaces, the merrier. You could offer parallel, serial, USB, and
> ethernet if they are available. Since the point of this proposal is to be
> able to use one of the many document style printers available though, USB
> would be important to support. Parallel printer ports are disappearing on the
> personal printers which would be one of the likely low cost targets for this
> sort of thing. <

The trick is to make it "appliance like", none of this is particularly hard for me to do with a standard Linux desktop for $300 at walmart.

>>Linux would be sort of like using a sledgehammer to drive
>>tacks, but with foomatic and all you could get really elegant. Even to
>>the point of embedding barcodes etc. <
>
> No, it wouldn't be a "sledgehammer". The whole point of the idea of using a
> full featured OS like Linux was to take advantage of all the printer drivers
> for it. It would be impractical to attempt write your own printer drivers and
> rather silly to think of doing so when they are already there for free in an
> OS that you can still embed. <

Yes, indeed. But it would be good to pare things down a bit. Of course, some might like a browser interface and a full blown database or two.

>>Too bad there are so many crippled half printers (Winprinters)out there. <
>
> I think you are referring to "host based printers". They would be the wrong
> sort of printer to use anyway. Since the "driver" for these is often very
> model specific, you would have to install a new driver if you replaced the
> printer hardware with even a slightly different one. The sort of embedded
> interface box that I am suggesting would not be very convenient for this as
> it wouldn't have a keyboard, screen, or CD drive built in. <

That's my point. You would have a lot of junk that people have that is not usable or supportable. And the trend is heavily towards page printers which are less than desirable for labels. From long experience, what is needed are pin or friction feed continuous form printers which are a rare commodity anymore. Epson used to make a tractor inkjet which was ideal for low cost barcodes, because it could handle standard labels and still provide high quality bit graphics. What you would have to target are specialty thermal transfer label printers like Zebra which
are probably not foomatic items. And the cost for these and their consumables take them well out of the commodity class. Inkjet and Laser page printers are not very good when you want to print one label at a time. Dot matrix impact printers are dinosaurs and don't typically do barcodes consistantly well. That's where we get into perhaps integrating an OEM mechanism with a SBC. A high res narrow form tractor inkjet with bulk tanks would blow the specialty guys out of the water for consumable costs.

> It would be better to use a "real" printer, as the driver interface to them
> tends to be more stable over a range of models and over time. This makes
> replacing a broken printer with a newer model less of a computer expert job,
> and more of a routine maintenance department repair job (just unplug the
> broken one, and plug in the new one). <

Hear, hear. The Winjunk should go away.

> The "host based" (Winprinters in your words) don't seem to be any cheaper than
> comparable "real" printers, so there are plenty of reasons to avoid them and
> no good ones for using them. <

But since they give them away with systems, counting on stratospheric ink costs for revenue, the blight will continue amongst the uninformed.

>>What's a BASIC module cost these days? That would set your price point.
>
> <clip>
>
> I don't see the relevance of the cost of a Basic Module to this. You could use
> a Basic Module to interface the PLC to this hypothetical printer "interface
> box", but a Basic Module could not itself do what this "box" does - interface
> to a wide range of modern laser or ink jet printers to provide sophisticated
> output. This is letting you use a cheaper printer for the same sort of
> applications as an industrial label printer. It wouldn't give you thermal
> transfer print quality, or roll-feed or peel-off capabilities, but it would
> still have applications where you want to print off move tickets and other
> lower quality paperwork without having to add a PC plus custom application to
> the system just to provide a printer interface.
>
> What I had in mind as to how such a device would be used was as follows. You
> would design a label on your PC, using standard label design software (you
> probably have a few K-this or Gnome-that label programs on your PC without
> realising it). For the data fields, enter some place-holder data values (e.g.
> <PART-NUMBER> instead of the real part number).
>
> You would next download this into the interface box via serial, USB, ethernet,
> or some other means (perhaps by FTP). You could store a number of different
> label formats to be selected as required. <

Yep.

> The interface box would be connected to the PLC via RS-232, or ethernet
> (depending upon what is available, and what protocols are supported). The PLC
> would then talk to the interface box via some protocol such as Modbus.
> Certain registers would be defined as "command registers", while others would
> just be "data registers". <

Yep.

> To use the part number example, the PLC would write the part number data into
> the appropriate data registers, and then write the necessary commands to the
> command registers. Some fairly simple software in the interface box would
> interpret the commands, fetch the requested label format, substitute the
> place-holders in the stored label with the actual data in the data registers,
> and then send the resulting file out to the printer via the printer driver.
> Bar codes could be dynamically generated and substituted into the label in a
> similar manner (I believe bar code generators are available which can be
> used like this). <

Yes, I have one I wrote for Epson Esc/P2 printers long ago. That does make the whole label a bitmap which complicates things, but is doable.

> The above example used Modbus. Other protocols would work as well. It would
> probably be a good idea to also have a special simple ASCII protocol for
> applications using a simple PLC serial port or Basic module. <

Yes, or a clever means to use whatever unchangeable format is cooked into the proprietary end. Recognize the start, parse out the data, embed it into the label and throw the rest. Sorta like a screen scraper.

> As for your question on cost, the target should be for less than $500. It
> would need a single board computer, power supply, case, flash card or flash
> DoC, and software. The hardware should be low powered and fanless. There may
> be ready made hardware systems which are suitable for this. The software
> should not be too difficult. You would need the PLC protocol interfaces,
> register map, command interpreter, and label reformatter (to substitute in
> the real data on command). The printer drivers of course come with the OS.
>
> A variety of different hardware could be used with this idea. The software
> could of course also be be hosted on the same PC as a softlogic system
> without a hardware PLC. <

And would probably be GPL since it would use GPL libraries, etc.

It would fill a niche, and if you could deliver on the consumable cost savings, it might be a pretty large niche.

Regards

cww


Posted by Michael Griffin on 18 February, 2005 - 3:44 pm
> The trick is to make it "appliance like", none of this is particularly
> hard for me to do with a standard Linux desktop for $300 at walmart.
<clip>

The standard desktop PC wouldn't be very appliance like. Have a look at mini-ITX boards. These are very compact and have fanless versions while still working like ordinary PC hardware. Finding a good case for a reasonable price may be difficult though. If you look at non-PC hardware, there are quite a few ARM or MIPS SBCs. These don't often have a printer port though.

> Yes, indeed. But it would be good to pare things down a bit. Of course,
> some might like a browser interface and a full blown database or two.
<clip>

I don't know what you would use a database for in this application, but the browser interface sounds like a good idea for configuration and status monitoring.

> What you would have to target are specialty thermal transfer label
> printers like Zebra which are probably not foomatic items. <

The Zebra and Intermec printers that I am familiar with use ZPL or IPL, which are ASCII coded command languages. You don't need a "driver" for them. The label graphics (including bar codes) are generated in the printer, not in the computer. These are actually the easiest printers to handle using the type of system we have been discussing.

You design the label using label software (Kbarcode supports both Zebra and Intermec). The label software can write the commands out to an ASCII file which you can print directly or easily parse to modify it dynamically. You can actually create a label definition file with just a text editor and a copy of the printer manual if you wish (I know someone who has done exactly this).

> And the cost for these and their
> consumables take them well out of the commodity class.
>
> Inkjet and Laser page printers are not very good when you want to print
> one label at a time.
<clip>
> But since they give them away with systems, counting on stratospheric
> ink costs for revenue, the blight [host based printers] will continue
> amongst the uninformed.
<clip>

Laser printers are quite cheap now, provided you don't want colour. The operating costs are lower than ink jet printers as the toner tends to be cheaper than ink cartridges. I will admit though that neither have a quick
response for "print on demand" applications, as they go into stand-by mode when idle and take a few seconds to recover to operating mode. However, there is still a large application area for temporary labelling for in-process
inventory. People are using laser printers and photocopiers for creating these sorts of labels now.

> Dot matrix impact printers are dinosaurs and don't
> typically do barcodes consistantly well. That's where we get into
> perhaps integrating an OEM mechanism with a SBC. A high res narrow form
> tractor inkjet with bulk tanks would blow the specialty guys out of the
> water for consumable costs. <

Are you sure? The consumable in a thermal transfer printer (besides the labels) is just the ribbon. A case of ribbons is about the same price as a single ink cartridge.

Given the above, I can perhaps define a target market for this hypothetical "printer interface appliance". We should set aside for now the question of printing labels "cheaply" and just worry about how to control a standard
thermal transfer printer (Zebra, Internec, etc.) from a PLC. The question after all, originated as how to "drive a label printer by PLC".

The appliance would store multiple label definitions which would be selected for printing on demand by the PLC. The PLC would also be able to send variable data which the appliance could merge into the label file before printing it. New label formats could be created using standard label software and downloaded to the appliance by various means, including via a network connection.

The printer appliance hardware should be small, low powered, and fanless. When installed, it should be more or less invisible.

I have just realised that I could have used two of these last year instead of printer pendants. This would have let us control date code printers via the MMI panels and would have resulted in a much better integration into the machines.


Posted by Curt Wuollet on 21 February, 2005 - 4:42 pm
Hi Michael

You know what's interesting? If you blurt these ideas out and discuss the feasibility and approaches and then wait a bit, they tend to appear :^)

Regards

cww


Posted by Jason Reiling on 9 June, 2005 - 2:43 pm
Comtrol has in fact tested ASCII communications between these printers and various PLC models already.

Using the DeviceMaster UP (Universal Protocol), you can connect 1 or up to 4 RS-232/422/485 serial devices to an Industrial Ethernet network easily, and affordably. Industrial Ethernet protocols currently supported include Ethernet/IP, Modbus TCP and PROFINET.

Please contact me if you might be interested in additional details.

Jason Reiling
Comtrol Corporation
763-494-4144


Posted by Michael Griffin on 8 February, 2005 - 10:20 pm
It sounds like what you want is a point of sale or retail label printer, not a document printer. You need to talk to someone who sells cash registers and retail scanners.


Posted by Cross, Patrick M \(SKM\) on 9 February, 2005 - 12:12 pm
I've used SATO label printers to this ..

http://www.satoworldwide.com

They have a RS232 interface option.

Regards

Patrick Cross
pmcross@skm.com.au


Posted by Scott Anderson on 1 April, 2005 - 8:50 pm
I've got the same requirement, and a quick google search turned up the Dymo LabelWriter SE300 ASCII Printer for about $250 which is what I'm going to try first...

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
God is not dead! He's alive and autographing bibles at Cody's
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive