Show me how to think

So while I was reading a good thread (read it if you get a chance), I started to wonder...how do programmers think, on rsdoran’s signature ""Tell me and I forget, show me and I remember, involve me and I understand."" That’s very true, but to elaborate further "show me how to think so I can do it myself"

On that thread a person asked how to do it with NO and NC contacts, Net man came up with one way, then Bernie came up with several modifications of his own (that were very good) and Terry’s "Karnaugh map" (thanks for taking the time Terry that was very good), I know that we all have different ways of programming, some a karnaugh map, some write the process down, some "off the hip".

Yes I think the vast majority of us could of came up with Bernie’s solution or something very close that would of worked, but as we all know time is of essence. I feel that it second nature to Bernie and to many others, thats what I'm looking for (the edge), what will make me a better programmer.

So how do you program? What’s your advice on how to cut the time down? and make a better program.

I know one mistake that I make is jumping into the program to fast, before the wiring is done I'm ready to program, but hell that’s the fun part

I basically chop the process into small parts its normally easier to break it down, create standard sub routines for repeated functions (motors, valves, conveyors, etc), being a predominant Siemens programmer its the easiest way anyway.

I don't do flow/logic/ker? whatever its called diagrams/charts, unless the section is particularly complex and then I only do the complex sections that way.

Do spend time on memory maps though, certainly helps on repetative stuff for cutting and pasting and re-addressing when the basic block has been tested.

I like to keep addresses in the PLC's similair. For example, if using PID's, the first one might be N10:0, the second N10:25, then N10:50 and so forth.

I also use subroutines for each similair fuctions. If I have ten different loops, I have 10 sub-routines. Then if the first has 15 rungs, I just copy and paste, do a search and replace and its basically finished.

I have also lost count of how many programs I have wrote, but I keep each one of them and a lot of times its just a matter of copying certain rungs or rountines from past programs.

I think the biggest thing is that some of us have been programming for many many years, we have been exposed to doing things a variety of ways and over years have learned to apply that knowledge.

geniusintraining said:

...So how do you program? What’s your advice on how to cut the time down? and make a better program...

Click to expand...

Clarity comes from STRUCTURE. K-maps exist to minimise the bolean STRUCTURE.

Smaller structure often are easyer to follow.

You want to program fast?

First take your time.
Second Establish the structure.
Take notes.
Write comments.

If you do it you'll find out your fast after all.

as far as 'time is of the essence' stuff...that speed & sense of urgengy come from having to program/troubleshoot/offer alternatives under pressure. As far as teaching someone to think, well, methinks this is futile. To argue a point with Pierre, clarity comes from understanding structure, not structure in itself. While you can teach people to think a certain way, this is usually the way the teacher thinks (and has been taught). Bernie had the 'it' you're searching for before he was introduced to circuit logic, as most really good programmers/troubleshooters know... either you have it, or you don't.

just my opinion...

Git...

Haven't you learned yet? In this field, when it comes to doing the right-thing, NOTHING IS EASY!

The right-thing most certainly SHOULD be done... but, more often than not, doing it as right as it should be done is not so easy! It never has been easy to do the right-thing! Why do you thing we find so many cases of the wrong-thing being done? Why are there so many folks in prison? Could it be because they (like some programmers) think that using short-cuts is the way to go? DUH?

Have you ever heard of the conflict regarding Gain vs. Bandwidth?

For any given amount of Power, Gain is inversely proportional to Bandwidth. That is, as Gain increases, available Bandwidth decreases, and, as Gain decreases, available Bandwidth increases. The converse is also true. There is only so much Power available.

The only way to increase both is to increase the available Power (KNOWLEDGE + EFFORT ???).

You are asking for a way to increase both without increasing the available Power!

In terms of programming...

Generally speaking, results are dependent upon effort.

However... PROPER RESULTS are dependent upon sufficient knowledge and sufficient effort!

If knowledge is low... then there must be a great deal of effort in order to even possibly obtain a usable result. However, if knowledge is low enough... then, no amount of effort will provide a usable and sustainable solution.

Even if knowledge is high, if effort is low enough... then, no amount of knowledge will provide a usable and sustainable solution.

The primary problem that I run into, over and over again, is partial solutions. Solutions that are perceived to be... "good enough"... only to find out later that they are not really good enough.

Following short-cuts are nothing more than being short-sighted.

Didn't your Momma teach you to do the right thing? No matter how hard it was? My Mom tried, sorta, but it was my Dad, when I came to understand his own experiences, that taught me to appreciate and to be willing to go through the school of hard-knocks so that I could learn how to do what really needed to be done so that I would then be... truly proud to put my name on my work!

My Dad asked me, many times, "Are you proud enough to put your name on this? Are you proud enough to let the world know that you did this? If not, then do what you have to do to make it so!"

"GeniusinTraining"??? Well, since you claim to be a "genius-in-training", wouldn't you want to know the real mechanics (logical and physical) behind what it takes?

Quit looking for short-cuts. You're only gonna screw the Operators and the Maintenance folks!

BITE THE BULLET!!!

You'll be more than glad that you did!

Generally speaking, I would say one of the most important parts of programming is the profound knowledge of the process you are trying to control. Be it cutting tools, metal forming, chemical reactions, etc. Most problems I have encountered stem from not having a deep understanding of the fundamental process. Also, as Terry states, taking too many "shortcuts" to try to save money of time. I can't count how many times I have seen a machine with actuators (pneumatic, hydraulic) that have NO feedback (limit switch, pressure switch, etc.). Just a timer in the program. So the control "assumes" the load is at its commanded position. When I bring up the subject(due to the machine having experienced some problem)all I hear is " it's fine " or "it's been working like that for a while now". I always try to have feedback for each actuator in every position that it will be commanded to go.

I think it was a guy named Petri who described it this way..." Action..(work to be performed).....Transition..(verification that work was performed)... Action.. you get the idea.

Great thread GIT.(I like to think we are all G.I.T.)but I know it ain't so.

Terry,

Apparently you had taken this in the wrong way... I am not looking for a "short cut"..if that was the case then I would hire a programmer to come in here and do it all.

I am a very good trouble shooter, I put forth the effort and get the equipment running, when it comes to AB or Siemens I can follow the logic do my job.

That being said when "I bit the Bullet" and started writing my own programs (to save the company money) I started looking for better ways of doing things (trying to better myself, not full of myself like you can be sometimes)

I think that this is the reason this site was developed, for people to try and better their self

I "put fourth the effort" every week in the 80+hrs that I do.

If it was a "short-cut" that I was looking for then I would post the program, then tell someone to finish it.

"Cutting the time down" has nothing to do with "short cuts". I get paid very well (better then most) and I feel that I should be productive as such

geniusintraining said:

(thanks for taking the time Terry that was very good),

Click to expand...

Do you have any clue why I was thanking you?, did I take a short cut in reading you post?, I was thanking you for taking the time to show others and myself.

Sometimes Terry you can be a ***


Thanks Peter, Mark and Pierre at leased someone got it

Programming

First rule of good programming, know the machine or process very well. Find out all you can and make notes. (a short pencil is better than a long memory). It is the economy of code that shows a good understanding of what is happening. Second rule, make sure you test indexed and indirect addressing to make sure that your code is not going to fault the processor. Third is use comments and descriptions to explain the subroutine in detail. I have seen many times there are many ways to do a project and end up with the same result. If you ask 10 programmers to do a project you will have 10 different programs. People think differently, have different experiences and solve problems in different ways. Making hard copy notes about what you are doing helps. If you are interupted you can get your train of thought back reading the notes. Just dont forget to have fun. If you hate programming you wont last long do it.

stasis said:

...clarity comes from understanding structure, not structure in itself...

Click to expand...

Before he starts in da coding zone, he has nothing. Whats is the structure of nothing? How can he have a clear hunderstanding of the structure when it does not exist?.

I hope we are not getting into semantics here, like the egg or the chicken, which one came first?

All of the above are good things to keep in mind, but one thing I feel is left out. Consistency is a great thing, and can also be considered a shortcut. Every program I write has certain parts that are the same in structure. For example, there have been many examples of toggle logic on this website. I personally have a favorite of my own, and have a copy of it stored on our network in all the different types of files we have in plant. (RSLogix5, 500, and 5000, as well as TI 505 Workshop). When I need a toggle, it's a quick copy and paste into my developement project, and all I need to do is assign the correct tags or addresses. Saves me some thought, and when you do this with several parts to a program, can save you a lot of time. I'd like to think that the techs doing the troubleshooting here also appreciate the consistency of the code as well from one area of the plant to another.

Terry Woods "Following short-cuts are nothing more than being short-sighted".

I see nothing wrong with short-cuts as long as you understand the process of how you got there. Isn't steamlining a process a short-cut. Isn't automation a short-cut. I think you are confusing working smarter with being lazy.

Many students come here asking for help. Some do try to use a short-cut and get us to do their work. We all know what type of response that gets. Others post their code, show the effort they put into it and then ask for our help. Are we wrong in advising them or should we just ignore them and let them learn in the school of hard knocks.

geniusintraining has started this thread with the interest of finding out better ways of doing things. Drawing on the knowledge of those who came before is the way we learn.

1.) I agree with PeterW. Take the entire process and break it down into smaller, easier to manage, pieces.
2.) Always start with the output and work "backwards" through the required inputs to make the condidtion true. Using K-Maps are priceless here, IMHO.
3.) Shortcuts, In my opinion" are the clever use of, say, indirect addressing to reduce the amount of code for duplicated control. These are usually PLC dependent and each brand of PLC has their own ways of creating "clever" shortcuts. However, if you have a firm understanding of doing it the "long" way, the "shortcuts" will present themselves naturally, in time. Just don't forget how to do it the "long" way because at least this will work across all PLC brands.
4.) K.I.S.S. - Keep It Simple Stupid. Don't over complicate things.
5.) My personal credo. "It's easy to program a machine to get it to do what it's supposed to do. The real challenge is to program a machine to NOT do what it's NOT supposed to do". ie - SAFETY!, ALARM conditions and what happens if the operator does "this" or "that" which was never taken into consideration in the beginning. You'll find operators can be very "crafty" in how they manage to get a machine to do something it was never intended to do.
6.) Learn from your mistakes. Make one ONCE, but never again.
7.) Listen to these guys here. They have some great ideas and different points of view. Always a good resource for information.
- Tony

Programming has a lot in common with painting. Preparation is vital. The more information you gather about the process before fingers start dancing, the better off you will be.



Here are a few tips that will pay off in the long run:



Look at as many programs as possible. This way you will see what works, what works well, and what does not work. I have had the opportunity to work with dozens of other programmers work. I always seem to pick up something from each and every program I study. This site is an excellent source for that.



Understand the building blocks of machinery. If you have not done so, take a physics class, and take it seriously. Learn hydraulics, pneumatics, steam, and mechanics, then start looking at the wonderful electrical/electronic toys we have available.



Take a math class or three. I have always believed that math, more than any other study, teaches one to think. Push your limits with math. Even Einstien did.



Experience pays dividends with machinery. The more machines you work with, the better you will be able to control them.



Listen, listen, listen. Everyone on a project is a source of information for a programmer. I can't tell you how many times I have experienced a simple softly spoken comment that proved very important in making a machine function properly.



Listen, but make sure that when you start, you are in control of the coding. After preparation, it is your turn to shine. Don't get distracted by petty arguments. Go through with the plan you developed in preparation, then after you have a functioning machine, make improvements. Getting distracted can wreck a project. During this process documentation is vital. Keep notes, draw sketches. Document everything, specially your code.



Oh yeah, never let them know how much fun you are having.

Pierre said:

I hope we are not getting into semantics here, like the egg or the chicken, which one came first?

Click to expand...

nah, not semantics. Just pointing out that without understanding the basic building blocks of 'structure' (how to code, logic functions, automation in general) , the structure itself is moot. You should try explaining PID loops to a welder sometimes

and to genius, you learn speed from repetition, alternative solutions from everyone, professional work habits from professionals, and how to pass the buck from management.