Hello all this is Section 7 of PLCC programming from scratch.
And now we're going to start getting into our actual process logic which is really the heart and soul
of a C program.
Before we get started throwing logical blocks all over ladders we need to stop.
And this is the part we really think about what we're about to program and visualize the process.
What does this machine look like.
How does it work.
How is it laid out.
Where did the process engineer have in mind when he created the piano idea that we're looking at.
And if you don't know what a piano ideas it's piping an instrument diagram which is a typical engineering
output for any type of pipe system.
So before we start programming how do we imagine the process.
How do we understand the process and visualizing the process with something like a visual flow diagram
a cause and effect chart or even a Vizio diagram is a really helpful tool in knowing what your program
is going to need to look like how to divide it up between various ladders.
And really the more you can envision the process from the beginning the easier your program will be
to right.
There's a saying that writing clarifies thought and it's true when we look at the document on the screen
.
It's nothing elaborate.
It's nothing too highly structured.
It's a simple Excel spreadsheet but it tells us in time exactly what needs to happen and when when we're
starting up a system and it's hugely important to have something like this in front of you when you're
writing a C program.
A lot of us can do it off the top of our head and we get a little cocky about doing that.
And more times than not we spend far more time than we should shaking down and debugging a program before
we can load it onto a machine and hand it off to somebody.
And another thing we need to consider when we're putting process logic into a program is what are the
contingencies what can go wrong if we're in the middle of a start up and all of a sudden an alarm condition
arises do we interrupt the start up do we sound the alarm and keep going.
What needs to happen what can happen all the way through our process.
Murphy's Law says anything that can happen will happen.
And in the world of process and automation that's very true.
If it's possible for somebody to throw a shoe into your water tank it will happen.
And when that shoe blocks your discharge valve What is your PEOC going to do about it.
You have to think about not only how is the machine designed.
How is the machine supposed to run but what things can happen along the way and how are we going to
handle those exceptions for the type of programs we're riding in this course.
Very simple.
One or two elements systems of visual flow diagram probably is necessary but in a real world scenario
when you're called to use APL c you're more than likely going to be controlling 10 to 20 or more different
devices.
And on top of that receiving inputs from just as many there aren't many people who can keep that many
different variables straight in their head.
So if you can get as many diagrams as many flowcharts as many theories of operation written out and
on your desk in the beginning it's going to make your job programming a lot faster a lot easier and
certainly a lot cleaner.