traffic light program

Hi everyone, i was just having a look through the site to try and get a bit of help with a program i'm working on. i need to write a plc program to control a traffic light system for a project im working on. the inputs are sensors that detect the presence of cars. i've drawn a function diagram with the general outline of what i want the program to do but dont really know where to go from here. i would really appreciate it if anyone could set me off in the right direction with a couple of hints. thanks a million.
Elaine.

Requirement for help: Post again

Could you post your "general outline"? If your sequence of operations is detailed enough, the code will practically write itself. Since it's not doing that, you must be missing something. But we have no idea what that something is until you show us your work.

Elaine said:

Hi everyone, i was just having a look through the site to try and get a bit of help with a program i'm working on.

Click to expand...

That means that you will notice that the ol' traffic light program get treated with contempt by the regulars on this forum, but you seem to be different to most other posters of this question because you stated that:-

i've drawn a function diagram

Click to expand...

Now that is a start to solving your problem, if you have your function diagram correct, translating that into ladder logic should be a doddle, that doesn't mean it's going to work correctly the first time, but then again it just might. But it will get you up and running.

post your function diagram here and any ladder that you have written then we can be of some more assistance to you.

Edit I see Allen has answered in much the same way as myself while I was busy 1 finger typeing

Paul

The most common mistake beginning programmers make is trying to figure out how the program should look before you start writing it. That usually doesn't work.

The best bet is to wirte one rung of logic, even if it is wrong. Take something like an input from the furst car sensor, and have it turn on a timer. Then write a second rung, then a thrid, then go back and change what you did before becsause you now see mistakes, then ........

Programming is a process.

Post your steps so far, and your ladder logic, too.

[COLOR=blue]Tom Jenkins [/COLOR] said:

The most common mistake beginning programmers make is trying to figure out how the program should look before you start writing it....
The best bet is to wirte one rung of logic, even if it is wrong. Take something like an input from the furst car sensor, and have it turn on a timer. Then write a second rung, then a thrid, then go back and change what you did before becsause you now see mistakes, then ........ SPAGHETTI CODE

Click to expand...

I did not know you had Italian origines. Tom that is real wrong.

STRUCTURE
STRUCTURE
STRUCTURE
STRUCTURE
STRUCTURE

It must start with that.

Well, Pierre, yes, but .........

I agree that a well structured program is essential. This is certainly more true in a complex program than for a simple traffic light, but nonetheless it is true of any program. As you know from my past posts I always recommend starting with a point list, and a description of logic including major functions, and alarm lists, and adjustments. That is the beginning of structure.

My point to Elaine is that you have to get started. I sensed that she was frustrated in starting to create the logic. She said she already had a function diagram and an outline of the program, so her structure should be defined. Now she has to start writing code. The only way to get past the intimidation of a blank page is to put something on it!

Oh, my God, Tom...

SHOTGUN?????

From the Top Down???

You are promoting HACKING!!!

BULL$HIT!

Elaine, work BACKWARDS, ON PAPER, from Expected EFFECT to CAUSE!

What drives a RED, YELLOW and GREEN?
That is...
WHY do a RED?
WHY do a YELLOW?
WHY do a GREEN?

(154)

Tom Jenkins said:

Well, Pierre, yes, but .........

Click to expand...

Tom I never doubt your work habits. The text was more to promote structure to the newby.

I also prefer to tell them that if they really want to hunderstand how to ride they must mount that horse and GO!

Thats at the very beginning. Then when they endu-up with the spaghettis they learn the structure, K-maps, States and the whole chibang!

Tom Jenkins said:

The only way to get past the intimidation of a blank page is to put something on it!

Click to expand...

Amen!

Whatever tools you use to prepare are fine; I/O lists, functional descriptions, etc. But, in the end you have to write code! Diagramming the problem/solution will help you organize your code so that it's readable. AND THAT IS IMPORTANT! But, don't lose all your programming time because you were too busy trying to make your pseudo-code 100% correct. IT'S A TOOL!

AK

Soooo... Let's just put a match to this rocket. We'll consider where we are going when we get there.

There's an old saying... "Sometimes, to get a project onto the floor, you have to shoot the Bloody Engineer."

Then there's... "Haste makes waste."

And then there's... "How come we couldn't afford to design and build it right the first time but we can afford to redesign and rebuild a second time, a third time,...?"

It is the ability to THINK that separates REAL process-developers from hammer-swinging-programmers! Which do you want to be? Do you want to "HACK" your way to a solution? Or do you want to "ENGINEER" a solution?

In this field, you don't need a paper that says you are an Engineer. All you need to do, to be really successful, is "Practice Engineering!"

During the early stages of learning about any brand-new field it is far better to teach someone the "Thinking-Skills" based on the under-pinnings of that field before handing someone a shotgun and saying "Here, have at it!"

For myself, Genetics is the second most interesting field to be in. However, I simply can not imagine attempting to move into that field and then begin using the "Shotgun Approach" simply because the mentality is "Doing something completely stupid is better than taking the time to at least learn the basic tenets."

Under those conditions I can't wait to work on YOUR next Test-Tube baby! ("YOUR" is the collective "you" that believe in this philosophy.)

Say, if we gave your new daughter two heads, one could be sleeping while the other is working! HEY! How 'bout that? A 24/7 working machine! What do you think? (She will probably end-up with three stomachs instead... "Feed Me, Seymour!")

Teach what is right. Experience, in its' time, will show "reasonable" short-cuts.

Until the basic concepts, tools and methodologies are understood, do it the hard way. The "School of Hard Knocks" is not a school where one stupidly blunders one's way to a workable solution. The "School of Hard Knocks" is where one starts at the bottom and LEARNS the trade while being "KNOCKED" in the head, for screwing-up, by the Master-Tradesman.

The "School of Hard Knocks" is NOT where someone comes in, from the cold, all alone, and then learns the short-cuts without learning the basics. The "Knocks" come from the Masters.

Those that stupidly blunder their way to a workable solutions without the benefit of the "Knocks" are "HACKERS!"... the bane of REAL Process-Developers.

Even those that supposedly Graduated from the "I did it on my own" kind of School of Hard-Knocks spent at least some of their time saying to themselves... "Damned, I really wish I really knew the basics of this field!" (Many of them are saying... "Thank God for PLCnet!" YOU KNOW WHO YOU ARE!)

At the end of the REAL "School of Hard Knocks", the hard way ends up being the easy way... and the Best Way!!

Otherwise, I hope that all of the "short-cut hackers" end-up being traffic-pattern programmers in your neighborhood - not mine!

END-RANT:
(308)

I wonder if Elaine's traffic light has a left turn signal in it--this thread seems to have taken one.

Terry, man, you have GOT to write that book.

Soooo... Let's just put a match to this rocket. We'll consider where we are going when we get there.

Click to expand...

WASHINGTON (AFP) Apr 27, 2004
The Pentagon could put a ground-based missile defense system on alert as early as September when the first interceptor missiles will be deployed in Alaska even if it fails two flight tests this summer, the general who heads the program said Tuesday.

Click to expand...

link

All that criticism is BS

There must be a start point...noone is perfect therefore can not always start perfect.

All that **** about structure, hammer swinging, spaghetti etc etc etc is BS.

Elaine, if you do a search on this site you will find examples of code for the traffic light problem.

If you follow Tom's idea and PUT ANYTHING down on paper or in your program you will eventually find a solution albeit any code can be improved.

I can attest that it does NOT take a rocket scientist to program a plc..forget the spaghetti code comments...they are not relevant.

There are ideas/concepts stated by others that will put you on the correct path. Follow your diagram, set a beginning point...ie light is red..car passes sensor...what do you do next?

I totally agree with Tom...there has to be a start point and it doesnt matter if right or wrong...just START.

Post your diagram and any code you have created then you will receive much more assistance.

I admire all of you pros but you have forgotten what it was like. You did not KNOW structure...etc...etc...etc al when starting. You did not know when to use a timer, a counter or what instruction. You did not KNOW...you learned

And Furthermore...

Terry, those numbers in parenthesis are really starting to bother me!... mddr

Must be the 'puzzle solver' in me?...

So far, we have 466, 107, 449, 154, 121, and now 308 (in that order, by the way). Did I miss any?...

Here's some facts I found about a few of these numbers:

107 and 449 are prime
107 is also the exponent of a Mersenne prime
121 is the only square known of the form 1+p+p²+p³+p⁴, where p is prime
308 is a heptagonal pyramidal number

I know it's probably something stupid like how many teaspoons of MGD were consumed while typing each post, yet I just HAVE TO KNOW!...

beerchug

-Eric

Oh, and one more thing... Hey Terry, do you know that your cat has been posting messages over at the AD forum?

Terry Woods said:

Soooo... Let's just put a match to this rocket. We'll consider where we are going when we get there.

Click to expand...

Sure!

Just make sure your bags are packed and the rocket is pointing UP.


Honestly, I've worked for Tom. He's very methodical, and there's nothing sloppy about his work. But, I've never seen him do pseudo-code, or K-maps, or whatever unless there was some compelling reason. Usually an I/O list and functional description were enough. Once, we had to put a little more effort than usual into memory mapping. On that project, we needed to be a bit more rigid about grouping data.

After I left his company, I worked places where the POs for parts were placed BEFORE any design work had been done. Now THAT is just throwing away money... Even then, though we were able to maintain some organization in the program. But, everything took MUCH longer and had to be cleaned up afterward. I much prefer Tom's approach.

AK