What Are Your Lessons Learned About Being a Self Taught Programmer?

Just because a PLC will do structured text or flow chart programming doesn't mean you should use it. Keep in mind if your programming a machine that will/must be running when your not there, that that poor electrician who has to go online may have no idea what the higher level programming is or how to trouble-shoot it. You don't want any 3am calls because they cant figure it out. I have been programming ladder logic for 35 years and have never had a customer say I must use a higher level language. But all of them have said not to if asked.
 
Rule # 1

remember who your customer is, maintenance !
plc code that only the programmer can understand isn't a program, its worthless.
a machine can cost $10 million and is not worth 10 cents if maintenance cannot understand the code and trouble shoot the problem. maintenance will give up trying to fix the issue and when asked by their boss they will tell him that they cannot understand the logic no matter how long they try.
So management hears about the downtime, your boss hears about the problem, and you hear about the problem.. you then spend the next week, month, year writing the code so maintenance can understand what's going on.
in the meantime, you get a bad reputation, your company may loose a very valuable customer in the long run.

LONG story short, find out what the maintenance guys know and understand, talk to them and let them know what's going on, get them involved
DO TRAINING !!

Rule #2
DOCUMENTATION !!!
good manuals with a sequence of events in the automatic cycle, cad drawings that are correct with the machine modifications made (mechanical, electrical, pneumatic / hydraulic), bill of materials.
PLC program that has good rung comments every 5 rungs or so.

#3
only have (1) debug bit that is always on and only (1) that is always off.
document them at the beginning of the program.

#4
as already stated, break up the program.
a multistation machine can be broken up into individual station programs.

#5
only use (1) latch and (1) unlatch bit not multiple latches of the same bit.

#6.
get a good understanding of the machine operations and write it down.
get the customer to approve the document, then write the code in the order of the machine sequence.

#7
Change orders happen - have all program changes documented and signed by the one requesting the change, even if it's a 10 minute fix !! that document saved my rear and the company I worked for and kept us out of a multimillion dollar lawsuit.

#8
multistation machines that do the same thing must be programmed identically using different bits. not 6 different ways.
for example, a 6 station machine using slc 500.
station 1 - b13,t14,c15,....
station 6 - b63,t64,c65....
same logic, different bits.

#9
you have 2 numbers, a and b
a > b
a = b
a < b
always program that logic. a co worker years ago NEVER programmed a = b

#10 have a good attitude with your customer, you may be asked to never return, it does happen !
same co worker mentioned above, plant manager told the boss to never send him there or touch his machines again.

#11 never forget, you can be replaced.

#12 Always make sure the machine is cleared of all tools and workers when downloading the program, going to run mode, applying plant air for the first time, or making online program changes !

#13 if you can ask what if this happens and you don't have an answer, plan for it!

#14 the program in the plc is he master, don't assume you have the correct copy on your pc. Make a backup of your pc program, upload the program to your pc and make a copy.
keep lots of backups so you can go back to your starting point if necessary.

#15 don't forget about BUBBA ! he loves to change things and never tell you or anyone else what he did



lots of other stuff that can be added by others.

james


From my point of view, this is the best advise yet.

Bubba.
 
Rule # 1

remember who your customer is, maintenance !
plc code that only the programmer can understand isn't a program, its worthless.

Does this mean then that the programs running air craft, cranes, marine vessels and all sorts of equipment that only a programmer can understand are worthless?

Personally, I disagree with this approach. I know full well it's a trade off between price and functionality which maintenance departments would be glad to pay, but they don't get a say in it, but ultimately there are plenty of examples of systems operating where the user doesn't need to look into the processor code to understand a problem.
We should aim to do that as much as possible instead of starting from the assumption that the user will just plug in a laptop and have a look at the code when the machine stops as that is a sure fire way for them to actually have to do that.
 
Hello,

I run a small online website called Logix Magazine (nothing to sell). Anyways, I would like to write an article about the lessons you have all learned being self-taught PLC programmers.

I am aware not all of you are self-taught, but for those that are, I would appreciate your opinion of what a newbie needs to know?

Thanks for your input.

I would love to listen to your lessons)
 
#5
only use (1) latch and (1) unlatch bit not multiple latches of the same bit.

james

I must respectfully disagree with Rule #5 - for specific uses.
My implementation of sequence (fsm) state machines uses multiple Set/Reset, Latch/Unlatch instructions.
They are, however, documented as sequence state memories.

For generic process control, I agree with Rule #5
 
never program something in a 'cool' way that only you will understand months or years down the road. Just because you CAN do somethings a certain way doesnt mean you SHOULD.


This is an important one to me. If you try to do everything behind the scenes (AOIs etc) it can be extremely difficult for someone who isn't you to come behind you and troubleshoot the program.
 
Oh, also, aren't we all "self-taught" in some way? I'm sure many of us also had formal college education plus vendor training here and there but this is one profession that one has to do some learning on our own.

Also, add this one:

- Be cautious about making assumption on area just outside your base expertise. In that regard, always try to widen your area of expertise. In addition to the process of your industry, learn PC programming, IT Network, SQL, etc.. Keep your mind open on how to achieve the best result for your customer.
 
#1 advice: Think safety - always. For yourself, and for people around the machine.

Dont hurry, dont stress. Accidents happens when people cut corners.

When running in a machine, and guards are possibly not in place for example, cordon off the area. Be very careful about starting dangerous movements that you cannot visually see from the position you are in.

And before leaving the customers site, the customer must be trained in safety, the safety must be tested and verified. Before the customer is allowed to operate the machine, he must sign to that the machine is safe and his personnel has been trained in safety.
If you dont do this step, and an accident happens, you can get into serious problems.
 
I suggest - Listen To Everybody.

Even the janitor at the clients shop will know more than you how a machine is supposed to run. Every person may be able to provide one detail or suggestion that will be beneficial to the project.

Also, the people ordering and specifying the control may not mention, or know, every detail of operation. This has cost me time when at commissioning it is suddenly realized that something undisclosed has to happen before what just turned on can. Now I require Engineering Changes in writing with a known cost for the changes.
 
cardosocea,

the instances you refer to are very specific and I agree that those are written for the programmers. I am talking in general terms of the average maintenance person. most do not understand function blocks, grafcet, sequencers, mask moves.

kwade,

rule #5
I had a 750 run program written in rslogix 500 for a micrologix 1500.
there were 18 latch bits of b13:2/3 and 24 unlatches for that bit through out the entire program with 8 subroutines. add to that there were 12 error conditions that would set the bit.

when the program faulted, that bit was latched.
I am in no ways the smartest programmer in the world, but how can you tell where that bit was set? a coworker and I spent a week trying to figure it out and I ended up re writing the program.
latches do have their place and i use them a lot when necessary, but this example is what I am referring to.
 
Last edited:
cardosocea,

the instances you refer to are very specific and I agree that those are written for the programmers. I am talking in general terms of the average maintenance person. most do not understand function blocks, grafcet, sequencers, mask moves.


I'll give you that an aircraft isn't operatd on PLC's... plenty of maritime vessels are and are done in such a way that you don't have to connect the laptop in to understand why it stopped. Yes, it is more expensive and at times a lot more work, but the end result is a lot better as it avoids using the laptop as a complement of a poor visualization implementation or documentation.
 

Similar Topics

I'm currently on a project start-up and am keeping a running list of lessons learned. I've learned so much on this forum from you incredible...
Replies
1
Views
10,387
I'm currently on a project start-up and am keeping a running list of lessons learned. I've learned so much on this forum from you incredible...
Replies
1
Views
8,266
I have learned a couple of lessons during this pretty huge demo project I am working. I figured I'd post them, as maybe they will be of help to...
Replies
1
Views
2,512
Evening all, I have submitted a requisition for ~ 5K for a power supply, controller, input, and output card for next years budget. I will not...
Replies
13
Views
2,830
Does anyone have any links to any touch typing lessons? I have a bit of spare time on my hands and would like to be able to learn to type as I am...
Replies
16
Views
5,951
Back
Top Bottom