Comments please - my first ever ladder logic program

I see five functions that this program will perform

  1. Start/Stop function: Rungs 0000:0001
    1. Inputs
      1. [START I:1/9] momentary(?) button(?); normally 0; active when 1 => Start command
      2. [STOP I:1/5] momentary(?) button(?); normally 1; active when 0 => Stop command
      3. [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
    2. Output
      1. [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
    3. Logic
      1. STARTED becomes active = 1 via Latch (OTL) when START is active = 1 and FAULT_PRESENT is inactive = 0
      2. STARTED becomes inactive = 0 via Unlatch when STOP is active = 0.
    4. Comment:
      1. This functions current logic could be replaced, and become more clear, with the Start/Stop pattern
        1. The only difference would be the behavior across PLC mode changes
  2. Fault present function; Rung 0002 and Rung 0006
    1. Inputs
      1. [START I:1/9] momentary(?) button(?); normally 0; active when 1 => Start command
      2. [STOP I:1/5] momentary(?) button(?); normally 1; active when 0 => Stop command
      3. [FAULT_RESET I:1/3] normally 1; active when 0 => clear fault
    2. Outputs
      1. [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 => A fault is present and has not been cleared
    3. Logic
      1. FAULT_PRESENT becomes active = 1 via Latch (OTL) on Rung 0006 when START is active = 1 and STOP is active = 0 on the same scan
      2. FAULT_PRESENT becomes inactive = 0 via Unlatch (OTU) on Rung 0002 when FAULT_RESET becomes active = 0
        1. N.B. this could be overridden later in the same scan on Rung 0006
    4. Comment
      1. This function's current logic could be replaced, and become more clear, with the State/Fault pattern
        1. Cf here: http://www.contactandcoil.com/patterns-of-ladder-logic-programming/state-coil/
  3. Control a white light(?); Rung 0003
    1. Inputs
      1. [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
    2. Outputs
      1. [WHITE O:2/0] normally 0; active when 1
    3. Logic
      1. WHITE output becomes 1 when STARTED is 1
      2. Presumably this turns on a white lite to indicate some part of the process is in a started state
    4. Comment
      1. Discrete output [WHITE O:2/0] could have its value assigned via an OTE in a branch in parallel with the OTE [STARTED B3:0/0] of the Start/Stop pattern proposed above, eliminating this Rung
  4. Control a yellow light(?), Rungs 0004:0005
    1. Inputs
      1. [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
      2. [FUNCTION O:1/15] normally 0; active when 1; the name of this discrete input is generic so nothing is know about it, or why it would be in any state
      3. [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
      4. [RIDE_ACTIVE T4:0] TOF timer; specifically T4:0/DN; normally 0; active = 1
    2. Outputs
      1. [YELLOW O:2/12] normally 0; active when 1
    3. Logic
      1. Output YELLOW follows T4:0/DN; when it becomes 1, it presumably turns on a yellow light
      2. T4:0/DN is 1 when the STARTED and FUNCTION both are active = 1 while the FAULT_PRESENT is inactive = 0.
      3. T4:0/DN also extends by 5s the duration that it is active = 1 after any of the STARTED, FUNCTION or FAULT_PRESENT bits change state.
    4. Comment
      1. None
  5. Flasher when faulted; Rungs 0007:0008
    1. Inputs
      1. [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
      2. [FAULT_TMR_STATUS T4:1] specifically T4:1/DN
      3. [T4:2] specifically T4:2/DN
    2. Outputs
      1. [FAULT_LED O:2/6] presumably an LED
    3. Logic
      1. When FAULT_PRESENT is active = 1, FAULT_LED alternates between 0 and 1 at 1Hz on a 50% duty cycle.
    4. Comment
      1. There are simpler, cleaner ways to do this, as mentioned earlier by both @GaryS and myself.
I know it is silly that I did this, but my point is that something like this, sans comments, should have been provided by the OP, along with a description of the process. Because, while the comments provided so far to the OP may or may not be helpful, without process knowledge any comments made will be ignorant of process-specific aspects of this program e.g. safety.


General comments

  • Each function deduced above can be handled by a single rung, often by using well-known patterns that are instantly understood by others
    • latches/unlatches, when used, of any single bit should be paired next to each other and not separated; e.g. the latching and unlatching of FAULT_PRESENT. four rungs apart, is a prelude to future mistakes.
  • A comment on each rung, describing the interface with the process and the model the PLC is using for that process would be extremely useful, e.g. especially three months from now when OP, or someone else, is trying to diagnose a problem.

great comments, thankyou
 
Thankyou to everyone for your feedbacks

i am a cisco network engineer by trade, this was a quick 5 minute throw it together project

the goal is to make a "funfair ride simulator"

outputs: -

RED LED \ Fault LED = Fault Present
WHITE LED = Ride Running
Yellow LED = Function (unknown purpose) on - runs for 5 seconds (special effect etc).


Will upload pic of control panel.
 
TBH, this is so simple, try something a little harder and push yourself like simple two way traffic lights, this will test your skills a little further, for example it will be a small sequence, no need for a start or stop just ensure it automatically starts on boot up.
Write down the I/O required (in first instance no need for inputs just outputs).
Write down the sequence of events
for example: initial power up Step 0 Traffic lights 1 (TL1) RED, Traffic lights 2 (TL2) RED.
Timer
Step 1 TL1 RED & AMBER, TL2 RED
Timer
Step 2 TL1 GREEN, TL2 RED
Timer
STEP 3 TL1 AMBER, TL2 RED
Timer
STEP 4 TL1 RED, TL2 RED
Timer
Step 5 TL1 RED TL2 AMBER
Timer
STEP 6 TL1 RED TL2 GREEN
Timer
STEP 7 TL1 RED TL2 AMBER
Timer
STEP 8 Go back to step 0

Then add two pedestrian crossings i.e. push buttons. so when in step 0 or step 4 pedestrian lights green for a time delaying the normal traffic light sequence.
Things to remember there are a couple of ways to do step sequences, use internal bits for the steps (remember to disable previous step), you will notice that using consecutive bits if you want to add extra steps then it becomes messy, leave spare bits between each step so you can add extra steps, alternatively use an integer variable as the sequence so on each step you move a value into it & do compares i.e. sequence word = 0 then this is step 0, sequence word = 10 this is step 1, allow the spare values i.e. 1 to 9 if you need extra steps later, this reduces the need to shift the number down the line should you need to add extra steps, use some of the internal bits that have their own special functions like a bit that is on for first scan only on power up (or stop to run), this can be used to move a 0 into the sequence word or reset all the step bits.
example of using a sequence word:
IF N7:0 = 0 then turn on TL1 RED TL2 RED Run Timer 1
If Timer 1.DN MOVE 10 N7:0
IF N7:0 = 10 turn on TL1 RED & AMBER Run Timer 2
Etc.
I suggest you work out on what sequence value turns on what outputs put those compares on each output rung.
See attached simple traffic light, this is not SLC500 but then again it is only a guide so you will have to write it in ladder.
you could come up with loads of different sequences like a pick & place robot that has an up/down cylinder forward/back & a gripper, so if a part is placed in the pick nest a sensor (input) detects it is there, sends the P&P down, grips the part, sends it up, sends it forward, sends it down, un-grips & reverses ready for the next part. each cylinder has two sensors for forward/back or up/down & either a single solenoid to drive them forward (down) automatically return on de-energise the solenoid or even two one for each stroke i.e. 1 forward 2 back.
 

Similar Topics

Hey guys, I recently visited an existing water plant that's running a Scadapack32 with ClearScada for the HMI. I've been looking through the...
Replies
0
Views
1,470
Hi.. 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...
Replies
0
Views
3,565
Hello again, Still working on my tank mixing project between breakdowns and maintenance! It would be really helpfull if any of you fancy...
Replies
7
Views
2,706
I'm pretty new at this. I've attached a PDF file. Open the file and take a look at my little program. I wanted to turn "OUPUT O:2/10" ON for a...
Replies
3
Views
1,858
It better to have too many instead of not enough right?
Replies
26
Views
2,895
Back
Top Bottom