One of the most prevalent applications for our products is connecting printers to controllers. As you certainly know there are all kinds of printers and applications. And a lot of them don’t even print anything in the traditional sense. Some of them are really engravers and embossers. Others use various techniques for encoding information physically on a product.
Let’s talk about the kinds of ways that these printers are driven and how you can connect them to your controllers.
Let’s start with physical connections. There are two basic ways to connect a printer to a controller; serially or over Ethernet [I’m going to skip parallel printers because if you’ve decided to use a parallel printer, your beyond hope]. Serial is the traditional approach. And 90% of the time, those printers will use RS232 as the electrical standard. But RS232 always presents some problems. It’s limited to 50 feet so you have to keep your printer close to the controller and it’s not very noise immune. That can be a real problem in a lot of factories.
But if the printer supports Ethernet, and a lot of them do, the distance and noise issue go away. You can put the printer anywhere you have an Ethernet switch. And noise won’t be a problem if you’re sending data over Ethernet.
But no matter what kind of physical layer you use, you still have to process the printer data, the characters that are printed and any controller characters that it sends.
Sometimes that’s just straight ASCII with a CR (Carriage Return) and LF (Line Feed) on the end. Those are the easiest ones to deal with. Lots of people just hook those up to the serial port of the controller and blast out the printer data over RS232. But if your printer isn’t near the controller or you don’t have a spare serial port, our 435NBX (https://www.rtautomation.com/products/435/nbx.html) takes the string data out of the controller, adds the termination characters on the end and sends it serially to the printer. That’s a great tool if you need to remotely locate your printer.
And if the printer is on TCP we have an equivalent tool, the 490NBX (https://www.rtautomation.com/products/490/TCPControl.html). The 490NBX grabs the printer data in your Controllogix data table and sends it to the printer over standard TCP/IP. On the PLC side it works exactly like the 435NBX.
But what if the printer data is more complicated? Sometimes there are printer control characters involved. Sometimes there are multiple messages. Most of the time the 435NBX and the 490NBX can handle those situations. In a lot of cases, you can embed the printer control characters right in the ASCII string. You’ll have to see your PLC handbook on how to do that.
What those devices can’t handle though is when there has to be a dialog between the printer and the controller. Some printers use their own protocol and have a pretty extensive command set. The controller must send command 55 followed by command 23 and then 49. Each one of these reports back to the controller with a status or some data.
This kind of interaction is handled using our tailoring services. We actually implement that command set in our unit and the unit will do all the interaction with the printer. All you do in the PLC is to kick off the interaction and give us the base data we need to send.
That kind of project is handled on a case by case basis. Just call our office and we’ll arrange a phone meeting where we can go over all the details.