Let me start by saying, I don't have a PLC background, I'm more of an embedded computer type person. I need to migrate many controls (switches, status lights, etc) to a PC-based application. It looks like the SLC 500 has a 232 interface. It seems like I could connect a computer and write software to monitor and command these I/Os on the SLC 500. The Allen Bradley website is terrible. Can anybody point me to the correct documentation to get started with this? Thanks.
It would seem like that, but there really isn't any easy way to do that. The SLC is pretty much intended to do the controlling and the ports speak only what the makers allow. Not impossible, but probably a lot more trouble than you would believe. Monitor, yes. Wrest control from the executive? Not too likely. It would probably be easier to use networked IO and just rewrite on the PC. For enough money, maybe they can find a way. It is possible to send maps back
and forth, that might be the best angle of attack. The AB website is a bit tedious, but at least you can download almost any manual and the manuals are at least mediocre.
Or just buy an HMI package capable of doing control and that has DF1 drivers capable of writing direct to I/O like Azeotech's DAQFactory (I assume other peoples' packages may be able to write to I/O directly but that one I know personally can do so).
I've actually written drivers that can do this; it's not hard with DF1.
It is quite easy to read inputs directly and write directly to outputs in an SLC, or most any PLC for that matter.
Just put it in run mode with no program, just an I/O configuration and you are all set.
The SLC with RS232 uses DF1 protocol that is fairly easy to implement. It's on their website somewhere. It is no harder than Modbus to implement.
The protocol that is used on the serial port is DF-1. There is a Reference Manual available on the web. Search for Allen Bradley Literature to find the Rockwell Automation Literature Library. From there search for Publication Number 1770-6.5.16
I have not attempted to directly read or write inputs or outputs. Typically, we read and write to files and use simple ladder rungs to move data to the actual I/O cards. However the SLC 500 does have File Type of 8B and 8C listed as output logical by slot and input logical by slot so you might give that a try. I think using some simple PLC programming would be much easier and adds a layer of safety as well.
Why on earth would you turn a SLC that's running a process into remote I/O for a PC? Is your car perfectly workable but you just use it as a carriage and pull it with a donkey?
> Why on earth would you turn a SLC
> that's running a process into remote I/O
> for a PC? Is your car perfectly
> workable but you just use it as a
> carriage and pull it with a donkey?
I think this one short post is the best answer you've had so far. While you "could" do what you're proposing its basically a bad solution.
You really should look at coding your application in the PLC and providing an operator display either on a PC using an off the shelf HMI package (or even a free open source one from this forum if you've got no money) or a simple dedicated panel from somebody like Red Lion or even A-B.
But, you should remember that when all you have is a hammer....Everything begins to look like a nail. This is pretty much a PLC list :^) If the idea is to get rid of the SLC and control the process with _your_ software, there are I/O solutions you can add to a PC. I'm working on one and there are several that are reasonably easy to code for without duplicating a proprietary protocol. From a programming time and effort standpoint, these might be easier than repurposing the SLC because the data is created on the machine that you are using. That said, a SLC is a fairly good way to do things so you will want to make sure your way is better. Or at least that the need justifies the effort.
Now be nice, Curt! No one that suggested he use a SLC as a SLC said they had never done PC control or didn't know how to do so, nor has anyone ever accused you of advocating PC control because you don't know how to use a PLC.
Maybe we just tried it and found that saws suck at hammering.
I am being nice Steve:^) In their depth, PLCs are an excellent solution and yes, I've used them where they make sense and been very satisfied. And you can get it done and forget about it for life in some applications. Outside their depth, you find yourself buying a lot of extremely expensive and often obviously hacked in add ons and trying to do procedural programming with relays and negating the key advantages of PLCs. They do analog only so-so and too slowly to use averaging, and the networking picture is often dismal, a return to ancient days like leased equipment and proprietary confusion, and it would be hopelessly expensive to add a dozen barcode scanners, for example. And when people use PC control pejoratively on this list, they are speaking of Visual Basic or other stuff built on top of the Worlds Least Reliable Operating System. That's somewhat like judging the automobile solely by experience with a Yugo or a Trabant. That's why I add that the way you do PC Control is crucial in replacing a SLC. It's a lot easier to make a PC do a PLC's work than vice versa. It's not hard to tell which operating envelope you're in, but you need to be careful with definitions. I've done both, and it's hard to beat a SLC in it's depth and hard to beat a PC in it's depth. But, what do I know, I've gotta go get some more firewood:^)
Automated Solutions offers an A-B Serial DF1 ActiveX Control that can be used in VB, C++, C#, etc.
Fully functioning 30-day trial version is available for download at
Includes ready-to-run example applications, VB6 example projects, and Help system.
PeakHMI can handle this task.
You'll find the job a lot easier- in fact REALLY easy- if you use a protocol converter. I've used the Red Lion Datastation Plus, only a few hundred pounds, http://www.redlion.net/Products/HumanMachineInterface/DataStationPlus.html
Speaks DF1 to the PLC. Speaks more or less what you like to your PC. You can even put a C- like program inside it to do some of your work for you.
You could use an SLC. You would set the port to ASCII instead of DF1 and then you can read and write characters to it.
Why you would want to write a protocol in ladder though is beyond me.
Look at a simple HMI or SCADA application. There are even OPC servers like the Topserver Omniserver where you can implement your own protocol.
What made you think of using the SLC. Do you also need to control IO as well?
If so there may be better suited devices for this. Something like Beckhoff IO and Twincatt soft PLC may do (no affiliation here). I have done a similar project using this hardware. You can buy extra serial ports and re-use function blocks to control many similar serial devices.
Unlike the many people who are trying to tell you that you need to use a PLC, I'll just assume that you really do know that you need a PC, and I will concentrate on the I/O.
You said there are "many" controls (switches, status lights, etc). I don't know how many is "many" but I have done machine retrofits before, and replacing the I/O can be quite feasible if you do it in stages and plan it properly. If there are already cable connectors, or if you can add connectors ahead of time, you can swap the field devices from one set of I/O to another.
I haven't seen your machine, but my own first thought would be to install new field mountable I/O connected via Ethernet and using the Modbus/TCP protocol. Ethernet is a lot easier to work with than RS-232 and it won't be a speed bottleneck. Modbus/TCP is an open protocol, and there are lots of options for using it from your program.
Trying to salvage the I/O that is already there can look attractive at first sight, but the headaches of trying to make something do what it was never intended can be a quagmire once you get into the project. You also have to consider that if you are using a SLC-500, it has probably been there for quite a while, so you are spending a lot of time and effort (and therefore money) on trying to salvage old control hardware.
If you want to discuss the practicalities of this further, let us know how many I/O there are and what types they are, and what the production process is like, and we may be able to come up with some good suggestions.
I would suggest getting someone with an electrical control background involved regardless of what you do. My experience in this area has been that retrofits usually turn up "surprises" when you try to start up the machine again unless someone has gone over the machine carefully and confirmed what is connected to where, and whether everything actually is working at the current time. Don't accept "the machine is running right now" as meaning everything is actually working!
I'm going to take a different view of the OP, that you're starting with those many controls wired to an SLC-500 and you want to migrate those controls to a PC application. I did just that last year for a client, replacing over 60 controls with a dedicated graphic terminal. It actually has more functions, since we added some features to the machine at the same time.
As long as you don't remove the physical I/O modules, reading outputs is not a problem. However, you can't write to the same physical addresses that the switches are wired to, so you'll have to reprogram the PLC with new HMI input addresses. If you need help with the PLC programming, ask your local A-B distributor to recommend a system integrator who can help you.
Using OPC seems to be the easiest and cheapest way here ... you will need to connect the OPC Server to the SLC 500 and then use the OPC Client included in the package to control and monitor your SLC data.
Here is a link to the SLC 500 OPC Server:
Hope this was helpful
Global Solution Architect