Why, oh why, Do Beginners Think PLC Inputs Are More Important Than PLC Outputs?

[Lancie1]

Yes, true. But also you could not give your reply until you thought of an output (response), what it would be, what it would say, and then figured out what inputs (arguements) would then support that reply (output).

I did not intend this to be a "which comes first" type of discussion. Rather that a PLC output is similar to a goal, a purpose, the action that completes the task. To solve that task or that goal, first a clear idea of the goal is needed, what it does and how it works. Then the rest of the logic follows easily.

 

[Lancie1]

When I was taking my controls/PLC classes at college, a large majority of the control problems used a phrasing of "You have this many inputs. Make the output do this." That phrasing tended to get the class to focus on the inputs and approach the problem from that direction.

Sorry, my mistake. That quote was from Pireciter, not Stig. Those two members have completely different viewpoints, and I don't want to accidently insult one.

 

[bce123]

I did not intend this to be a "which comes first" type of discussion. Rather that a PLC output is similar to a goal, a purpose, the action that completes the task. To solve that task or that goal, first a clear idea of the goal is needed, what it does and how it works. Then the rest of the logic follows easily.

I agree. I just couldn't resist the chicken/egg comparison. With me it starts with the task then what outputs are needed to complete the task then the associated preconditions (inputs) needed to make it safe then a way to turn it on and off ect.....

 

[Brijm]

I agree. I just couldn't resist the chicken/egg comparison. With me it starts with the task then what outputs are needed to complete the task then the associated preconditions (inputs) needed to make it safe then a way to turn it on and off ect.....

Now, this makes since to me... Perhaps the confusion is I was thinking of programming, and Lancie was thinking of project planning.

 

[Lancie1]

With me, it starts with the task, then what outputs are needed to complete the task...

I think that, one way or another, all programs have to be done that way. It may be that at many PLC integrators, some of the initial programming steps are done by the designers who pick the PLC brand and model, then the final programmer already has a list of outputs so does not have anything to do with that initial step.

 

[jaywillnot]

Now, that is funny.....sad but funny!

 

[sixstringz]

here is my $0.005 (1/4 price since I am a noob and my INPUT ain't worth the going rate): I am an old relay control electrician; when I wired a panel I worked from the coils back to the controls (how I was taught). When I began playing with programmable logic I found I got caught up in the left to right conventional flow of things, I felt the need to start the rung with an input, and add the output last. I have since found that I am more efficient when I program from the out's back to the in's !! (but i still have much to learn). The importance issue of the I/O thing I don't understand because without either you have nothing (in most cases).

 

[jparale]

I agree with sixstringz, It all boils down with what you want to achieve in programming PLC ( output) and base on it you will start filling the blank what you need in order get the output you want. Then here comes the input ( requirements ).

All of it were all important it is like a story, there is the beginning, the body of the story and the end.

Either one of these components is missing you will not complete the story, similar with PLC programing...

Once upon a time --- input
king ---input
beautiful princess--- input
handsome prince --input
wicked witch ---input

then the whole story itself that creates story on each character - the program itself


and they live happily ever after... THE END. ---Output

 

[jaywillnot]

The Input really does nothing at all but give the output the "green light" (no pun intended) to do its work.

In a closed loop system, the only true role the Input has is to verify to the PLC that the output is indeed on because all the PLC knows is that it got the signal from somewhere to turn an output on...it wouldn't know otherwise unless it received the signal from a prox, photo eye, or some kind of limit switch attached to the output.

Speaking from the light switch scenario...the first word in this topic is LIGHT (an output). Of course, this wouldn't necessarily be a closed loop system, so I would have to look at this one as a Potential Energy vs Heat/Light Energy situation. ?
I am a "young-blood" in the world of programming, but I have been doing a lot of research, as well as, tinkering with different forms of programming and no matter how different all the programs may be, they all have the same outcome....what the PLC was told to do. If I don't know what I want the outputs to do then I shouldn't even worry about the inputs yet because they will only tell the PLC "yes" or "no"

I hope I didn't step on anyone's toes here. I just wanted to be the first new jack to try and answer Lancie's question correctly

 

[jdbrandt]

I have never got any good answers. Is someone out there teaching this concept? Why do they think that? Where did the idea start? What keeps it going? Is it because that is the first thing they see, or read, or are told about?

I can't figure it out. Please help me.

Well, _I_ don't teach this way. Inputs and Outputs are just a few of the components of the SYSTEM. I am a "systems guy", and I don't focus on just one component of any system.
Perhaps that's the answer.
If you're a systems guy, you think in connected blocks, each with its own function, which may (or may not) have anything in common with functions of other blocks.
I don't really know who would teach PLC operation and say that one thing is more important than the other.
Heck, I have seen PLC systems with all outputs (no inputs) and all inputs (no outputs), so that argument can't be used, either.

 

[Lancie1]

If I don't know what I want the outputs to do then I shouldn't even worry about the inputs yet because they will only tell the PLC "yes" or "no"

Right on target.

I don't really know who would teach PLC operation and say that one thing is more important than the other.

Study the attempts that students first make on this site. Often you will see a focus on the Inputs, with a complete disregard for the given Outputs that are right there in a list for their use. Often they don't use critical outputs at all. Where could this come from except their instuctors?

Outputs are the PLCs actionable devices, the equivalent of a sentence "verb", the part that do all the work. Without outputs, nothing gets done.

Heck, I have seen PLC systems with all outputs (no inputs) and all inputs (no outputs), so that argument can't be used, either.

I can't imagine how a PLC without outputs of some type would be worth anything at all.

 

[jdbrandt]

Right on target.
I can't imagine how a PLC without outputs of some type would be worth anything at all.

I was wondering if anybody was reading.

I taught a class once, and, when covering the elements of the system, I mentioned that there are INPUT modules, and OUTPUT modules; digital and analog. I also said (then..not now) that all systems have some combination of INPUT and OUTPUT modules.
Safe, right?
Not this class.
S: "Jeff, we have a system at work that only has input modules."
Me: "That's hard to believe. It's like a lawn mower that won't cut your foot off....it doesn't cut grass either. What do you use it for?"
S: "Troubleshooting."

[It turns out that it was connected to a relay-controlled machine, and all that it did was to use internal memory bits to track the status of various inputs from relay contacts and monitoring of relay coil energization status. It was on a machine that the OEM refused to use programmable controllers on....an amusement park ride; in this case, a roller coaster.]

So, as I teach, just because _you_ haven't seen one, doesn't mean that they're not out there, somewhere.

 

[The Plc Kid]

I was wondering if anybody was reading.

I taught a class once, and, when covering the elements of the system, I mentioned that there are INPUT modules, and OUTPUT modules; digital and analog. I also said (then..not now) that all systems have some combination of INPUT and OUTPUT modules.
Safe, right?
Not this class.
S: "Jeff, we have a system at work that only has input modules."
Me: "That's hard to believe. It's like a lawn mower that won't cut your foot off....it doesn't cut grass either. What do you use it for?"
S: "Troubleshooting."

[It turns out that it was connected to a relay-controlled machine, and all that it did was to use internal memory bits to track the status of various inputs from relay contacts and monitoring of relay coil energization status. It was on a machine that the OEM refused to use programmable controllers on....an amusement park ride; in this case, a roller coaster.]

So, as I teach, just because _you_ haven't seen one, doesn't mean that they're not out there, somewhere.

I have seen a couple things like this also. I have also seen where someone used an ethernet based PAC for a Data Aquisition Board and had inputs only for flow meter and Temperature readings.

 

[Lancie1]

So, as I teach, just because _you_ haven't seen one, doesn't mean that they're not out there, somewhere.

My original question was about why students focus on Inputs instead of Outputs when they are trying to develop logic to solve a problem.

 

[osmanmom]

example input to output and output to input (IPC25 Honeywell)