I've received another e-mail through the forum. Geoff Robertson wrote me:
Well Geoff, first of all let me emphasize again, as I did on other occasions like this one, that it is under any circumstance best of all to post this kind of questions on the forum and not direct it at any one of the members personally. I'm only a small fish in the pond. Yes, I know some PLC (sorry iknowsomeplc, not intended to steal away your username ), as so many of my highly appreciated colleagues do. Yes, I've given answers to various questions, again as so many of my esteemed colleagues here also did. And no I don't know more than the numerous people here who try to help others with their questions about PLC's and who I think of as friends.
Our (and not my) strength is in our numbers. If you address your questions to us all, you're bound to get a better, quicker and more complete answer.
Now regarding your question: "Are there standards in how one lays out ladder logic or are we at the mercy of the style of the programmer?"
Well, I for one never intended for a user of the programs I wrote to be "at my mercy" as I'm sure most of us here don't. For me it was always one of the most important things that any service technician should be able to read the programs I write. In this view your remark "I've seen pages and pages of logic that could have easily been reduced to one page of logic and accomplish the same thing." should be read with caution. I've seen programs written in the most compact way possible, but to understand what the darn thing did took me hours, which could easily be filled with more fulfilling work. Remember: a program is written once but serviced numerous times over the lifespan of the machine. Imagine you even don't understand a program you've written yourself only a few years agoo, simply because you didn't document enough and you slimmed it down to minimal size without taking readability into account.
I always try to teach my trainees to write readable, well documented programs. To ensure the presence of structure in these programs I teach them to use structured design techniques such as flowcharts or Nassi-Schneidermann charts for calculations and dynamic state diagrams or sequential control charts for sequential programming.
But this is only my opinion in this. I'm sure everyone else here has strong feelings about this topic. So, friends, please feel free to discuss this topic further.
Kind regards,
Greetings.
Are there standards in how one lays out ladder logic or are we at the mercy of the style of the programmer? it seems to me there are many different ways to accomplish the same task. I've seen pages and pages of logic that could have easily been reduced to one page of logic and accomplish the same thing. any info regarding this would be helpful.
Thanx,
Geoff.
Well Geoff, first of all let me emphasize again, as I did on other occasions like this one, that it is under any circumstance best of all to post this kind of questions on the forum and not direct it at any one of the members personally. I'm only a small fish in the pond. Yes, I know some PLC (sorry iknowsomeplc, not intended to steal away your username ), as so many of my highly appreciated colleagues do. Yes, I've given answers to various questions, again as so many of my esteemed colleagues here also did. And no I don't know more than the numerous people here who try to help others with their questions about PLC's and who I think of as friends.
Our (and not my) strength is in our numbers. If you address your questions to us all, you're bound to get a better, quicker and more complete answer.
Now regarding your question: "Are there standards in how one lays out ladder logic or are we at the mercy of the style of the programmer?"
Well, I for one never intended for a user of the programs I wrote to be "at my mercy" as I'm sure most of us here don't. For me it was always one of the most important things that any service technician should be able to read the programs I write. In this view your remark "I've seen pages and pages of logic that could have easily been reduced to one page of logic and accomplish the same thing." should be read with caution. I've seen programs written in the most compact way possible, but to understand what the darn thing did took me hours, which could easily be filled with more fulfilling work. Remember: a program is written once but serviced numerous times over the lifespan of the machine. Imagine you even don't understand a program you've written yourself only a few years agoo, simply because you didn't document enough and you slimmed it down to minimal size without taking readability into account.
I always try to teach my trainees to write readable, well documented programs. To ensure the presence of structure in these programs I teach them to use structured design techniques such as flowcharts or Nassi-Schneidermann charts for calculations and dynamic state diagrams or sequential control charts for sequential programming.
But this is only my opinion in this. I'm sure everyone else here has strong feelings about this topic. So, friends, please feel free to discuss this topic further.
Kind regards,