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

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...

What I would do is set 18 different latch bits, then XIC all 18 to OTE one bit that would trip the fault condition. Then you can tell which of the 18 latch conditions was true.
 
Aabeck,

my co worker and I looked at the operation sequence and did just that.
the existing program jumped around to much.
we reviewed what I had programmed, then he studied it for a couple of days,
discussed it again, and put the program in with minor issues.

james
 
Hello All,

It may seem peculiar but there are many people (especially newbies) who look at Automation Professionals with awe.

Thanks for sharing your wisdom. I took a chance telling you all about my online magazine, I didn't know how you would take my question, the magazine is my baby these days.

I hope to share the inside life and career of the "People Behind the Automation" in it.

So on occasion I hope to get some input about you all, your lives, your work and your families and share what you will let me with the world.

Thank you...
 
Learn from your machine operators. They will discover all sorts of new and interesting ways to trip up your carefully crafted program by trying to do things out of sequence, power cycling the machine, trying to do steps out of intended order, etc...

25% of programming a machine is getting it to do what you want it to. 50% is coping with what happens when someone hits an e-stop, power is lost, the cycle is stopped mid-way, or something jams. The last 25% is the hardest - operator-proofing it. You will know the system so well that it's hard to break it by being ignorant of what should happen. Let someone else try to break it - I guarantee they will.


-rpoet
 
Learn from your machine operators. They will discover all sorts of new and interesting ways to trip up your carefully crafted program by trying to do things out of sequence, power cycling the machine, trying to do steps out of intended order, etc...

25% of programming a machine is getting it to do what you want it to. 50% is coping with what happens when someone hits an e-stop, power is lost, the cycle is stopped mid-way, or something jams. The last 25% is the hardest - operator-proofing it. You will know the system so well that it's hard to break it by being ignorant of what should happen. Let someone else try to break it - I guarantee they will.


-rpoet


I wanted to write something similar to this, from my short experience is like that.
You write a sequence, make it work and then you spend 3x more time to make it fail-proof for all possible what-ifs.
And then you still can miss some ifs.
 
My 2 cents

Whatever happens, and however good the system and program design is, it always breaks!!

Apply KISS principle (Keep it simple, Stupid!). And get someone else to agree it is simple. Its always simple according to main programmer.

In simulation, always, and always do multiple cold restarts and see if the program is still working as expected
 
sanchit9590,

when I worked for am oem before I left, one of the requirements was that we gave a copy to maintenance, let them study the program and then we got together to discuss the program, its operation and sequence.

by keeping them involved, they felt like this was their machine also and we rarely got calls, and when we did, they really had a problem.

do I over simplify plc programming, probably.
do I write a detailed document when a 2 page report would work, definitely.
why?
not everyone in maintenance writes programs for a living.
the detailed documents is for the next guy they hire or a coworker who has never worked on that equipment before.

james
 
@James:

I agree teaching and discussing the program with Maintenance. That indeed is the best practice.

However, my recent experience has been either clients not allotting the budget for this, or software/IT managers asking to hide the code because of similar practice in IT fields. (And them thinking operators and maintenance know no programming) (Automation started only recently :ROFLMAO:)

Since next gen-PLC engineers/technicians are coming from that realm, they forget its Operations and Maintenance who will fight the fire after programmer has done the PLC programming.
 
An interface is like a joke...if you have to explain it, it's really not that good.

Meaning, take extra time when creating,HMI screens, alarm Texts, etc. it is time well spendt
 
How about - don't try to do things that you are sure you will remember later.

Write comments and descriptions on how & why you did things, because when you get in it in 3 years without comments you will be just as confused as anyone else.

I got called to one machine I built here then we sold it and for the life of me I swore I never saw it or programmed it - but it had my schematic and my programming structure.
 

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,382
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,263
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,507
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,826
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,946
Back
Top Bottom