DLB

Read/Write between AB PLC's

19 posts in this topic

I am fairly new to PLC Programming and hope that I may be able to get some advice you guys :) However, I have around 18 months experience building SCADA systems which means I have a sort of overall understanding as to how PLC Programming is done. I have an upcoming task which is to involve some PLC coding. I don't have the exact details yet of it yet but I expect that is going to be mainly focused on transferring data from one PLC to another (ControlLogix, so development will be done under RSLogix5000 I guess?). I have yet to be explained exactly what data is being passed between the 2 PLC's but please could somebody explain to me the steps taken to read from/write to another PLC? I have been looking into the MSG function and the Message data type but I've not yet been unable to build up a clear representation as to how these are used. Any help and advise would be massively appreciated! Thanks

Share this post


Link to post
Share on other sites
Check out the PDF Below, it will tell you how to setup and use messaging instructions. MSG If the data is to be sent from one control logix plc to another control logix plc they will most likely use produced and consummed tags. See link below. Link

Share this post


Link to post
Share on other sites
Thanks for the links Steve! I've read down to page 17 so far, but I'm not understanding it. A couple of questions that have arisen so far are: 1. What are produced and consummed tags? [EDIT: Apologies, I have just had a quick look at the second link and realised that it explains produced and consumed tags and also that you had already told me this :) ] 2. What does CIP stand for? 3. What does 1 position in the throttle represent? Maybe I don't have enough background knowledge to understand the MSG instruction just yet? I'm not sure. Am I right in thinking that if I wanted to take a BOOL tag (btag1) from PLC1 and write it to PLC2, that I configure a Message tag and set its value to that of btag1, then use the MSG function to write to PLC2? I am also wondering, if PLC2 wants to continuously get hold of data from PLC1, is it better to have PLC1 constantly write the data out to PLC2, or to have PLC2 continuously read PLC1? Sorry for so many general questions. I'll know more once I get the job details. I'll keep on reading.... Thanks Edited by DLB

Share this post


Link to post
Share on other sites
If you are moving data between Control Logix boxes it's easier to use Produced / Consumed tags. <EDIT> My bad... Steve already covered that. Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
CIP("Control and Information Protocol") = Application-Level, Object-Oriented, Connection-Based communication architecture shared by Ethernet/IP, ControlNet and DeviceNet Rockwell Automation communications protocols in order to establish interchangeability and interoperatibility between products from different vendors. If by "throttle" you mean the CIP Message Comms.Path, 1 represents the Virtual Backplane of the Logix System. Now, back to the data transfer between Logix PACs... It could be done two ways: 1. Unscheduled Data Transfer; data is transferred (read/write) within the so called "20% Time Slice" interval of the Logix Controllers "Complete Cycle Period" at the configuration rate of the Communication Adapters used by the forementiond CLXs. This is usually being implemented by establishing of a "Dedicated Produced/Consumed" subnet (Ethernet/IP, ControlNet) between the processors involved within the data transfer. A Produced Tag of ANY networked PAC is availabe at "ANY" Time to ANY of the others controllers on the subnet IF they contain an IDENTICALLY SPELLED Consumed Type Tag, of THE SAME DATA TYPE as the Produced Tag within their Controller Tags. You do not have to program any logic related to the Produced/Consumed data transfer; it is being done automatically and even you cannot call it deterministic (predictable) is is usually faster than any "scheduled" data transfer. 2. Scheduled Data Transfer; data is transferred via the MSG instruction, which has to be programmed within a routine of your project's documentation. The routine containing the MSG is being called as part of a Task, Task which could be furthermore prioritized by defining of a Task Period. The Task Period represents the "call frequency" of the routine containg the MSG data transfer. This type of data transfer is deterministic by its nature; the Read/Write occurs at "Constant Frequency" determined by the Period of the Task containg the MSG defining Routine.

Share this post


Link to post
Share on other sites
Fantastic, that makes much more sense. I'll read through the link posted by Steve on P&C Tags. No doubt I'll have a few more questions to post up in the next couple of house! Thanks for your help so far!

Share this post


Link to post
Share on other sites
A few comments, maybe not so important, but 1. CIP I was under the impression that it was "Common Industrial Protocoll" 2. A message instruction is never Determenistic as far as I know. While a produce/Consumed tag can be Determenistic if it is used on ControlNet (No other Rockwell network is 100% determenistic) 3. A message instruction is not scheduled, sure you can send it with a certain interval, but I would not say that it is scheduled. If anything is scheduled it is Produce Consume, since you do put a RPI time on them. 4. I think that the Produced consumed data actually is sent by the I/O processor in ControlLogix, so it is independent of the Timeslice. While messages I think needs some overhead taken from the timeslice (I could be wrong but it is my understanding) If you are communicating with 2 Logix5000 systems (ControlLogix, CompactLogix or even the old Flex Logix) Use Produce Consume. Keep down the amount of produced consumed tag as much as possible, by combining data in UDT's and send. Each tag takes up connections and you have a limited amount of connections. When you create a UDT that you want to send you should copy it to the project where you want to receive the data also. There are a few reasons that messages could be better, if you want to keep down the amount of packages/Second a message could be better since it is not sent automatically... If you are communicating between a 5000 system and something else, it is easiest to do it with messages, though there are ways to use produce consume on SLC and PLC 5 systems also, but it is not as easy.

Share this post


Link to post
Share on other sites
Thanks for your input. I am unsure of your numbered comments, but I am sure someone else will be able to elaborate and compare to previous posts! I terms of connections though, how is it possible to calculate the maximum number of connections? How are they measured? Also, if anyone could explain RPI that would be a big help. Looking at the posted documents and some others that I have found whilst trawling the net, it seems as though the RPI (in RSLogix 5000 v18 at least) can be manually set for multicast transfers but it doesn't explain exactly what the time values mean exactly. It just says that the producing and consuming controllers should have a matching RPI, or the consuming controller should simply be within the RPI range specified by the producing controller. I guess from the Remote Packet Interval I can sort of guess what it means but an explanation in simpleton terms would be nice :)

Share this post


Link to post
Share on other sites
The best place to get information about rockwell is their literature library and their knowledge base. You can find all sorts of facts there. Regarding connections, I know there is a good manual for ethernet that have detailed information about counting connections, but I could not find it now. If you have a techConnect contract you can check on the knowledge base, I found this document quite fast: http://rockwellautomation.custhelp.com/app/answers/detail/a_id/56682/kw/count%20connections Regarding RPI, you are more or less right there. It stands for Requested Package interval or something similar, and it tells I/O cards and other data producing devices how often it should send data. So if you set it to 20 for a device it will send data avery 20mS. Just a side note, that does not mean that you get new data every 20ms, other factors affect it such as Network delays delay due to scan times and such things.

Share this post


Link to post
Share on other sites
(Common Industrial Protocol)CIP = CIP(Control and Information Protocol); Since we are talking "Logix",Rockwell Automation preffers the latter description due to the fact that they were the ones who introduced it in 1998. If deterministic = non-random, then ControlNet is the only 100% DETERMINISTIC comms network BECAUSE IT HAS TO BE SCHEDULED! On an Ethernet/IP network you could set the RPI (Requested Packet Interval) of A CONSUMED TAG (ONLY!) at 20 ms, however if your comms bridges are RPI-ed at 10 and 30 ms respectively ( or they are running close to the connection number limit or within high memory usage) the tag WILL NOT BE UPDATED every 20 ms. Moreover, IF THE TAG FAILS TO BE UPDATED, THE PROCESSOR DOESN'T KNOW ABOUT IT! Unless within a ControlNet environment, the "RPI Schedule" is more or less a TENTATIVE SCHEDULE! ( Lotsa randomness in the "tentative" definition! ) A programmed MSG instruction offers 5 status bits which, if monitored, could give you a pretty good indication (OF COURSE NOT 100% DETERMINISTIC! ) of the state of the data transfer. Moreover, you could program your way to a more efficient data exchange. The common accepted practice is, indeed, within a strictly RA PAC environment, to use Produce/Consume over Ethernet/IP or ControlNet. However, you could Produce/Consume data between ANY ROCKWELL PLC/PACs+SoftLogix(except MicroLogix family) with either Ethernet/IP or ControlNet comms capabilities. The reciprocal is also true, you could use MSG data transfer between any Rockwell PLC/PAC with a little twist; the comms protocols list expands to ANY ESTABLISHED COMMUNICATION PROTOCOLS. Now, back to the Connection and RPI. A CONNECTION is AN ESTABLISHED COMMUNICATION BUFFER BIN where data to be read/written is placed prior to the actual transfer. Any processor and communications bridge COULD HANDLE only a LIMITED NUMBER OF CONNECTIONS. For example a 1756-ENBT Series A Ethernet/IP bridge could "handle" no more than 128 Logix Communications connections and no more than 64 TCP/IP communications connections. On the other hand, 1756-EN2T or 1756-EN2F bridge connection number limits are 264 and 128 respectively. A Produced Tag uses (# of consumers + 1) connections A Consumed Tag uses 1 connection. The Requested Packet Interval (RPI) is the POLLING FREQUENCY (in milliseconds) of the established connections or, in more simplistic terms, how often the processor is to "open up the data valve". That's where the fun starts! Manually "scheduling" an EtherNet/IP network could be a tedious process! You will have to prioritize data, "guesstimate" the complete transfers duration, set the RPIs accordingly, decide what's to be cached or not and then run the Task Monitor Manager for days on end to realize that it doesn't quite do whatever it was told to do!- Back to square one! Or you could go ControlNet and either Logix 5000 or RSNetworx will do it for you! Or better yet, don't maximize your expectations but go maximum bandwith, high end processors/comms bridges/switches and you don't have to worry about the EtherNet/IP timing. 100Mbps will do it for you!

Share this post


Link to post
Share on other sites
Yeah, and shut down your whole system every time you have to add/change IO because you have to shut down all processors on a network to load in a new schedule whenever you reschedule. With Ethernet/IP, I can even add/remove/change IO while the system is running, even on processors that are running. Charge your customers no less than about 3-4 times what it would cost with competing network technologies, at 5% of the speed. What a wonderful system. If I run Ethernet/IP as slow as Controlnet, all these arguments about being deterministic and scheduling problems go away because the Ethernet/IP network is loafing along with practically no load. Even AB realizes that it's time to move on. The "deterministic" problem with Ethernet/IP is just the timing jitter. Their new servo drives utilize the coordinated system time (CST) functions to update the control loops where update times are a variable. This simple trick allows them to run servo drive control over Ethernet without using modified Ethernet systems like Twincat. Ethernet/IP is a lot simpler than that. You have a maximum of 600 packets/second on a drive (weak 2x-COMM-E cards), 5000 packets/second on an ENBT (double that on EN2T), and about 6500 on a Flex IO. It is very easy to calculate the loads, and RSNetworx does it all automatically for you. However I have noticed that in practice, CPU limits get you well before total packet throughput does. They are roughly half of the maximum specified packet limit, and AB recommends not allowing CPU loads on the communication cards to get over 50% CPU. So that leaves you with roughly 1250 packets/second as a practical maximum on an ENBT, whereas at the switch level, loads of over 100,000 packets/second are reasonable given that Ethernet/IP traffic is mostly 64-80 byte packets (the minimum). To get even close to this, you really need switches that can do congestion control (AB switches can't do it, only high end Cisco switches with policing policies can do it in their lines, and Hirschmann and upper end N-Trons can do it). Before even getting there, it is critical to make sure that your IGMP querying works, or else packets=packets since your IO hardware and produced/consumed tags will just bleed all over everything. This keeps your packets flowing only where they are supposed to go. Or go to Rev. 18 (and 5.1) on the processor and cards, and you can use Unicasting with 1756-chassis. Some (not quite all yet) remote IO already has unicasting capability. In an Ethernet environment when I have maintenance issues, and it's cable related, EVERY device in the network (if the switches are managed) has diagnostic data that directly pinpoints the problem. If you do have a problem, only the link that is damaged is affected. It doesn't take down everything else in your network (unless you don't have any redundancy). In Controlnet, you can have redundancy (if you pay for it). Then if one cable system fails, you've got a backup. You won't know where the problem is, only that you have one. Fortunately, it's easy to find. Just dig out the oscilloscope and start searching! The only thing worse than finding a DeviceNet network problem is finding a Controlnet network problem. Because Ethernet is a segmented network, problems are isolated to just a single segment rather than affecting the entire network. This makes it much easier to troubleshoot. Hence the reason that when you dig through the hype it turns out that Controlnet offers: 1. Deterministic RPI's and jitter. Ethernet offers only RPI's but at 20 times the bandwidth, and the capability of operating in coordinated system time (we know exactly when the packet arrived, even if we can't control exactly when it will arrive ahead of time), this disadvantage vanishes. 2. Cable-level redundancy. Until recently (EN3T), you could do redundancy at the switch level but not at the cable-level. This is no longer the case, even without the "single path" issue between the PLC and the first switch. 3. Frustrating troubleshooting experience. Gotta love the oscilloscope as a troubleshooting tool. 4. IO changes are much safer because adding to or changing your IO requires that you take down the entire network (unless you give up determinism and have the NUT to spare). Clearly in a continuous process this means that IO changes have to be scheduled around major plant-wide outages, reducing the load on the maintenance group for "little changes". 5. Massive profit margins for Allen Bradley because of all the little TNC connectors, bus modules, higher cost of coaxial cabling, higher cost of modules, lack of third-party competition, etc., etc. 6. Much slower speeds, preventing you from ever getting to the point of overloading your communications architecture. You simply can't "push" a CNB card to it's limits. 7. No chance that you can take advantage of shared infrastructure such as sharing gigabit fiber or wireless links with another system. 8. No compatibility with commercial equipment that would allow you to adopt wireless or travel across some kind of foreign network if needed...in short, you can't use 802.11 or any similar standards now or in the future. 9. Very expensive cards to interface to your PC for troubleshooting, along with all kinds of compatibility problems as PC hardware/software changes over time. 10. Media problems propagate across all equipment and are not isolated to just the spot where the problem is at. 11. Extra software. You MUST have RSNetworx in addition to Logix 5000, and have to maintain yet another configuration file.

Share this post


Link to post
Share on other sites
Paul, It is pretty obvious what would be my choice when it comes to decide between CNet and Ethernet/IP... Just concentrate over last sentence of my previous post...100Mbps says it all!... However, CNet is still widely used and, in some critical instances, THE ONLY COMMS PROTOCOL APPROVED TO BE USED, because of its DETERMINISTIC nature...Yes, it is a pain to have to shut down an entire system for a simple hardware replacement or firmware upgrade, but, again, even with a signifficantly narrower bandwith, THERE ARE NO RANDOM EVENTS WITHIN A CONTROLNET SYSTEM...PERIOD! I agree, nowadays EtherNet/IP communications within Logix platforms are a far cry from their humble begginings...Hopefully, sometimes in the near future, its non-deterministic component will trully be equal to zero. However, today, March the 10th 2011, when a PAC waits for THREE MISSED PACKETS to declare a CONNECTION FAILURE, and then RESTARTS IT AUTOMATICALLY like nothing has happened, makes me declare, again, that AS FAR AS I AM CONCERNED, A LOGIX PROCESSOR DOESN'T KNOW WHAT'S GOING ON when it comes to EtherNet/IP communications... IT MERELY TRYS TO KEEP THE BUFFERS FUNCTIONAL...A single missed Data Packet IS ONE TOO MANY when being part of a time critical application...Writing communications monitoring code and decision making logic following a comms failure has become a staple within any EtherNet/IP project... ...Talking about efficiency... As for the ROCKWELL SOFTWARE PLATFORMS MSG instruction communications options, of course I meant that you could MSG, again, BETWEEN ROCKWELL PROCESSORS PLATFORMS, not only over CNet and EtherNet/IP, but also over DeviceNet, and DH+. I don't recall using the "communications implementation" subject anywhere within the communication options differences between the Produced/Consumed or MSGed data transfer. I stated that YOU COULD PRODUCE/CONSUME DATA ON ETHERNET/IP AND/OR CONTROLNET BETWEEN ANY ROCKWELL ROCKWELL PROCESSORS (including SoftLogix-except MicroLogix) IF THEY (the processors) HAVE ETHERNET/IP AND/OR CONTROLNET CAPABILITIES. What's wrong with this statement?! The thread was started by someone who is new to industrial automation communications; trying to comprehend the Rockwell Automation Literature Library information is not an easy task. THEY know it and WE have to deal with it until the (hopefully on their way) signifficant improvements arrive. Questions were asked about the data transfer choices within a Logix platform and also some Rockwell terminology needed to be laid out in a simpler form. I have tried to help a little and NEVER INTENDED TO GET NOWHERE NEAR THE HORNETS NEST OF COMMUNICATIONS THEORY. Everyone of us is trying to get things done, to the best of our abilities, using the currently available options. Let's not make it harder than it already is!

Share this post


Link to post
Share on other sites
The literature library is definitely somewhat daunting at first, which is why I posted up here as well as ready everything I could :) I appreciate all who have tried to help me in this thread, despite it turning into a communications theory debate ...not that I am bothered. I am actually glad of the last few posts as they have helped me to see a bit deeper into the comms structure :) Back on topic... Is there a sort of threshold in the amount of data being transferred to use produce/consume tags over MSG instructions? I get the impression that for transferring a integers here and there that it is better to use MSG instructions, where as produced/consumed tags are better when there is a greater amount of data needing to be transferred. Is this correct? Well I have some more information on the work I am going to be doing. I am effectively setting up a test rig to simulate a PLC out in the field, along with a couple of HMI's. The PLC will need to have simulated inputs, but I am unsure whether it would be better to have an input card with some switches attached to toggle them on and off, or whether to just have internal bits inside the PLC to which I can toggle via the HMI (over TCP/IP). Depending on these inputs, there will be some logic inside the PLC to carry out simulated outputs (when again, I guess I could simply set internal bits and show the values of these on the HMI), as well as transfer data to another PLC. Technically, it doesn't seem like rocket science. I just need to get the design sorted out and then start playing around with the hardware. Any advice would be greately appreciated. Apologies for a pretty general question/post! Thanks guys Any advice would be greately appreciated!

Share this post


Link to post
Share on other sites
Now I think that finally we almost have provided a answer to a very easy question... I have always used produce and consume. To see that the data is transfering I have been using watch dogs, and sent it both ways always counting up with one and then a reset when it reaches some high value. I belive that you can also monitor the status of a consumed tag, but it is not as simple, (I do not think you can monitor the producer) As far as all the status bits and being able to see that you missed a message.. and all that Well, yes you do have all the status bits and can see if you got error on a message, but what you are missing is that it can take a couple of scans to complete a message instruction, so it might take half a second before you realize it or even more (I do not know the exact numbers, depends on message size and CPU load and stuff aswell as the setup of the message) So with all this in some cases it might be faster to use a watch dog on a produced tag. And even with messages the way I have been using them is that I retry to send the message a couple (Usually 3) times before I set any alarm... Using only the status tags on the message, you only get to know if anything went wrong in the PLC with the message, by sending a watchdog back and forth, you can alarm in both PLCs. But in the end it depends on the requirements of the application, on what can can be accepted or not... And a side note RPI is not the polling rate of an I/O card. Clx Processors does not poll data, it configures the card and then the card sends the data automatically with the RPI time...

Share this post


Link to post
Share on other sites
I'll give you one idea for thought when it comes to simulations. If you are writing a large, complex PLC program (hundreds of rungs) it is pretty easy to fat-finger something and have a simply typo that can cause you a lot of grief later. Break your program up into at least 4 layers: 1. Operator HMI stuff. Usually just error-checking and boxing/unboxing the interfaces (if you need this). 2. High level stuff (including some housekeeping). This is where your "process logic" resides, like fully automatic routines. 3. Unit operations. This is where the code that "runs" something like a pump or valve or fan lives. Auto/manual code goes here along with interlocks. 4. I/O interface code. "Glue logic" goes down here. Now in a "simulator" version you simply write some "stupid" code to go in at layer 4. Things like when it receives a "start" command, it has a timer to simulate the run feedback from the starter. And if you want to simulate a failure, simply break it here. In the real thing, this is the only code that talks directly to the IO. Now you can let the operators toy with this "fake" system and try to break it every way possible. Since only the low level "IO glue" logic is different in the "real thing", you can do 100% of your troubleshooting in the simulated version before doing the first field work. After IO checkout is complete, 90% of your bugs are already discovered and fixed. So after functional capacity testing, you can go almost immediately into production with very few hiccups. It costs a little more up front to do it this way but you will save on overall project time and costs because it is debugged ahead of time. Edited by paulengr

Share this post


Link to post
Share on other sites
Fantastic information! The MSG and Produced/Consumed tag debate is a much clearer now. When you talk about layers, I guess you mean that I should split my ladder logic into different tasks? The way I had looked into writing it was using state sequences and splitting the code up in each task that way. Although I'm not really sure what sort of states I will be able to split the logic into until I decide on functionality. In terms of faults, it is a requirement that the system replicate faults at the click of a button. ie, a button on the test HMI which might read "Simulate Fault" which will then change simulated PLC input values. I'm a bit confused about how I am going to go about things at the minute. Hopefully things will be clearer to me when I have got the requirements down on paper and put some sort of design together :)

Share this post


Link to post
Share on other sites
It's easy to do if you are simulating all the IO. Simply think up the basic "what can go wrong" stuff and insert the appropriate hooks to generate the required fault. This becomes something of an iterative process (akin to "use cases" in modern PC programming).

Share this post


Link to post
Share on other sites
Thanks for all the help so far :) I've had a bit of a break from the PLC code I was asking about but started playing around with MSG instructions today in RSLogix5000 v17. I am using an example that comes with the package (attached) but I seem to be getting confused by parts (despite it probably being really simple to you guys :) ). Rather than me explaining where I am confused (as it is quite hard to explain), would anybody be kind enough to edit the logic and controller tags to just read from one controller? Then hopefully I'l be able to see things a bit clearer! I'd massively appreciate it! Fearne Cotton --> .............sorry, couldn't resist. It's Friday and I'm in a good mood

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