parisandon

Traffic Intersection with 3 second inductive sensor

7 posts in this topic

I am new to PLC training. I am trying to do a traffic light intersection with 23 seconds for North and South to cycle through green, yellow and red; 23 seconds for East and West to cycle through. However there is an inductive sensor that if it counts 3 cars will add an additional 3 seconds to its' respective directions cycle.

What is the best practice for handling the 3 second alternate time? Subroutines?

Share this post


Link to post
Share on other sites

PLC logic has a little different mindset than other programming languages.  So no to the subroutine for this.  I actually find that subroutines in a PLC are more used for program organization than anything else.  Take that in mind and try to come up with an alternative solution BEFORE READING MINE as the struggle to figure out the solution is one of the most important things to go through in learning to program anything. 

That said...  I assume from your text that this is an either or thing not 3 seconds for each 3 cars the sensor sees.  The solution is actually pretty simple.  You have a register that stores the normal time and one that stores the extended time.  You then modify the timer preset with the stored values.  It looks like this is total cycle time through all 3 lights.  I would expect you would extend the green for the side with extra cars but not the red or yellow and obviously.  if you extend the green on one side you are extending the red on the other side.  If you use 3 timers the method I would use would be to copy the extended time into the green timer preset one direction and red timer preset in the other.  An either or.  Either you are copying the default time into those timers or the extended time into the preset for those timers.  Of course you could do it all with one timer and just use comparison instructions to turn your lights on at certain accumulator values.  You would still need to extend the preset time for your timer in that case also. 

Edited by PLCMentor.com

Share this post


Link to post
Share on other sites

I have also been learning to program as well. My approach is a bit unusual as I built a model train layout and using the PLC to control the trains. I have had some success but have hit a roadblock with a routine I am trying to write. In the meantime I also picked up an inexpensive C-More HMI panel to start learning how to program and interface a HMI panel.

I did recently went back to some basics and did my own version of the traffic light problem. There are several solutions to the problem, perhaps mine isn't the best one but it does work. I wanted a graphical display of the traffic light and have the HMI panel be able to interface with it. I can not only use the real inputs to go to automatic or manual control, but the HMI has soft buttons to do the same. The HMI can also change the cycle time of the traffic light system from 10 to 60 seconds total. This variable timer option may help in your solution to the problem.

One other "back to basics" I did was write a routine that where a process needs a compressed gas. two tanks are attached where the system uses one tank until it is empty, then switches  to the other tank of gas and alerts the user the first tank has run out. Once the user replaces the empty tank with a full one, a button is pressed and a valve opens for one second to purge out the atmosphere so only the pure gas is in the system. We actually had a similar system at a former place I worked, so I thought it would be a good idea to replicate the system. I wrote the program two years ago, and recently re-wrote it from scratch. I not only wanted to add the HMI controls but I wanted to see how my skills changed as I learned more.

Mike

 

Traffic Light.pdf

Share this post


Link to post
Share on other sites

Mike's logic is a good example of the comparison method I mentioned.  It is also offers a chance to talk about what I meant by using subroutines to organize logic.  I encourage my students to get in the habit of using subroutines for organization even for small programs like this to practice and to get in the habit for larger programs.  I would suggest that very little logic should be located in program file 2 of a SLC, micrologix or PLC5 even.  Only JSR's to program modules if possible.  In this program, you could put all the setup information in a program file and the actual control logic in a different program file.  Not a big deal in this size of a program, but I think you can see the benefit in a system where you have lots of sub systems.  Once again - PLC programming is different than other languages.  Users will be in a PLC trying to troubleshoot at 3AM with only half their brain actually awake.  The easier it is to get to the information they need the faster they system problem is fixed. 

Share this post


Link to post
Share on other sites
20 hours ago, PLCMentor.com said:

Mike's logic is a good example of the comparison method I mentioned.  It is also offers a chance to talk about what I meant by using subroutines to organize logic.  I encourage my students to get in the habit of using subroutines for organization even for small programs like this to practice and to get in the habit for larger programs.  I would suggest that very little logic should be located in program file 2 of a SLC, micrologix or PLC5 even.  Only JSR's to program modules if possible.  In this program, you could put all the setup information in a program file and the actual control logic in a different program file.  Not a big deal in this size of a program, but I think you can see the benefit in a system where you have lots of sub systems.  Once again - PLC programming is different than other languages.  Users will be in a PLC trying to troubleshoot at 3AM with only half their brain actually awake.  The easier it is to get to the information they need the faster they system problem is fixed. 

 

Using subroutines is how I am doing my model train layout. The plan is the main program will do not much and look for input from the HMI or buttons and then call the needed routine to do what it is told. (such as interchange the main line train with the one on the side track) There are also routines that will be needed in several routines, one example would be to throw the switches to either the throughway or turnout depending on the data bits. Attached is a few of the subroutines (I did not include the forward-reverse one because it is large)

These programs are sequence based, What I did was use a binary word (say B3:10) and as each step is completed I latch on the bit (B3:10/0) to indicate it is complete and to do the next step. For these subroutines, since I cannot have a loop, when it calls the subroutine, it will repeatedly call it until the subroutine sets its complete bit, then the program that called it will continue on to the next step) I can provide an example of a complete program if you would like to look it over. I would like feedback on my programming skills or is the way I am doing this not a good way to program. I uploaded it as "Main and Side interchange" I took a video of the program running here:

 

 

 

Mike

 

BLANK PLC PROJECT.pdf

MAIN AND SIDE INTERCHANGE SIMPL.pdf

Share this post


Link to post
Share on other sites

Kinda on the verge of hijacking the thread, but I guess it is pertinent poop for someone learning programming. 

Took a quick look through your program and do have a couple immediate things that pop out:

  1.  I never use conditional JSR rungs or at least I cant remember a time that I found one helpful.  They are generally a way to get into trouble as all outputs stay in their last condition when you stop scanning the subroutine.  The mantra in PLC programming is "keep it simple."   This is a program just for you, but generally we are programming for the multitude of people that will follow us into the program after we are done.  That is very unique in PLC programming.  Generally in a plant environment the level of proficiency is fairly basic.  Also at 3am in the morning when a line is down, brain functionality is fairly basic.  Imagine the fun of seeing an output on in the program with all of the logic before that output false just because the program file is not being scanned at that time.  Minds have been blown with less.  In my experience, nothing good ever comes from a conditional subroutine.  If you want an output off then put a contact in the rung to make sure it is off.  Then the logic is clear and understandable to just about anyone.  I suspect that is why you have to reset your outputs with the masked move statement.  Another gotcha waiting to happen.
  2. I never use (or extremely rarely) the JMP instruction.  That is a fairly common statement for all high level languages.  Basic has its goto and just about every language has a statement to jump to a location in the program.  Most instructors I have learned from will explain the statement and its purpose and then tell you not to use it.  Those types of statements get you into trouble and are difficult to follow in most programming circumstances.  There is generally another way to do the same thing.  Same goes for MCP.  That has some value possibly in temporarily taking sections of code out of service for testing or maintenance.  As permanent fixtures they just cause confusion when people are troubleshooting.
  3. Rather than latches use seal in circuits.  Latches generally cause problems.  They are necessary if you need to maintain output status through a power failure.  OTE's are reset when the system comes up.  Same with the resets on your timers.  TON's reset automatically when the logic before them goes off.  Resets can be eliminated and everything that controls that timer's function then is on the rung with the timer.  Thats much easier to understand when looking at the rung functionality.  Side note: RTO's do have to be reset and are useful if the timer value has to be maintained such as for a total run time of a system that is starting and stopping.
  4. Even with the subroutines you have, I would move everything from file 2 except for JSR's to a subroutine.  Leave file 2 just for JSR or insignificant overhead logic such as blink timers or such.  That will make the logic much easier to go through.
  5. Looks like a fun project! 

Share this post


Link to post
Share on other sites

I do not wish to hijack this thread either, but I want to thank you for your feedback.

If I were to start a new thread with this information, I would like some input in how I can do this project properly.

Mike

 

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