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

[sethen320]

I think the concern is not with whether or not outputs or inputs are actually more important in any given case.

Lancie, correct me if I am worng, but if not:
I agree that the perspective should always be on the actions (outputs) and its seems with many of the threads started especially by students, this isn't the case.

I can't find a way to play devil's advocate and disagree. Bernie has good points, but still, when he is designing the code, I would expect the focus to be on the sequence of actions, then go back and fill in what in detail must happen as transition logic and permissives.

When troubleshooting and programming I always start with the outputs or actions.

It is been my experience 100% of the time trouble calls are triggered because an action failed to perform correctly. You start with what didn't happen, or what did happen, and work your way back to the devices, wiring, and possibly logic for help troubleshooting.

Same thing when programming, maybe because I wrote thousands of programs in basic and assembly but I always plan my sequences starting with the actions.

New kids should be taught this stuff. The emphasis on cutting through the ******** and starting with the outputs should be commonplace.

This makes more sense. I would agree that when laying out a program and planning the output is definitely the priority as it is the desired effect (which is essentially a real-world definition of "output"). If there are people learning who have not yet mastered this concept then I would suggest they step away from any controllers where safety is of concern.

As far as explaining WHY, well...I can't answer to that as it is *sigh* "highly illogical" (not a fan of Trek, but this cliche seems to fit the bill).

 

[BobB]

The inputs, middle and outputs are all important - otherwise there is no 'result'! Most problems occur in the middle from my experience of well over 20 years of programming PLCs and sorting out other peoples s**t. Get good money sorting out other peoples s**t though - hourly rate really goes up! I suppose I would be better off financially doing that than building new jobs.

 

[Lancie1]

Lancie, correct me if I am wrong, but if not:
I agree that the perspective should always be on the actions (outputs) and its seems with many of the threads started especially by students, this isn't the case.

Yes, I think so. My goal was to understand why students always focus on the controlling devices, the inputs and the switches.

And to get back to the discussion Lancie1 started: if you really don't understand the outputs, hide it and talk about the inputs .

Since Jean Pierre's post, I have been thinking about it, and now I can see why and how it happened. Kids from a young age are exposed to switches, but not to motors. Want the light on? Flip the switch. Listen to music: flip the switch. Everyone knows what inputs are, but few know or are taught very much about the mostly-hidden devices that do the work, the contactors, solenoids, heaters, and motors and such things.

It is only human nature to try and simplify the things not understood. Can't explain how a motor works? No problem, all you got to know is how to turn on the switch on the washing machine.

Thanks to "jvdcande" for the clue, I am satisfied about how this phenomonon developed. I don't think it is a good thing, but at least I see why it exists.

Some day in the future, some mad leader will have the scientists, engineers, and technicians killed off for political reasons, and flipping a switch will not cause the clothes to get washed or the music to play. There will be a world of people with technology they don't understand and can't rebuild. What then?

 

[Brijm]

This still seems like a philosophical methodology to me, and I have yet to see, why one way is correct over another (start from the input side or the output side). Why is this more than a personal preference? Now if one is neglecting one side or aspect of the program over another, then that is a problem.

Personally, the reason I start with the inputs; is that for me, the operator interface, is the priority (how the man interacts with the machine). In small projects this is obviously less important, as controls are simple. However with more complex HMI's; how the data is obtained and displayed, may often change the way that I program the ladder.

To me, this discussion is about the same as those who insist that troubleshooting should always start in the middle, and isolate in halves, until the problem is found. I say not necessarily. While this methodology may have it's place, it is not always the best. The key is to work in a systematic way, keeping the entire picture or sectional scope in view at the same time.

 

[dmargineau]

My two cents veer towards Lancie's "theory" and I personally had to "educate" myself within this approach...
CPU controllers, after all, are devices designed to "make things happen" depending of the state of the inputs and following the user program.
Since we probably all know that once "something happens" it is invariably irreversible, an automation system's outputs will have the outmost priority within the system's components.
Theoretically, an automation system could operate without (or minimal) user input + instrumentation (and the trends point that direction ), however, it is obvious that you cannot reduce the number of needed outputs; chances are, soon enough, automation systems' outputs will "outnumber" the inputs by at least one order of power.

 

[Lancie1]

Now if one is neglecting one side or aspect of the program over another, then that is a problem.

Yes, that is what my question was about - why students do neglect the outputs in favor of the inputs. Check it yourself - search through some of previous student posts and see how many times PLC outputs are even mentioned. Many times, the student list of parameters do not even include outputs as a needed item, but only the switches, sensors, timers, and counters are listed. When asked about what output devices are available to do the work, there is a long puzzled silence, followed by more talk about the input devices.

I now think (due to Jean Pierre's hint) that this neglect is because many students start at a level where they are completely ignorant about the output devices. They don't understand them and have no experiece with them, so try to solve the problem without the part that they don't understand.

Since we probably all know that once "something happens" it is invariably irreversible, an automation system's outputs will have the outmost priority within the system's components...however, it is obvious that you cannot reduce the number of needed outputs;...

That is what I have always believed, but I am beginning to see that it is NOW a minority view, and somewhere along the passage of 50 years, views have shifted. Apparently many now believe that a switch is not a control device among many, but The Action Device, the part that makes things happen.

 

[jamesau]

The input-side to real time systems is what makes them interesting and what drives up the complexity of these systems. Perhaps it's this complexity that gets people hung up?

If a system has only outputs, you just specify, design, and program the desired behavior; you have freedom to completely specify the system states. Once inputs are included, the complexity goes up quickly because the designer has very limited control of when inputs, in what combinations, enter the system. Now, along with desired behavior, there's exception processing, arbitration, and greater uncertainty that needs to be addressed. I think this is the aspect that may confound the apprentice. It's this nature of real-time systems that is probably not addressed in most academic 'programming' class environments.

When designing systems, I consider the (normal) desired behavior of the system (you can almost do this without regard to field inputs). Consideration too must be given at the outset as to how the operator will normally interact with the system (a certain class of inputs).

Once normal processing is nailed down, exception processing must be considered. This may include state transition timeouts, interlocks, operator intervention (Hold/Abort), et cetera. Exceptions must be handled to predictably and gracefully suspend and restore normal processing. People who may have some programming background but no real-time systems experience will caught out by this.

 

[Pireciter]

Long time lurker(~2008), but this input vs. output topic struck something with me because I've been there and seen it first-hand.

A quick background: I only graduated with my BSEE in 2009 and between my co-op, some contract work, and my current job, I have ~4-5 years controls experience.


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. There were rarely problems like "I want this light to cycle on/off every second. How do I do that?"

I found all the problems went a lot better for me if I started with what I wanted the system to do (Cycle the light), then focus on how I got there(Toggle switch, 1-second timers, etc). Took a little longer, but helped me see how everything interacted better in my mind. A lot of my fellow students went through these problems quickly when the inputs/outputs were clearly laid out. However, when we were given system outputs and told to figure out the inputs, they were completely lost because they kept trying to start from the input side and work toward the outputs. I helped a couple of them with these problems when they came up.

I'm not saying you can't program one way or the other. I'm not sure if it's even a white/black kind of idea. I personally have found working from the outputs back has made a lot of my controls problems a lot easier to figure out.

However, no matter how you program, you do tend to find that most problems spawn somewhere in the middle...

Pi

 

[Stig]

I agree with you completely

Yes, but if the goal is to program a machine (similar to say, solving a word puzzle), you need to start with the answer (similar to the PLC outputs) and work back to what you have to get there, the given clues or letters - (the PLC inputs).

In solving a puzzle, if you start the backward way, there are thousands or millions of dead ends that will not work (****, you really don't even know where you are trying to get because you started without looking at the solution). That is exactly what happens to the students who show up here, confused and frustrated. They don't know where they are going, so are unlikely to KNOW if or when they get there.

Heck, it is no wonder that this problem keeps coming up again and again. Nobody seems to know the method of solving puzzles anymore.

Hmm... if I said to some children that I know, "the toast will come out here. What could you do to make that happen?", then it would not be long before they figured out what that big hole is for. The rest is details.

Every project I have started begins with "what do I want it to do" My order of programming starts with the outputs, from there I go to: What, When, Why, How. When problems appear (and they always do) then look at the info the inputs are providing and find out why it is not acting as planned.

For instance I put a PLC on a freezer door, What:2 speeds, slow travel, fast travel, slow travel, stop. Reverse direction, slow travel ,fast travel ,slow travel ,stop. What:Solved. How: a combination of PE's, Single Push button, How:Solved. The rest was easy to fill in, and this is coming from somebody that has been self taught with no formal training. The modern education system is becoming a "Guru Meditation" Error.

 

[Stig]

Vartile, that is a very fine example that shows the point. It is much easier to start on the Output side and work back to the correct Input, than to do it the other way. Exactly the way I think it should be in solving a PLC programming problem. I have not found a beginner yet that does it correctly. Look at those dead ends! Look at all that confusion, as the dog chases it's tail around and around! Think of the hundreds of new questions that will be pop up here!

Vartile, You will go far, my friend!

Has anyone figured out the correct input yet?

The middle input was the first one I found, need to go back and look at it to see if their are any other combinations.

 

[Stig]

All three inputs can be tied into the output.

 

[beethoven_ii]

As with most things in life you have to put something in before something comes out.

 

[blueyedpeter]

Most beginners like myself would consider a plc much like the fabled beige box at there work place , they know almost nothing of its inner workings , but claim to be the kings of the world until it crashes . If you were to ask if an input was normally open or is it examine if open , then whats the difference or are they the same or could it be that the input might be found closed at times or open . So after they tackle there first project the humble three wire motor starter and they find every conceivable way of getting it wrong . It was burning in the back of there minds that they would like the plc to turn on the motor , if you have little to no idea of how you are going to get there or even for that matter what you could use how on earth am i going to turn it off again .It would be obvious if you had a good mechanical / electrical idea and then to try and convert it into a program would be a great starting point , but at the end what we take for granted and have forgotten over the years , students have yet to realize .Most of us are great followers and only a select few are true trail blazers .

 

[Lancie1]

As with most things in life you have to put something in before something comes out.

Yes, but is the "putting something in" the first step, or should it be some later step? If your namesake Beethoven had not started with a musical idea of what sound he wanted to come out, would he be likely to just fiddle around with some violin and horn notes and come out with a great composition?

I think first you have to have to visualize the final product, the result, the action. Then you can decide what inputs are needed.

All three inputs can be tied into the output.

Yes, they could have been, but ONLY ONE is. That was the point and much easier to see if you started on the Output side.

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.

Thanks, Stig. That makes me believe that I have been seeing a real phenomonon, not my imagination. It could be that many instructors do not have the experience to know what is important for solving a PLC programming problem. Many college instructors are theory guys, with little or no hands-on experience. Theory and equations are great in their place, but usually a PLC involves many real-world problems that don't relate well to theory-only solutions.

 

[bce123]

Lancie, heres how I see it:
You could not give you your output(reply) to my reply(input) before getting my Input( reply)Just as I could not give you my reply(output) before seeing your post(input)