what do have to know?

gtcolmenero

Member
Join Date
Mar 2004
Location
South Texas
Posts
1
As a instrument electrical designer I am interested in doing PLC programming. I have a background in computer systems as pertains to the IT world, sach as networking, database design, document management, pc hardware development, infrastructure management, capital infrastructure projects, PDS (Plant Design Systems) as pertains to design engineering, certified electronics tech. Would this type of background make for a better transition over to PLC programming? Or am I barking up the wrong tree?
 
Your the man. to an extent. A good PLC programmer should understand the application, (machine and interfaces, safety issues etc).

For example I design PLC based controllers for elevators. Before I was allowed to even think of doing this I had to complete the entire Apprenticeship Program, and become a Licensed Elevator Mechanic, and Certified in elevator repair & installiation by NEEIP (The National Elevator Industry Educational Program). After I had a thourogh grasp on the application, and the ANSI 17.1 elevator code, then I was let loos to program PLCs for elevator control.

There are a lot of really smart programmers on this forum that use the same components that I use, that wouldnt have any idea where to start building and elevator controller, any more that I would know where to start building the equipment they specilize in.

It seems you have a strong background for understanding PLCs and may make a great programmer. But choose the applications your programming for carefully, and make sure you have a thorough understanding of the safety issues involved etc..

Good Luck with it!

Mike

P.S. here's a good link for you to check out:http://claymore.engineer.gvsu.edu/~jackh/books/plcs/
 
Last edited:
HI
Its look like you have good background for PLCs.
There is two issues left.
1.To know PLCs and understand how they work and how to program them.
(very easy)
2.To understand the application and what involved. and to know how to deal with that. for that you need experience.
I an in that business more then 25 years and I not always feel confident how to solve the problems I facing.
I think you have to join to someone with experience and learn from him how to approach to project and deal with all the aspects.
The rest will come with the time.

Good Luck.
 
I say go for it. Understanding how computers "think" is one of the important skills. For you, this should be a matter of learning some new terminology and relearning some things you already know.
 
My boss who is approximately 10-15
years older than me lays out the
i/o and acad prints for me. I wish I could
do it myself because I would change alot
of things and make it easier for everyone.
However this is the situation I am in.
Basically I am stuck writing the program ,
working with the parts & mess he gave me, getting the machine working and making the
customer happy. Well the one time he tried
to write the PLC code to prove a point.
He proved a point alright he can not
do any kind of programming! What a disaster!I had to start from stratch at the customer site to get the machine going. You would think the man doing the prints can write PLC code. WRONG!!! This is just in my case however.
 
Zombo

I feel for you! I get to spec the components we use and I do the programming. I like it this way for scores of reasons, the best of which is flexibility.

Gtcolmenero you sound like you have the background that would make PLCs the next logical step for you to take. I have a blast doing what I do with PLCs and I don't have near the background you seem to.
My favorite question from someone is: "You can make it do THAT?"

Yes I can.
 
We had the Siemens people at our plant
for a meeting and to get up to date with
what is "out there". They repeatly told
our management and my boss it would be
alot easier and cost effective for the
programmer/engineer/technician to spec
the parts/hardware. They said at almost every other business its done this way. Plus they went out of there way to show how the part #'s etc. can be imported from the S7 software to a spread sheet format and other good stuff. My boss just sat there with a stupid look on his face
and kept saying " What am I going to do"?
The Siemens people told my boss he is still basically do the same job minus the engineering. Which would include ordering the parts and making the drawings. Well that was about one year ago. Since then our other programmer has quit from frustration. My boss is still doing all the engineering. I am stuck with a mess. Plus we are one or two dollars short from shutting the doors. Here is an example of
how bad our place is. For years my boss is improply fusing AB 1746-OA16 triac outputs. He has one 20 amp fuse feeding all the modules. Which is typically between 4-8. When a short occurs you basically have 20 amps feeding through the triac output. The output module circuit board etchings are actualy burning up because of the high current. Several other programmers as well as myself have brought this matter up to my boss , managers and the owner numerous times. Nothing ever gets changed. Our customers want to know why the boards are getting "blown out" when a short occur? This is so stupid but do to pride , indifference or total stupidity it goes on and on. This is just one case I could go on all day. Is anyone else stuck in a situation like this?
 
Sounds like your boss is going to get someone in trouble or worse, hurt. Unfortunately, he's the boss so you have a decision to make. I hate hearing about people who do it the right way working for those that don't.
Sadly, the job market doesn't make it that easy to get away from those type of people.
Good luck--and I hope you have a fire extinguisher close.
 
Your boss sounds a lot like someone I know.. ME!

The big differance is when the other guys catch my mistakes we make the necessary changes. I personally find it far less embarassing to correct the errors in the shop than force it out onto the job and have all hell brake loose there. I repeatedly emphisize to my techs to bring up any and all potential discrepencies in my work.

The big problem is that the techs are sometimes timid about "embarasing the boss" and as a result garbage can go out to the job. So it takes a lot of hard work to keep the lines of communication open, and make sure that I dont react poorly to my techs when they have suggestions, corrections, questions etc...

$$$ (profit) and safety feeds my ego more than having to be right all the time.
 
Just another few examples in what I am dealing with. We built machines which sometimes are quite long and in several sections. I as well as the several programmers who worked here ( now sadly gone because of the madness ) have constantly fought to use remote I/O. You should see some of the machines going out of here. Right now we have one set up for debugging and testing on the floor. It
looks like a blown up spaghetti factory
here. The younger guys have a difficult troubleshooting if something goes wrong.
We had outside drive suppliers looking at the machine and they were shocked! They asked my boss why weren't we using remote I/O? He just looked at floor and was quiet. Another case was we were trying to convince him to use a small HMI screen for changing timer values , roll diameters , etc. Operator friendly.
This took almost four years to do and the
only reason he did was because the road manager got so ****ed off. Its so bad its
really halirious. I run into some off the programmers that worked here before and they still can not believe we are still in business. Many people in our company will not listen or use another person's idea because they did not think of it.
One more comment. For years I am trying to get the management to standardize the PLC's , drives and hmi used on the machine. Giving the customer a price break if they use the standard or add a surcharge if they want another brand.
I was told by two of the top manager it would not work and is not a good idea.
No wonder why the company is almost chapter 11.
 
I am lucky that I am the one that specs out all the components that go into a machine. I find that I have to constantly fight the customer's desire to use a PLC that is different from what I use (AutomationDirect). It is a real bear trying to standardize on one type of PLC/HMI when the customer can dictate how you machine is designed. I have a possible 192 different ways to configure my product line which each require subtle differences to a PLC configuration. Now add using AB, Seimens, GE, etc. and any thought of standardization goes right out the window!

Bob
 
You are right your lucky. You get to spec out your systems. My boss does that and constantly throws a monkey wrench in the works. The owner comes to me and says make programs the same. I could possibly make them close if you use the same brand PLC and I was specking the machine out plus doing the engineering/prints. But I have a
handicap , My Boss...
My boss will have almost two identical machines. The one may have 2 or three more basic I/O cards.Instead of keeping the cards (Which the owner says is OK) as spares he will shift or move all the cards so the addresses will not be the same as the previous machines. Plus he will redo the I/O sheets changing input and output numbers. So I:5/0 may be oil low level on one machine and bearing high tempurature on another! What a nightmare!!!
 
How to make different machines the same.

Zombo:

If the only thing you boss messes with are the drawings, make your life easy -- don't use real I/O addresses in your program.

Designate some files/register spaces as DEDICATED to I/O mapping. (I'm partial to B10 for Outputs and B11 for Inputs when working on AB PLCs).

Use those mapped files EXCLUSIVELY throughout your program. NEVER reference the real-world data table

Except in two subroutine. In the first routine, you'll map the real Inputs to your "image table". In the second routine, you'll do the same to your outputs. The first routine will be the first one used in the program, the second one will be called last.

Now when your Boss hands you a "new" I/O drawing for an "old" machine, the only thing you need to change those two programs files, and you're golden.

Lots of advantages to this way of working:
- If things get changed at the last minute ("We need to move THIS subsystem to THAT side of the plant, and wired into THAT subpanel."), it doesn't cause major reprogramming (or fear that you forgot something in a search/replace)

- You can start programming, and HMI-ing, while the boss takes his time making drawings. You only need the LIST of I/O, not their location.

- If you've got a spare PLC lying around, and time to play, you can use it to do message reads of your B10's, simulate the plant, and message write to the B11's. You just disable those two subroutine calls, and watch the process at work. Simulation is an excellent way to find bugs in your code and/or HMI. And you don't have to worry about removing any simulation logic, or having having a big enough PLC to handle the extra logic - it resides in another PLC. (And, since your simulator is using those internal addresses, HIGH LEVEL will be the same for ALL you systems - no need to rewrite the simulator between jobs.

Anyway, good luck with your boss.
 
Zombo,

This is all a mater of politics. The art of convincing somebody to do it your way is to convince them that it's their idea. This may seem like a joke, but pick up a copy of "How to win friends and influence people" and read it from cover to cover over and over. It may take some time, and hard work, but with the right tact you may be able to get through to your boss. Basically you have to lead him without letting him know he's being led.

This is the hardest part: Let him take some of the credit for you ideas. If you can make him feel like he's not competing with you, he wont trash you and your ideas. The more successful the projects, the closer he will keep you by his side, and the more autonomy you will get. Eventually he will start giving you credit too. This will happen because he will eventually realize that he cant loose you or he’s dead.

I’m dead serious about the book. If nothing else, you’ll be better at picking up chicks, or improving your love life, or doing better at job interviews, etc…

Good luck with it.(y)

Mike.
 
Well now how about that. Advice on bits and babes in the same post. Ain't this a wonderful forum!
I've used Allen's method on setting up new programs as well. Writing the program while waiting for the conveyors to be installed not only helps with the time factor, it also allows me to place sensors and controls on the line in a more efficient way. We, unlike poor Zombo, are allowed to spec our components and we know ahead of time how those components will affect the PLCs I/O.
Zombo, I had problems with our engineer when I first started my current position. We had knock downs about components, especially the use of VFDs, which he fought. I had to prove to him their value and now he has full faith in my specs. Hopefully you and your boss can reach the same level of understanding--everyone will benefit.
 
Back
Top Bottom