Help needed learning "right" way to program

Hi all.
I know the answer to the title is probably that there is no definitive "right" way to program. But there probably is many definite "wrong" ways to program.
Anyway, I have been experimenting with PLC's at work for a while now and can usually get a plc to do what I wish with a bit of trial and error along the way: Try something, see if it works, if it doesn't, work out why, alter this, tweak that, learn from it, try again, and so the cycle repeats. I always suspected / knew, there was a much more organised way to doing this, and have recently been avidly reading through Hugh Jack's book as recomended by most people on here. What a great book - and for free! The section on state based programming particularly sparked my interest and made a lot of sense. Very straight forward structured way of converting logical process into states and transitions between states. The difficult part is realising what each state actually is.
I tried applying this to a couple of (hypothetical) real world projects and found it's a little bit trickier than the examples in the book.
I was hoping that somebody may have a look at my attached example for a three conveyor sequenced start and stop system and give me some feedback on it. I am sure it has many flaws, but would like the input from you guys that know much more than me, as I will hopefully learn something from the exercise.
I hope all that made sense, and thanks in advance.

You're going about learning the right way!

Note - it's an RSLogix 500 project with a drawing. I'd love to check it out, but I'm on my personnal laptop :-(. I may be back after you have undoubtedly already been critiqued.

For those that don't have RSLogix500 and Autocad, I converted you ladder logic and drawing to PDF files.

Didn't look at the program, put from printing it, I can say that your documentation of the ladders could use a lot of improvement. Need to add a lot more descriptions, especially on the ladders.

Welcome to the PLCs programers world.

First as Ken wrote it very hard to follow your ladder without good documentation.
Its the first roll for Right writing.Documentation
2nd write follow the process and divide the code to files which help to understand your intension.
1.main
2.motor start
3.faults
4.outputs
5.ect...
I also dont like the use of Latch and Unlatch with outputs.
You must be carefule when the power is up any motor might start with out command.

Improve what you need and come back againe.

I'm a beginner myself but i think there's a Sequencer instruction you might want to check out.

I'm like you trying to peck and scratch my way along trying to learn but I have taken two courses given by Rockwell Automation on RSLogix 500 (at $1600 ea.) and two courses given by GE FANUC (at $1200 ea.) and two courses by NTT National Technology Transfer on RSLogix 500 (at $800 ea.) and if I had to do it all over again and spend my own money I would take the course I'm currently taking FIRST. Check out George Brown College 'PLC Technician' course at www.PLCTechnician.com.

Also go to www.RonBeaufort.com when it comes time to learn about PID control before you dig up anything else on the subject.

Granted that the comments aren't in. What I am looking for is if the process could be laid out better in the flow chart, making it more straight forward to convert.
The program wouldn't actually work anyway as the transition T7 has "too many nested levels". This is due to the fact that I combined transitions, to make fewer transitions.
I guess I posted the files to show I am making a genuine effort to understand these processes, rather than coming along and asking for the job to be done for me - lock stock and barrel. From reading this site a lot I realize that asking for a job done on your behalf is not the way to go, and rightly so, there's not much to be learnt that way.
I'm hoping somebody may explain what I should have done to simplify the T7 issue. Or maybe I've set about the task completely the wrong way.

You want absolute efficiency? Instead of nesting branches, use the extend branch up or extend branch down.

E.g., your rung 25. On each of those outputs, you've nested a new branch. Every place you put a new branch, it technically takes 2 more words of memory -- plus, IMO, it just looks ugly. Using the extend-branch, you free up those 2 words/branch, and it looks cleaner. And those 2 words take up a little bit of scan time to evaluate. In this example, you're not really needing those 2 words/branch and scan time, so it doesn't matter a whole lot.


My suggestion for your rung 25:



Keep working with this -- you're doing great!

When working with state-systems, always do a state diagram like you did. It makes life much easier! You'll learn that programming will become much easier if you spend a little more time up front defining your system.

And document, document, document! That's what you're really lacking on your example. Document it as you go -- because you rarely will go back and finish the documentation after the project is done. If you don't do it as you go, it won't get done.

Thanks, Ken!

To address to Gazzr's comment -
1. I'm a fan of SIMPLIFYING whenever possible, so I'm inviting a flamin' here, but
a) Can you do an array read and single comparison on line 11 at once? Does this make sense if you're reading the code and envisioning the process?
b) This reminds me of a slightly OT question:
Do you remember De Morgans from propositional logic? Can you guys easily think with this as you go, or does it screw you up later?

not (P and Q) = (not P) or (not Q)
not (P or Q) = (not P) and (not Q)

For example (psuedo PLC-code) XIC A || XIC B || XIC C being equivalent to !(XIO A && XIO B && XIO C). (Since !XIO=XIC)

Do you just read past those in ladder without thinking about it, or are you trying to translate in your head to how the process works so logical equivalencies screw you up?

As with all bit-bangin', there's always an obvious point of taking it to the extreme! Perl programming comes to mind here...does (1b) do that?

Ken Moore said:

For those that don't have RSLogix500 and Autocad, I converted you ladder logic and drawing to PDF files.

Click to expand...

some startegy

Hi everybody,

I am new here. Hope to contribute something. What I saw in the program was a homogeneous, continuous flow of the logic which to my experience problematic in the later stages of the life of the code. It is very difficult to understand and very very difficult to modify on a later date. It also requires considerable testing. Ans as the saying goes Testing proves there are bugs but does not prove that there are no bugs. Hence it is not the ultimate certificate of correctness of the program. The code itself must certify the correctness.

So much for the theory. I have prepared a strategy for the problem in a hurry. I think some thing more is required to initialise all the motors on power up. But this document that is attached here will give a fair idea of the direction I am suggesting. The strategy is to follow the events that are expected to happen. No diversion. The code also will follow the document as is. There is no possibility of typing the program on a RS500 editor. I am sory for that but hope to help you in some way.

surferb said:

a) Can you do an array read and single comparison on line 11 at once? Does this make sense if you're reading the code and envisioning the process?

Click to expand...

??
Sorry, you'd have to expand on that one a little for me.
But I'm all ears.

What I am looking for is if the process could be laid out better in the flow chart, making it more straight forward to convert.

Click to expand...

There is an Event Box missing between "Startup Complete ST4" and "Stop M3 ST9". We have to assume that as soon as the Startup Complete event occurs, that we do not immediately go to the "Stop M3" event. Something else must happen first.

The T5 transition cannot occur unless another event occurs: The Stop button is pressed. Your state diagram does not show this STOP event, which is probably the MOST IMPORTANT EVENT in the entire process. Lancie's Rule #2: If you can't STOP everything, then you should not START anything in the first place!

This error illustrates one of the problems for State Diagrams. The process and procedures for making the diagram often get in the way of the common sense approach of simply asking the question, "What happens next?"

You probably would have seen this yourself if you had DOCUMENTED all the rungs in your program. Rung 009 should have a comment something like "When STOP is pressed, Transition T5 (System STOP) happens". Then the question becomes obvious, "How did I get to the point of pressing the stop button?" The STOP event should be able to occur at any point from State ST1 to ST4. Your diagram does not reflect this. Please don't let your love affair with State Diagrams stand in the way of good old common sense reasoning. I think you intend to stop it at any point with Rung 11. Your state diagram does not show that this is possible. If you want all states to be completely defined, then you would need to show the STOP relationship completely. That points up the fact that you didn't follow your own state diagram when you wrote the ladder logic. What were you following instead?

Also, for most material handling conveyor systems that I have worked on, even when STOP is pressed, you still want a time delay to unload the conveyor before stopping. Stopping immediately is usually done only when an Emergency Stop cable or switch is activated. Did I just mention Emergency Stop? Where is that on your state diagram?

I think it is very good.

I agree about changing the output logic.

Change the OTL instructions to OTE, and create a mode that regulates which bits have control of each output. So if your mode is manual, your sequence can't turn on motors. If it is in AUTO, the jog buttons don't work, and throw in a branch for power up if necessary to unseal, or seal in the right stuff for each occasion. Anyway, you get the idea.

Make those look like typical start stop jog curcuits, and you will be much better ff for troubleshooting.

Also, be careful with your transition definitions. I am not sure, but it looks like your logic can skip ahead more than one state per scan depending on Transition conditions. Make sure that is acceptable to the equipment/process, or limit State changes to once per scan.

It looks like you have the mechanism in place to choose that in the Transition definition section and with the way the timers are programmed.

Add comments to your timers. It looks like you use some of them as step TIMEOUTS, and others as step DWELL time. Very distinct difference that requires a comment or symbol.

Very nice, though you should be proud of a most organized and concise 1st programmed sequence.

EDIT: Also on your rung 11, all the nested branches can be changed to be more readable. Right click the corner of the rung and click Extend Branch Up/Down. Then they are not nested branches, but extended ones. You can also do this by drag and drop. Grab and drage a whole branch or a whole rung and watch for the little green and red target dots.

Thanks for the comments. I'll read them in more detail when at work with the software etc...
OkiePC - thanks for the note about rung 11 nested branches. As you can probably tell I am very new to RSLogix and AB in general. The majority of my previous experience was with Siemens MicroWIN, but somebody at my company has decided any future in house projects are to be AB, as are the bigger projects that we contract out, so I have decided to put my efforts into getting to grips with it as I find this is something I enjoy and would like to push for more opportunities to do in house projects. Need to get competent with the basics first though.

As for the comments about the use of Latch and Unlatch, I didn't really like it either. But the alternative of using the state to bring the outputs in would have meant a rung for motor 1 being "ON" for:
ST1 OR
ST2 OR
ST3 OR
ST4 OR
ST6 OR
ST7 OR
ST8 OR
ST9
I liked this even less! So went with the latch / unlatch.
I'm now thinking the way to go may be to have ST1 (Motor 1 start) come on and stay on. Then when conditions are right ST2 (Motor 2 start) do the same etc... But I'm guessing this is getting away from the state based design, as multiple states would be needed on at once.

Gazzr said:

the alternative of using the state to bring the outputs in would have meant a rung for motor 1 being "ON" for:
ST1 OR
ST2 OR
ST3 OR
ST4 OR
ST6 OR
ST7 OR
ST8 OR
ST9

Click to expand...

I like this rung. it is easier to look at once EXTENDED and not nested.

More predictable for the reader too. In general, use the fewest instructions that are logically equivalent, so you can either:

A, nave multiple ORs
B, have mulitple AND NOTs.

Choose the less messy, but the disadvantage IMHO to state sequencers is inflexiblity. It is easy to get caddy-wampus, just trying to insert a step, unless the logic has a "clean core".

So, you are right IMHO when you realize that doing it another way is getting away from the reason.

To me, the state engine is best when there is a lots of branching between various steps, but the sequence doesn't change from the original flowchart very much.

Build in the options you think you'll need, and be very cautious, when making live changes, to adhere to the original construct.

If the flow chart gets too messy or too many pages to cover it all, switch to a software DRUM sequencer. It, to me is more suited for and complex, and/or frequently variable sequences.

Good luck
Paul

Gazzr said:

...I'm now thinking the way to go may be to have ST1 (Motor 1 start) come on and stay on. Then when conditions are right ST2 (Motor 2 start) do the same etc... But I'm guessing this is getting away from the state based design, as multiple states would be needed on at once.

Click to expand...

The state engine is based on mutually exclusive states that follow a precise path through the flowchart they are designed from.

If your chart is designed to allow parallel paths, then you can have two states on at one time, but then you need unique transitions for each and every possible combination of paths. That really calls for another state engine altogether.

Then it can use the same core. Mutually exclusive, distinct states. Clear definitions of the branches, and usually a separate mode control.

Often, you may benefit from multiple state engines and they can be interlocked as, for example, a product leaves one station and enters the next.

That way, they can run "on their own pace" until they are waiting to exchange a product. That construction makes it easy to identify bottle necks in an assembly machine, and tweak the controls for better overall productivity.

I usually build my state engines like this in AB:

http://www.plctalk.net/qanda/showthread.php?t=29918&highlight=simple+sequence

Post #3.

Putting the transition logic directly in the state control engine makes it easier for me to match an already scrutinized flowchart accurately. Using the CLR (or FLL for more than 15 states) and reserving bit 15 for a "one step per scan" control lets me put all the output logic after the step control section and even internal bits that may already be true upon entering a step can be updated later in the logic. If they are true second time through, then the step can advance again.

This example is just that. It is not a complete system. There is input mapping/filtering left off the beginning, and there are diagnostics that can be strapped on too...like timestamping state values in a FFU/FFL stack for HMI display.