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

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.

iadapt said:

I would appreciate your opinion of what a newbie needs to know?

Click to expand...

1) Find resources that will help you... plctalk.net :site: and youtube are great places to start
2) Get some real hardware/software and dive in.
3) Study the brand that will help you the most accomplish your goals, if you have a bunch of AB hardware at your work lean AB first
4) Before you start programming write the project out and ID all the IO that you will need
5) If safety is involved get help
6) Dont expect to land a job programming, maybe start with something else.

Make daily backups during a project with the date in the project name - you can delete them after the project has shipped.

If you have access to any machines with PLCs in them and you can upload the programs, do it. Reverse engineering a program is a good way to learn different ways that people write code. Then you can decide what you do and do not like.

Break code up into small chunks rather than trying to accomplish everything in as few lines as possible. It's one thing to become efficient, but until you've become regularly effective, shooting for super-compressed code just makes things more difficult for you and for anyone following behind you.

Keep multiple copies of the program. I'll usually keep an AM and PM verion of the software when I'm on site.

Put the date and version # in the file - many times PLCs are version specific. The last thing you want to do is go to a site and not have the correct version software to modify the program.

I use something like:

Project_Name_2019_08_11_V20P01_AM

Year-Month-Date helps with sorting in windows explorer and keeps the most recent on top / bottom.

Hi

No matter how long you are at it never be afraid to say
“I don’t know but I will find out”
“how did you do that“
“I got that wrong”
“I think I need to rewrite that”
“That’s very clever I wish I had came up with that”
“ that was not my idea, I saw it in another program”
And
“ do you know, your idea is better than mine”

Read and help that is out there

donnchadh said:

hi

no matter how long you are at it never be afraid to say
“i don’t know but i will find out”
“how did you do that“
“i got that wrong”
“i think i need to rewrite that”
“that’s very clever i wish i had came up with that”
“ that was not my idea, i saw it in another program”
and
“ do you know, your idea is better than mine”

read and help that is out there

Click to expand...

+1

Learn how to simulate a system, then have it all automated.

Example, 2 valves and 1 tank. Open fill valve the tank starts filling at a rate. Close valve and see the liquid level in the tank. Open the drain valve and the tank starts draining. No hardware needed, just an emulator and factorytalk (or anything for visual). All systems can be simulated and it should give you a better understanding of how you expect the system to work.

when you get frustrated and think that youre not going to be able to accomplish something up to your own personal standards, walk away take a breath and zone out for a bit. usually when you come back to it with a better mental attitude you see things that you didnt see just before and you can work your way through something much faster.

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.

Be sure that you understand the process you are trying to control before you try to write code to implement it.

Thanks geniusintraining, jstolaruk, T Gibbs, Steve Etter, Rson, Donnchadh, mobsoft. I couldn't agree more with everything that's been offered.
I will draft a post and share it with you all when I am done that offers your suggestions to beginners as good advice. Thanks to those who've contributed so far!

Donnchadh +1

For me, first and foremost is get as clear an understanding that you can of what the end goal is but don't be afraid to change it to better suit your needs. Once you know the end goal, break it down into smaller pieces and tackle them one at a time knowing that changing one piece will likely change another but that's OK, as long as the end result meets the goal.

Seconds, play around with the technology every chance you get. Think of an idea that sounds like it would be fun to do and do it. Early on in my PLC career I started using them at home for Halloween and Xmas displays and what I got out of that was, one, I'd blow the neighbors doors off with regards to "cool displays" and two, I have fun learning new things you can do with them.

Third, try to solve other peoples problems for your own education. There has been many occasions where I'd read about what someone else is trying to do and if I had the equipment (or close enough to it) I'd try to do what they were trying to do. I can't tell you how much I've learned over the years on that one including one of the things I probably use the most (outside of basic programming). The subject of toggling an output or a single bit using a single input (or bit) comes up from time to time and for years I'd ignore it but one day I decided to follow along with a thread and found a solution that is simple and useful and discovered that it really is a powerful little tool to have in your back pocket.

I could go on and on but let me leave with this. Some of you know by now that I've been a volunteer in the fire service for 30 years now and I've learn a lot of "life lessons" in that time but there is one lesson that I picked up from one of my mentors that has probably had the biggest impact on how I live my life and how I teach others (in areas that I teach or have taught). It's a simple quote with a powerful meaning; "A smart person learns from their mistakes. A wise person learns from their mistakes and the mistakes of others". I some respects that's what this web site is all about. Lots of people who have made many mistakes but learned from them and now pass along that knowledge.

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