Alan C

Help with PLC communication basics

6 posts in this topic

Hi everyone, first post.  My company provides software that manufacturing businesses use to track their tactical and strategic KPIs.  We wish to add the capability to pull data directly from the manufacturing processes, PLCs, etc.at the client sites and I have a couple of items I'm hoping I can get some help with here:

1. I have purchased an Allen Bradley Micrologix 1400 series PLC (1766-L32AWA/B) that we want to use for simulation purposes in our office and possibly at trade shows, etc.  I don't need to learn everything about programming and operating these devices (at least I hope not), but mainly need to understand how to load data into the PLC and read it out.  We also have purchased Kepware OPC software that should talk to it. We are connecting via Ethernet.  In my research so far I have learned a little about how PLCs work and ladder logic programming but I have a couple of fundamental questions: Do PLCs store data (say the values of temp probes, etc.) over time or do they have to be read instantaneously before those registers are overwritten?  Is there a way to load data into the PLC without having to physically fabricate test objects that it can measure and/or do a lot of programming?  Can someone recommend a resource that can explain what I need to learn without having to become a full PLC/Automation expert?

2. We would like to purchase or create a device that we could take onto the shop floor and temporarily connect to stand alone PLCs to read and store their data so we can show it to them in our software.  Something portable that we could connect, read data for a few minutes and disconnect.  Does anyone know of such a device, or would it simply be a laptop running OPC server and client software?

I realize this is a lot to ask, especially for a first post and I greatly appreciate any help.  Most of us are very new to this particular technology and I for one need all the help I can get!  Thanks so much in advance for any assistance.

Alan C

 

Share this post


Link to post
Share on other sites

I have only used Kepware OPC to pull info from PLC's That are not AB for FTView ME to run status displays.

I would think a laptop running the kepware OPC server should get the data from the PLC to the Laptop in most cases. What kind of data are you wanting to read?

I have ran into a few PLC's(mitsubishi q series) that do not like talking to kepware from their serial ports. Im not sure how this may affect it using ethernet though.

Keep in mind that if you are using a Micrologix 1400 you will also need to buy a license for RS500 programing software, download and install to be able to connect to the PLC and program it.(if you know this already I apologize, it was not mentioned in your post)

Share this post


Link to post
Share on other sites

Thanks Twigums.  We don't know yet what data we want to read, it will either be something we simulate, or could be anything from client devices.  I'd like to know if can I just load data (values, etc) directly into the registers via Ethernet or do those registers have to get their inputs from the input ports and programming?  Thanks for the heads up about the licensing, I was not aware of that.  It would be great if there was a PLC simulator device, rather than us having to build something with production hardware and software.  My manager thinks there is but I have not been able to find simulator hardware.

There are really two communication/interface issues here, one for programming and one for control/reading (OPC, etc.).  Can they both be via Ethernet or does it have to be programmed via a serial connection?  Thanks again.

Share this post


Link to post
Share on other sites

That's a big task...

My suggestion for right now is to get a MicroLogix 1100 instead of the 1400. The 1100 can be programmed with the free version of RSLogix 500. It can communicate to  your data collection software at the same time as the PC running RSLogix, both over Ethernet.

There are drivers available from Advanced HMI, Peak HMI, Ingear, and Ignition, to name a few. Advanced HMI is free and will get you going pretty quickly developing programs in Visual Studio to talk to your AB PLC. I don't have any personal experience with the others, though we do have a system on which the OEM used Ingear's software to manage a machine vision system that talks to a ControlLogix PLC.

You'll have to figure out which system works best for you, based on the installed base of the clients you plan to work with. For example, if you wanted to run a demo in our facility, we would like to see you connect to:

1) AB ControlLogix/CompactLogix via Ethernet
2) AB MicroLogix 1400 via Ethernet
3) Siemens S7-300 via Ethernet (Profinet)
4) Siemens S7-1200/1500 via Ethernet (Profinet)
5) AB SLC 5/04 via DH+ gateway connected to Ethernet network
6) AB PLC-5 via DH+ gateway connected to Ethernet network
7) Siemens S7-300 via Profibus DP

Just the first 4 options (the easiest) may be daunting. And that doesn't include the other models that we know would be too hard or simply impossible. Getting an ML1100 will get you started, but I think you'll need a fairly significant investment in PLC programming software to do this right.

Share this post


Link to post
Share on other sites

PLC’s basically run ’real-time’ and do not routinely store data unless specifically programmed to do so.   ’HMI software’ (several flavors listed in the post above this one) takes on the task of communicating with the PLC to get data from or to write data to the PLC.

As someone noted, some PLC comm ports are for programming, others for data transfer; depends on app specifics.   

It takes a ’driver’ to talk to a specific brand/model PLC.   OPC server (Windows software) are like a gateway; one side has a driver that talks to the  PLC, the other side exchanges the data from the PLC with an OPC client.   OPC clients are built into most HMI software packages nowadays. 

The latest iteration of OPC, OPC UA, is friendly on the server-client side, listing PLC configured tags in the client, but the driver side still requires ’building a tag database’ for many devices.  

I think the proposed task is incredibly ambitious.  I find the prospect of connecting to a variety of installed controllers daunting, to say the least.  

It’s my opinion that the world of IIoT is largely an illusion with its implementations requiring significant programming effort.

Best of luck in the endeavor.

 

 

 

 

Share this post


Link to post
Share on other sites

Thanks for the very helpful replies everyone.  I'm going to chew on this for a little while before making any more decisions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now