PLC_SLC500
Member
OP
I see five functions that this program will perform
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.
- Start/Stop function: Rungs 0000:0001
- Inputs
- [START I:1/9] momentary(?) button(?); normally 0; active when 1 => Start command
- [STOP I:1/5] momentary(?) button(?); normally 1; active when 0 => Stop command
- [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
- Output
- [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
- Logic
- STARTED becomes active = 1 via Latch (OTL) when START is active = 1 and FAULT_PRESENT is inactive = 0
- STARTED becomes inactive = 0 via Unlatch when STOP is active = 0.
- Comment:
- This functions current logic could be replaced, and become more clear, with the Start/Stop pattern
- The only difference would be the behavior across PLC mode changes
- Fault present function; Rung 0002 and Rung 0006
- Inputs
- [START I:1/9] momentary(?) button(?); normally 0; active when 1 => Start command
- [STOP I:1/5] momentary(?) button(?); normally 1; active when 0 => Stop command
- [FAULT_RESET I:1/3] normally 1; active when 0 => clear fault
- Outputs
- [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 => A fault is present and has not been cleared
- Logic
- 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
- FAULT_PRESENT becomes inactive = 0 via Unlatch (OTU) on Rung 0002 when FAULT_RESET becomes active = 0
- N.B. this could be overridden later in the same scan on Rung 0006
- Comment
- This function's current logic could be replaced, and become more clear, with the State/Fault pattern
- Control a white light(?); Rung 0003
- Inputs
- [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
- Outputs
- [WHITE O:2/0] normally 0; active when 1
- Logic
- WHITE output becomes 1 when STARTED is 1
- Presumably this turns on a white lite to indicate some part of the process is in a started state
- Comment
- 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
- Control a yellow light(?), Rungs 0004:0005
- Inputs
- [STARTED B3:0/0] internal boolean; normally 0; active when 1 => Some part of the process has started
- [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
- [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
- [RIDE_ACTIVE T4:0] TOF timer; specifically T4:0/DN; normally 0; active = 1
- Outputs
- [YELLOW O:2/12] normally 0; active when 1
- Logic
- Output YELLOW follows T4:0/DN; when it becomes 1, it presumably turns on a yellow light
- T4:0/DN is 1 when the STARTED and FUNCTION both are active = 1 while the FAULT_PRESENT is inactive = 0.
- 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.
- Comment
- None
- Flasher when faulted; Rungs 0007:0008
- Inputs
- [FAULT_PRESENT B3:0/1] internal boolean; normally 0; active when 1 -> A fault is present and has not been cleared
- [FAULT_TMR_STATUS T4:1] specifically T4:1/DN
- [T4:2] specifically T4:2/DN
- Outputs
- [FAULT_LED O:2/6] presumably an LED
- Logic
- When FAULT_PRESENT is active = 1, FAULT_LED alternates between 0 and 1 at 1Hz on a 50% duty cycle.
- Comment
- There are simpler, cleaner ways to do this, as mentioned earlier by both @GaryS and myself.
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