Program development questions/techniques

[kylbak]

Good afternoon!


My first post here so bear with me. A recent career change has made me become very interested in PLC/Automation Engineering. My former career (shipboard marine engineer) gave me a very strong mechanical and electrical troubleshooting background. My exposure to PLCs and automation aboard ships was extensive but almost entirely in troubleshooting/maintenance/repair. My new career has the potential to expose me to the design/development side of PLCs and automation and, as such, I'm trying to learn all I can!


On a recent job, I was asked to troubleshoot and repair a large hydraulically operated door. The door controls are relay based and the operational issues were traced to a failed mechanical relay, an incorrectly set limit switch, and another failed limit switch.


Anyway, after completing the job I decided I'd design a PLC based control system as a learning exercise. I've attached pictures of the original system schematic and the program I designed to replace it. The program tests fine in simulation and I'm confident it would work in practice so I'm happy with that. The problem is, getting to that point took a long time and lots of trial-and-error.


I intentionally made it more challenging by only using the original schematic for an input/output reference list. Though, the program would never work properly anyway had I straight "copied" the relay logic into the PLC ladder logic due to the scan sequence, multiple rungs leading to common outputs, etc.


I've spent a lot of time in the past several weeks reading all I can about design techniques/methodologies. I've touched on state machine, k-diagrams, SFC and Grafcet, truth tables, etc, etc. I've bought probably a dozen books in the past month! The problem is I am still missing "something". I can't quite link the theoretical to the practical.


Example, after fudging my way though the program design I figured there had to be a better way. With what I had learned so far about SFC and Grafcet, I thought, this seemed like a good technique for the door application. Sitting down with that, I immediately run into the issue of clearly defining the "states" the door can be in. With 11 inputs and 13 outputs there's a lot of them. Plus, several inputs have a "transition" period where neither is true for a period of time in operation (door locks, and door "open"/"closed" positions for example) that seem to be throwing me for a loop. Also, the door is manual operation only which doesn't necessarily seem to "fit" with SFC, but my lack of knowledge could be fooling me!


Next, I learned a bit about truth tables, using them, and boolean algebra to develop ladder logic. Again, with 11/13 I/Os, even excluding the (nearly) impossible and "easy" (indicator lamp outputs) combinations you still end up with 100+ truth tables.


I'm stuck. What kind of techniques would you guys use for something like this? I'm sure practice would make my trial-and-error process faster but what about a control project far more complicated than this one? There's got to be a more methodical approach to this. I know these are some pretty broad questions and my knowledge is limited but any advice, insight, or suggestions are welcome.


Thanks!
Kyle

 

[_Dock_]

Engineering in any aspect is about taking small bites out of large complex problems or applications and Beating them down individually. If you try and let your brain process the whole problem as one, failure is likely.

Automation is a trade and there is no replacement for experience. An application given to someone that is fairly new may take 40 hours, give the same application so someone well seasoned and it may take 4 hours. It really is that drastic when you have experience on your side. It’s not that either person is intellectually more capable then the other, it’s the fact that the more experienced person succeed at a faster rate because of semantic memory.

To answer your question directly I think everyone approaches things with how it works for them. For me I work off an io list and a description of operation, again remember, small bites. I think you’re looking at this process as one solid operation and really it’s not. Think, open operation, close operation, indicators, faults and interlocking individually.

One thing that is fact, those with troubleshooting and service experience for sure end up better at the next level. That is on your side.

 

[sigmadelta]

If this is a sequence, write out each step in normal English. Then maybe using Excel, write out each step with a step number, and write which output(s) are on during that step, and what should happen (event or timer) to transition to the next step.

 

[parky]

I agree with sigma, just think of the steps & what logic causes it to do the sequence and the logic to step onto the next stage, forget about all these fancy state machines etc. learn the basic logic first and how to roll your own sequence.
There are many ways to sequence some are strait forward i.e. it goes from step 1 to x others may jump around a bit.
look at it logically.
What initiates the sequence, the interlocks required to allow the operation.
what is the logic that moves it on to another sequence are they really sequences or just a bit of logic for different operations.
For example: the operation is to press a button once, the drive runs until certain inputs are in a state to stop the drive.
Operator presses a button (input)
and the equipment is at a position to start
latch the circuit until the inputs tell you it has reached it's position,, does it need another step?, yes initiate the next step and reset the previous, no reset the step.
So a flowchart is the most obvious, but does not have to be.

 

[kylbak]

Thanks so far for the suggestions. Dock, small bites, got it! A guy I worked with years ago used to say something similar. "How do you eat an elephant?" (a seemingly insurmountable task), "One bite at a time." Sigma, parky, the door operation is a sequence I'd say. It's got enough alternate branches that it becomes a bit convoluted though. I'll sit down and work on drawing up a flowchart again and see if I can come up with something better than my first few attempts!


Kyle

 

[drbitboy]

I can't quite link the theoretical to the practical.

Hey Kyle,


1) First I am going to focus on this quote, and provide a simple prescription that I suspect, based on your background, is already in your current knowledge base, but may not yet be part of your programming toolbox:

The ONLY thing that matters is what you TELL the PLC to do; it matters NOT A FIG what you WANT the PLC to do.
​

I have 40y experience programming, though little of that is in PLCs. My brother has similar experience but all in PLCs; his formulation of this concept is "You have to get stupid, as stupid as the PLC."


There was an interesting study about the ability (tnedency) to challenge held assumptions as a predictor of success in a programming course. I can't find it, and the folks that put it together did a further study that did not confirm the first.


2) Someone else mentioned "taking small bites" and breaking things into manageable pieces, which is a great way to work. On many of my larger projects I have found that I didn't realize when I was finished, because I was always working on one small piece or another and rarely saw the forest for the trees: I would finish one piece and find out it was the last piece - "Oh, I'm done?" Not that I never thought about the forest, but that part is usually resolved early on and refactored infrequently, and the bulk of the time is spent on the little stuff. The PLC program may implement a state machine, but you cannot keep all of its details in your head at once.



3) Learn and ingest the common design patterns - cf. here - you will use them over and over again.


4) Comments, comments, comments - they can be overdone, but not often.