Sign in to follow this  
Followers 0
ETJ

LogixPro silo simulation completed - Comments please

9 posts in this topic

Hi.. I'm new to plc.. I've just completed the Silo simulation exercise 3. I know it has alot of rungs because my initial idea is to activate output by using state/flag instead of input. This is so that it is easier to modify the coding later on if needed to. But i'm not sure whether it is necessary to do so or not.. Can somebody please comment/advice/critic..? Thanks..

Share this post


Link to post
Share on other sites
My first comment is about your comments. Excellent job! So many projects get posted without a single comment. Not only does it help us follow the program but it is a good practice to get into on real programs. While it may be fresh in your head today, a few years down the road when you get called into troubleshoot that machine those comments will be priceless A quick glance at it shows some well thought out code. It is easy to follow which is good. I love to criticize others code, especially a newbie, but it looks like is satisfies the criteria of the exercise nicely

Share this post


Link to post
Share on other sites
yay.. thanks.. I was abit worried when coding it because i 'wasted' 4 rungs. I could have saved 4 rungs if i'd connect the output directly to the input for run light, motor, valve and filling light. If I remembered correctly, the logixpro student exercise said not to use too many rungs for the program.. I also came across some program using fewer rungs but look more 'professional'.. But then again... I was trying to think in terms of maintenance and easy modification.. Hmm.. newbie's insecurities I guess..... Btw, is there any right method to planning and programming apart from writing comments..? I was thinking since I've jst started learning plc programming, might as well as do it the right way from the start.. hmm... Thanks again..

Share this post


Link to post
Share on other sites
I love your commenting! Some 20+ yrs ago, I was a co-op student and spent a month commenting a PLC ladder because the engineer "didn't have time". The electricians loved me and groused about the engineer. Keep doing that and you'll make friends with the maintenance crew. Just thinking about other types of controllers... specifically AB ControlLogix... What you did with the internal bits is good. Some of the newer controllers actually want you to use internal bits for all the logic and then transfer them to the input/output image all at once. I would have mapped your internal bits a little differently. If you know your output order before starting, make your internal bit order match so you can simply do an array copy (1 rung) instead of bit by bit unless there's a specific reason for it.

Share this post


Link to post
Share on other sites
Thanks... I don't quite get what you mean by that or how to do it.. Can you please give me some example..? Thanks..

Share this post


Link to post
Share on other sites
How you do it is that you have say a 16-bit word, or you create a 16 bit array with individual bits. Then when you go to transfer the data into the I/O card, you treat it as a full word and write it to the card, or vice versa, you read an entire word at once. The biggest reason that programmers do this has to do with having race conditions in their logic. On older PLC's, there are 3 phases in each scan. First, the PLC reads all the inputs into the input image table. Then it solves the logic (aka "runs the program"). Finally, it writes the data in the output image table into the output devices.Race conditions dealing with I/O in a single scan can't happen because from a program point of view, all I/O is updated "simultaneously". On newer PLC's, this is not the case. I/O is updated independent of logic solving. There are a couple reasons for doing this. First, quite often 90% of your I/O isn't changing state at all and it wastes time and resources to constantly update a value that doesn't actually change. Second, it allows your program to get an updated value and react to it as fast as possible, frequently achieving sub-millisecond response times for very fast processes such as high speed (10,000 piece per second or higher) equipment or motion control. However, this super-fast I/O sets up an issue that you need to be very aware of as a programmer. If you have sequential logic that depends on the inputs and you read the same input from different locations in your program, you cannot assume that the input bit will remain the same value. I/O is now independent of logic solving. This sets up a race (which happens first), which can lead to all kinds of strange errors in the sequencing of a program, if you are not cognizant of it. Simply copying the entire bit or word "solves" the problem by making a modern PLC act the same way as an older PLC. It masks the problem. The real solution is to program your system in such a way that there are no race conditions like this. There is a huge reason for NOT doing this. I've dealt with an entire system that the programmer did this with it. You just destroyed the link between the real I/O location and the internal states. This gives electricians huge problems when they try to troubleshoot it because there's always an extra level of indirection in troubleshooting it because they always have to figure out the "I/O map", and then go find the real input/output. No matter how many times I've seen programmers promote this as a good thing, it isn't. PLC manufacturers quit using "I/O maps" (input/output image tables) as a paradigm for lots of good reasons. I'm sure there were lots of heated debates about doing this. But in the end, it's a good thing and I suggest you adopt it too. There is a much better way of doing this. It uses "separation of concerns" or SoC (google for this). This is the modern incarnation of the old "modular programming" style promoted since the 1970's, but with a specific direction in mind. With SoC, break your program up into separate pieces that duplicate the real (or virtual) world of the process itself. So you'd have say one piece for each tank, pump, or any other distinct process component. The smaller piece actually starts/stops the process and provides status bits. I like to encode the interlock logic that cannot be disabled, even in "manual" mode, and local auto/manual control directly in this section. I prefer to avoid any higher level sequencing beyond this, such as verifying that the downstream conveyor is running before running an upstream conveyor (this is better served at a higher level and there may be good reasons for disabling this in manual mode). It deals with the real I/O. It has several inputs such as "Auto start", "Auto Stop", etc. It also has several outputs such as "Running status" or "Faulted". It does NOT look at the hardware inputs/outputs of a process under the control of another section of your program such as an upstream conveyor. It only looks at the real, local I/O and the higher level status bits supplied by other similar pieces. An actual sequence such as starting/stopping or controlling the overall process happens in a totally separate piece of your system. This piece has NO references to the hardware I/O. It relies on the software subsystems to handle "low level details". Frequently these subsystem programs are less than 20 rungs long so it is very easy to avoid race conditions if they exist, and frequently (such as with tanks and pumps) they are all identical so you can do a lot of copying/pasting or write some sort of subroutine logic (if available) so that in effect, there's really only one copy to maintain. This last piece is where object-oriented programming comes into play but so far, the PLC world is in it's infancy as far as adopting this sort of thing. The advantage of this programming style is that it is much easier to troubleshoot. Usually other than figuring out "where it's stuck", you don't have to do anything to the overall sequencing functions. Those functions don't have race condition problems because they don't deal directly with real-world outputs. They deal with the status bits of the subsystems. In turn it is very easy to troubleshoot a "pump" because you can go right to the pump logic and you only have to look at about 10-20 rungs of the pump logic itself instead of searching through hundreds of rungs to figure out how the "pump" interacts with the overall system. This would seem to be a lot of overhead and slow down the overall system, but the same logic is being executed with just some extra internal state bits. In practice it doesn't slow things down significantly at all, and more importantly, it decreases the probability of subtle logic bugs creeping into your program, and decreases the troubleshooting time dramatically. Commenting the heck out of every rung becomes less important and the program is easier to understand because there is a logical structure to the overall system, also reducing troubleshooting and maintenance time. Both of these are well worth the additional cost of organizing a program this way.

Share this post


Link to post
Share on other sites
Thanks paul for the indepth writeup.. Read it once but will definitely read it again when I have more time to enable me to digest it more.. Thanks again..

Share this post


Link to post
Share on other sites
Dont have the logix tool.. But when you ask about how to design i can provide an example... Did a similar program like you had but did some redesigns just to make it simpler for me.. First I thought about the sequence of events to happen then i drew a grafcet over this.. Then translated it to ladder and the result you have in attached pdf.. In my example the startbutton and the fill startbutton is momentary pushbuttons, the automatic fill and single cycle is switches (on/off) When you write more and more industrial programs the bits that today drives the outputs just will be orders to a motor/valve object to start/open and that object will handle its own alarms etc etc.. This code is today normally done as a FB(I work with siemens so the termonology may be wrong here) A typical motor FB could have these inputs Auto/Man AutoStart ManStart FeedbackCoil OverloadContact SafetyInterlock And these outputs Overload_Alarm Feedback_Alarm Coil Logix.pdf

Share this post


Link to post
Share on other sites
I purposely kept my comments very generic because for the most part, every PLC offers some way to do modular programming, and maybe even encapsulation or modularization, but each tends to be so unique that I didn't go down that road. Thats with Siemens which was one of the earlier PLC's to offer that form of encapsulation. Thus, the accepted practice with Siemens programmers is slightly different than what you would see with a programmer with a different PLC. With most modern (61131 based) PLC's, you can do it with separate programs and/or routines, and even the older ones could be made to have modular code with some creative use of code comments. In addition with ControlLogix rev. 16 or greater, you also have add-on instructions which perform the same duty as Siemens Function Blocks but are more generalized than Siemens FB implementation. With GE and AB, SFC's (the 61131 term for Grafcet) can be written directly. None have yet to embed data or types so it's not a full blown object model yet, but it's getting there.

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
Sign in to follow this  
Followers 0