Just cannot get started

Kind of off the wall but i have been reading these posts for a while now and, I understand what your saying I read and understand ladder clearly but when it comes to writing my own logic i just cannot get started. Does not matter how simple or complicated I simply cannot " get started " a friend of mine usually write first few rungs and then I have no problems. What gives any ideas?

Jody

Try writing out the first couple of rungs in English describing out it works.

Like: If the operator depresses the START PB, the motor should start and remain running until the operator depresses the STOP PB or the motor overload trips.

Really can it be that easy? I am told that I try to write my programs to small that I am afraid to have to many rungs. Oh on another note does anyone know how to calculate rate of evaporation of water @ a set temperature?

Jody M said:

Really can it be that easy? I am told that I try to write my programs to small that I am afraid to have to many rungs. Oh on another note does anyone know how to calculate rate of evaporation of water @ a set temperature?

Click to expand...

Don't worry about the number of rungs. IMHO, you're a lot further ahead keeping your rungs simple and well documented so that others (and you at a later date) can look at the code and clearly see what its trying to accomplish. Make it too tight/complicated and it will ding you later.

My first rung is the Start and Stop button. Sets an interal coil called RUN. Next is a Pause coil if this function is appropiate.
After that, deal with each input one at a time.
After writing code for the last input, most if not all outputs will be written. Write for any outputs missed.
Don't worry about the number of rungs. You can do cleanup later after the program runs fairly well.
Finally, write rungs for error handling and alarms. You should be conscious of this throughout the coding process.

The most important part is documentation. Put comments on every rung - you can skip the most obvious.

Yes, it can be that easy. Just start at input 1.

I usually start at the begging of the process, or machine..before this i have assigned my I/O..(Most of the time time the first I/O is at the begining of the machine however it dosnt realy matter..the i do as jstolaruk said and start in english then convert to ABise or modiconise or whatever the case may be...after a while i stop thinking in english and just think in ise...yep i have missed a few here and there or changed on the fly...but i would much rather have a bigger program thats easier to follow than a small program thats packed in tight...

All
Thanks for the help I am starting another project today and I am determined to write this one on my own, again thanks.

Jody

Jody,

Try the PLC simulator http://www.plcsimulator.net/ That way you can see what's going on in the program.

Do simple circuits at 1st then build from there. Start with a simple input contact to operate an output coil. Then add a timer to turn on the coil. The add another timer to turn off the coil after you released the button. Then add a counter to count input Ons and offs...

Jody

I hate to disagree with a lot of the very experienced and reliable people who have posted already, but here goes -

If the operator depresses the START PB, ...

Click to expand...

My first rung is the Start and Stop button...

Click to expand...

Start with a simple input contact ...

Click to expand...

I suspect it's their description of what they do that I disagree with rather than the actual process. It may be it's become so natural to them that they do it without thinking.

Don't start with an input : start with the output.

When you're thinking about constructing your program, before you set finger on the keyboard, select an output and work back from there. Think about the conditions under which you want that output to come on. Think about the conditions that would cause it to switch off. Gradually design back from the result towards the causes. Use pencil and paper if need be. If the conditions seem really complicated, split them in to smaller problems and use internal coils to represent each of these. Now work back from each of the internal coils to get the causes as before.

Sure, once you're an old hand at it, you just dive right in and start coding without thinking about it. But if you're having problems getting to grips with how to construct the basics try starting at the end. It's like planning a road journey on a map (does anyone do that nowadays what with GPS?) - start at your destination and work back.

Regards

Ken

PS : Apologies to all those I have quoted! No offence intended.

I found the attached pdf file on http://www.industrialtext.com/freestuff.htm, It might help you to write everything out and then take it from there. I know I use this document more and more on my jobs.

Ken is absolutely right!

Start from the end, the outputs, and work your way back to the "causes".

   RUN IN

    AUTO     E-STOP

  ---| |---+---| |---(   ) MOTOR

           |

   RUN IN  |

   MANUAL  |

  ---| |---+

Then develop your code for the Manual Control, using Start/Stop Buttons, and the Auto Control, using whatever conditions are necessary.

The E-Stop shouldn't be used until the last rung where the actual output is controlled. That makes it very easy to determine right away if you have an E-Stop issue.

When you need to troubleshoot a particular output, go to the output, check the status of the conditions that should be driving the output.

If you don't have an E-Stop issue, then, knowing which condition should be driving the output, if that condition doesn't exist, go to that Control Relay Output and examine the code there.

You have to "think-out" the general concept before laying a single rung!

And, as has been mentioned, the best way to "think-out" the process is to write a general, verbal description of what you want to happen. This will help you to create a general description of the various modules within the process.

You can then move on to fill in the details in each of the modules.

It all boils down to the scheme that you were taught in grade-school on how to develop an Outline. Before you can even start the Outline you need to know what you are trying to accomplish. Then you fill in the general ideas that are necessary to reach that goal. Then you "flesh-out" the general ideas, and thus, the entire project, into functioning code.

What are you trying to accomplish?
Generally, what are the things necessary to support that goal?
What does it take to make those "things" happen so that you can reach that goal?

You go forward by moving backward... from the desired effects back to the required causes.

Jody M said:

Oh on another note does anyone know how to calculate rate of evaporation of water @ a set temperature?

Click to expand...

You'll need more than a single temperature to get evap rates unless you start assuming a lot of information. What you need is the psychometric equation, which I don't have handy. I'll look at the office tomorrow.

Pyschrometric Chart online:

http://www.rfcafe.com/references/general/images/psychrom_chrt.gif

Click on the pop-up button in lower right corner to zoom in on the chart.

The wet-bulb temperature, Twet, is related to T, P, and r, using Ferrel’s psychrometric equation


where e′wet is the saturation vapor pressure at Twet. Numerical iteration is used to solve Equation (4) for Twet at a given observed temperature, pressure, and humidity.

In another form,


e = es(T w) – γ (T - Tw)


where es(Tw) is the saturation vapour pressure determined at the wet-bulb temperature ,

(Tw), γ is the psychrometric “constant” ≈ 0.66 mb oC -1
,and T is the air temperature.


I strongly agree with Ken and Terry. Start with where you want to go, the Outputs. List all your Outputs and use the list as an outline to develop your program. One you list the necessary Outputs, you will probably immediately start thinking of ways to make the Outputs go on and off at the proper times.

Sounds like to me you just suffer from a lack of confidence in your abilities. Sorta that Oh No what do I do now, deer in the headlights syndrome.


I have been dong this stuff sine 1990 and occasionly have that feeling at the beginning of a new projects. To get started I look at the project scope for the simplest output to control, (I agree start with the outs and work back) and write the code for that output, by then my feet are wet and I usually get on a roll.

Good Luck

JohnM

G'day mate!

For what's worth? I have been learning about PLC programing for only the last couple of months myself and I also get that feeling of looking at a project and just having no idea where to start.
The idea that has worked best for me is to get some paper and start writing down some of the physical inputs and outputs. On smaller projects it's easy to do them all, on larger jobs I just look at what gets things going. I then on paper assign them the addresses I think I want them to have, then I look at the first output and write a rung or rungs to make that happen.
From there I have something to build on, it takes a few bits of paper and lots of rewrites but atleast I'm off and going.It could be really bad advise but I find it better to be redoing things more then I really need to, then looking at a blank screen.

Good luck, Richard.