Next course in automation

Hello Enlightened Control Engineers!

I seek your valuable wisdom and experience.

I am an embedded software engineer and worked very briefly with AB SLC 5/04. Since then I was hooked with what it could do to control the outside world. And I am keen on entering the automation industry.

I am now doing a course in PLC Programming and it is getting to the end. What would you suggest that I take up next? I keep seeing job adverts in newspapers for engineers with PLC & HMI experience. Since HMI softwares are generally vendor specific, do I have to buy their product to learn it?

In any case, do let me know what you think would be the next most relevant subject that I should learn.

Thanks a lot
simplelogix

Well, you sure can try to buy something. There are plenty of afordable systems, or check eBay. It maybe an interesting
alternative is to get the real thing while working among
people who already know it while working for less money or
even volunteer for few weeks.
This way you don't get just knoweledge of one system but you
get the chance to learn what other products are used, work on
variety of different software tools, learn who are the
customers etc. (each customer could be employer...).

If you programed computers and did a course all you need is a job. try to find a mid size or a big company so you will be part of a team and not in charge of the all thing.

Oh, and more confidence

Hi panic mode and Eugen,

Thanks for your suggestions

Simplelogix, this is not directed at you in particular but to new programmers in general. I can appreciate the experience you must have as an embedded controller programmer.

It is so disheartening to see someone learn to swing a hammer at nails and then have the nerve to claim to be a carpenter.

Learning how to "key-punch" code into a PLC does not make one a programmer.

There are too many hammer-swinging-programmers out there looking for a nail.

I believe there is are at least one two... RESET

The answer to the question "What next?" depends on how serious you are about developing your skills in process control and where you really want to take those skills.

Some programmers are content developing nothing more radical than simple "switch-handlers". Some wish to be competent at motion control. Others wish to go beyond the relatively simplistic realms of switch-handling and motion control and move on into the development of "intelligent" control systems.


There are a few things that I consider to be minimum requirements for being a process developer.

Digital Logic Design

This is the absolute minimum requirement.

This is where logic is analyzed in a purely abstract form. That is, the purpose of the study is not so much to develop a final product as much as it is to develop the skills of developing logical relationships. This goes far beyond the simple concept of truth-tables.

Having a well seated understanding of this area of concern does not, in itself, eliminate spaghetti-code. However, the existence of spaghetti-code clearly indicates that the developer has very little, if any, understanding of this most important area of logical development.

This is the very foundation of reasonable logical control.


Dynamics

If you plan to be involved in Motion Control then this is another minimum requirement.

This is the study of the motions of bodies under the influences of force. If you expect to be involved in developing motion control then you really need to have a reasonable understanding of the relationships involved in moving bodies through space and time.

Employing Dynamics in a real-world application requires that you have at least some sense of the Strength of Materials. That is, the relationships in Dynamics can be applied theoretically to any "body". However, whether or not the body can survive depends on the ability of the body to resist those forces that would tend to destroy it.


Mathmatics

For any kind of motion control, be it moving bodies or varying analog output signals according to some dynamic relationships (for example, precisely controlled closed-loop heating or cooling functions), you must have a solid command of Algebra.

It would be very good to also have a solid command of Trigonometry and Geometry. However, if you are at least well versed in the "concepts" of Trigonometry and Geometry, you can develop solutions through Algebraic means alone using basic mathmatical functions.

At the very least, you must have a reasonable understanding of the "concepts" behind the Calculus. That is, the concepts of Integration and Derivatives. These are fundamental for understanding the relationships between motion and time. Again, if you understand the concepts you can develop solutions using basic mathmatical functions; that is, you do not necessarily need to employ "Calculus" per se to develop a solution. Calculus is nothing more than the employment of simple mathmatical functions, repeatedly, on a succession of very small segments. Applying the tools of Calculus will provide an "exact" answer. That is, you will have an answer that is precise to whatever number of "places" you choose. Of course, you would need to know the "Tools of Calculus". However, very reasonable and practical results can be obtained by simply using basic mathmatical functions. In that case, you simply need to understand what the Calculus method is trying to accomplish and then apply the basic mathmatical functions towards the same end.

BEGIN TANGENT:
One of the most intriguing examples in Calculus is the question of how much paint is required to paint an "exponential fence"?

Assuming that a fence builder was instructed to build such a fence, starting at Height = "H" and then proceeding down the length of the fence reducing the height exponentially until the heigth was zero, it should be easy to see that fence builder will still be building the fence.

I sure hope he's being paid by the hour and not the job!

Let's assume that the fence simply exists and that we know the exponential rate in height change. We can see that the height of the fence never goes to zero. And yet, we are tasked with ordering the correct amount of paint - no more, no less.

So, how much paint does it take to paint this fence of infinite length?

Infinite length? It must take an infinite amount of paint!

That does seem to be the intuitive answer. If you were to try to apply the Algebraic solution to this question you would never come to a conclusion. That is, the answer would indeed appear to be that an infinite amount of paint is required.

However, using the Tools of Calculus, Integration in particular, there is a definite limit to the area under the curve. Therefore a definite and specific amount of paint can be ordered to paint the fence.

It's so counter-intuitive... isn't it?

The point is... while the Calculus Tool of Integration will provide an exact answer, a reasonable and practical result can be obtained by algebraic means if you know when to say "when".

END TANGENT:

And then of course, there is that little matter of understanding how to "systematize" a process into a "system". This is not to be confused with the physical components of a physical system. Rather, it is the co-ordination of all of the (sub-)sub-processes within larger processes with the greater process thus resulting in a well organized, well functioning system.

Many confuse this use of the word "system" with the word "system" in "System Integrator". There certainly is, or at least should be some over-lapping in the meaning, however, each comes from the opposite direction.

The "System Integrator" brings the things together that are necessary to make a system possible. The "System Developer" does the actual task of creating the system (It's Alive! It's Alive!).

It's kinda like the relationship between Igor and Dr. Frankenstein.

(107)

Terry,

Thank you for the detailed reply. Most of what you have suggested, I am reasonably aware of I believe. I have done an engineering degree in electronics and computer control but have been working with embedded systems for a long while. So I do need to brush up on my Strength of Materials and Dynamics of Motion.

And yes, I am looking to be an ace in motion control. In this regard I must also ask another question. I hear people saying, "PLCs? Anybody can program one. You dont need to be an engineer to do PLCs". Does that mean that spaghetti code is the norm in the industry rather than structured code? And contrary to the general opinion I mentioned, I find that it is not so easy to program a PLC.

To get my foot in the employer's door, I need to at least spruce up my resume with what he wants. This was the reason for my question. I am not sure how things work in your country. Over here in New Zealand, employers try to get the "best fit" for the job before they consider someone who is keen to do what he wants but lacks experience. They are willing to wait for a long while to fill the position.

Thanks once again for your thoughts, Terry.

Simplelogix said...
"And yes, I am looking to be an ace in motion control. In this regard I must also ask another question. I hear people saying, "PLCs? Anybody can program one. You dont need to be an engineer to do PLCs". Does that mean that spaghetti code is the norm in the industry rather than structured code?"

Sad to say... the answer is yes.

This is because most PLC Programmers have not developed their expertise from an Engineering point of view. There are by far many more Electricians and other non-Engineer types (some of which do an excellent job) than there are adequately trained Process Engineers (some of which do a terrible job, despite having had the training).


Simplelogix said...
"And contrary to the general opinion I mentioned, I find that it is not so easy to program a PLC."

When you say "...program a PLC." that illustrates my comment about "hammer-swinging-programmers looking for a nail".

There is a world of difference between programming a PLC and developing a process.

If your comment means that it is hard to enter code into a PLC, that is one thing. There are a lot of so-called "user-friendly" programming interfaces. Many of them are neither "user-friendly" nor are they intuitive.

However, I hope you mean that it is hard to develop the code that you then enter. That is the proverbial horse of a different color.

Developing the code is by far the most complicated part of developing a process. Even very small and apparently simple processes might require a great deal of careful planning for the code. Using the "classic" PLCnet response... "It depends". The nature of the code depends on everything in as much as everything depends on the code. It's a co-dependence sorta thing.

The biggest problem that programmers make for themselves is when they sit down and begin developing the "process code". They are trying to write their code in terms of the entire process.

That can't help but be overwhelming, confusing and ultimately, the source of most spaghetti-code.

The secret is "Modularity". Don't even consider thinking of code until you have clearly and completely identified the entire process in terms of modules and sub-modules within the modules.

Also... don't even bother trying to create an I/O List at this point. You can't possibly build that list until you "know" what you need!

Caveat: After you finish identifying your modules you will most likely have to go back and redefine your list of modules. This usually happens when you begin to think on the details of how a particular module is to function. Sometimes you find that a module needs something that has not been specified in that module or any others. Sometimes you might find that you haven't really broken a particular module down to its' constituent sub-modules. At any rate, you are bound to revisit this part of the development process many times before you are through.

Once you have your process broken down into a list of modules and sub-modules, begin considering the output devices in that module. Consider the specific process-reasons that you would want to turn on the device. The fewer the number of process reasons, the easier to develop the control scheme. Some devices might turn on for one of several process-reasons... it depends.

Each reason becomes a separate "causal factor". Each of those "causal factors" needs to be developed separately.

 Cause-A

---| |---+---( Output ) 

         |

 Cause-B |

---| |---+

         |



         *

         *

         *



         |

 Cause-X |

---| |---+

Cause-A gets developed as a single sub-module. Likewise for causes B through X. The Output only needs to see that it has a valid process-reason to run. The Output does not need to interrogate other aspects of the system for a reason to run. It simply sits there waiting for the reason to come. Now, you have to properly develop the "reason".

Aw jeez... I just gotta write that book one day.

The deal is, develop the process one module at a time. While developing the modules, be mindful of information that might be needed from or by other modules. This information is passed in the form of "flags". No module should expend any effort examining the conditions or states within another module. (This does not mean that modules can not share inputs. Sometimes they do... it depends.)

If Module-A needs to know that Module-B is waiting for the next part to be delivered, then Module-A should sit on its' hands until it "sees" the flag from Module-B indicating... "Hey, send the damned part, already!"

As you develop the module, your Input List will essentially write itself.

Gotta go... the plaster has dried and I have work to do.

More info available if you want it... ask some questions.

-------------------------------------------------------------------
Terry said:

If your comment means that it is hard to enter code into a PLC, that is one thing. There are a lot of so-called "user-friendly" programming interfaces. Many of them are neither "user-friendly" nor are they intuitive.

Click to expand...

--------------------------------------------------------------------

No, I meant your second opinion, Terry. I can see how the codes turns to spaghetti when you just look at conditions to turn outputs on and off. And without formal training, I guess that must be the approach people usually take.

I am sure your knowledge has been distilled over the years through training, experience and books. But would you recommend a good book for developing PLC code? I got some useful stuff regarding state machines from Ian G. Warnock. I the book is called PLC Applications.

---------------------------------------------------------------------
Terry said:

Once you have your process broken down into a list of modules and sub-modules, begin considering the output devices in that module. Consider the specific process-reasons that you would want to turn on the device. The fewer the number of process reasons, the easier to develop the control scheme. Some devices might turn on for one of several process-reasons... it depends.

Click to expand...

--------------------------------------------------------------------

The part about modules and sub-modules using top-down approach I am familiar with. I hadnt thought of the inter-relation between the process-reasons and the outputs. That is quite an eye-opener.

In embedded programming I have gone both ways. I have gone straight to the pc and begun punching in code to arrive at a solution, going through multiple iterations along the way. I have also sat and planned and not touched a pc until everything was clear. I must say, overall, what worked for me was about 80% planning and 20% on the computer, ironing out the kinks in areas that I was not familiar with.

Thanks for your comments Terry. You can expect me to bombard you with heaps of questions now that you have left the door open lol.

I know of no such book.

The book you are asking about is the one I was referring to when I said... "Aw jeez... I just gotta write that book one day."

Hi Simplelogix

If there is any company in NZ that manufactures automated cutting tables or CNC machining centers? You could see it all computer, plc, servo motors,ect. all working on fiber optics. All this in one small package.This would, you mite say get you jump started in the automation field.

Good luck
Tom

Concepts esseciais were added the answers.

At the very least, you must have a reasonable understanding of the "concepts" behind the Calculus. That is, the concepts of Integration and Derivatives. These are fundamental for understanding the relationships between motion and time.

Click to expand...

This, can become a new post.It would be good understand is association with movement. It prolong the vision of many

A'int no damn book.

Understanding here to there, a + b etc...

Approach is what you have to learn, no matter what problem.

Any sum ***** can write code to make a cylinder extend and retract, but a code writer covers all the what if's while he is writing.

Life is at stake on all applications!

Good luck

Right-on, Mike!

I can see that Terry has a whole lot of theroretical training. If I had to consider all that HE does for every project, I am afraid that my boss would be looking for a new programmer....Oh I forget, I am the boss...

No, I do not start with Function Blocks, an idea that was popular back in the 1980's. I start with the known OUTPUTS, and enter 1 rung for each Output. Most programmers try to starrt with the Inputs. There are usually many more inputs than outputs, and does it make sense to start with Inputs, when the Outputs are your "final product"? I will split the program up into subroutines or blocks if it makes it easier to understand, but I don''t waste a lot of time on that part. Then for each Output rung, I put in a method to turn it OFF. If I can't turn it OFF, then I never want it ON in the first place. Then I figure all the ways that the rungs needs to be turned on, and put those instructions in. Then I go to the next output, and repeat until done. Now I go back and look at any previously unknown outputs that should be added. Then I do a final visual logic check on each rung, and then download and test it.

I have found that it is EASY to make a PLC correctly switch the outputs ON. What I find difficult is keeping it from doing all the infinite number of things that should not happen. By Terry's theroretical way of looking at logic, by definition there are a limited number of CORRECT ways do any job, but an INFINITE number of wrong ways. How do you know when you have protected against all those INFINITE wrong paths? Logic analysis will not provide the total answer to that question in the real world. It still takes a little practical experience to know what you have to guard against, and what you may safely ignore.

The Solution

Very nice thread and a lot to think about.

Sure there are many ways to get to the solution or right solution, even when you have developed some kind of routine still you follow one or some of the theoretical rules.

But I am looking for the right solution can somebody reply to me with that one.

Please!

Originally posted by Eugen
But I am looking for the right solution can somebody reply to me with that one.

Click to expand...

Seven. I've always had really good luck with seven as the answer.