theColonel26
Lifetime Supporting Member
So Let continue this because it was shaping up to be a lot of fun. It was High Jacking the other thread so lets continue it here.
Engineers Vs. "Joe Maintenance"
- Thread starter theColonel26
- Start date
Jasondelane
Lifetime Supporting Member
As a technician and plant worker, writing code that is easy for me to understand is nice and all, but writing code that is functional, efficient, and complete is what I like to see most.
It's my job to increase my working knowledge to understand the code that the professional integrator writes. It's up to my management to make sure I'm trained well by the equipment manufacturer to understand the code, and to hire manufacturers and integrators that are willing to either support their code or train me to be able to troubleshoot it.
There are HUGE differences in the code of a small integrator that makes his logic easy to understand and troubleshoot, and the code of a billion dollar OEM that spends a ton of money on engineers and support personnel (and provides 24/7 service plans).
It's my job to increase my working knowledge to understand the code that the professional integrator writes. It's up to my management to make sure I'm trained well by the equipment manufacturer to understand the code, and to hire manufacturers and integrators that are willing to either support their code or train me to be able to troubleshoot it.
There are HUGE differences in the code of a small integrator that makes his logic easy to understand and troubleshoot, and the code of a billion dollar OEM that spends a ton of money on engineers and support personnel (and provides 24/7 service plans).
theColonel26
Lifetime Supporting Member
OP
Because machine states are best written in truths. LADDER is a declarative language. It's greater for this. That not even starting to get in to all the issues you have to deal with if you are trying to run soft-realtime code on a full OS, and make it reliable.
Using DRY and SOC techniques just makes it better, my reducing copy/paste human error when manually copying logic and also making code more flexable and more reusable.
ST is usually written in a declarative way, but that's not really it's main purpose. It's strength is to be used in an imperative (Procedural) manner. For example it is best suited for doing math and doing memory, program control operations, and iterating over arrays or other addresses. It's easier to write these types of things in ST.
Like Bazook7777 says I/O status pages on HMIs and I/0 descriptions are meant to help maintenance quickly know what is supposed to be happening so that can trouble shoot and fix the problem.
Pretty much any type of set point in a PLC program should be configurable from the HMI.
If a problem requires Program changes, then it's time for some one to call in PLC Programmer.
In the same vain as what busarider29 says, good techniques can be learned by pretty much anyone, especially professional programmers that have the constant exposure. The problem is that they simply don't want to learn, it's not that they can't.
The only thing that makes them stupid is that they choose not to try. It's willful ignorance.
Wow you're setting the bar really high there.
school grades: Don't matter, as long as I don't fail the class. D-, that's the same as an A+.
Parent: As long as my kids don't die until I can kick them out of the house. That's all that matters
Let me throw this in the mix.
The evolution of industry is at a stage where the lines between PLC/PC/uC/uP are blurred. You will find that IT and OT are crossing paths more and this is only the beginning. Every buzzword I cringe at (Industry 4.0, Cloud, AR, VR & Digitalisation) brings with it changing capability in industrial devices. Arguments over ladder and structured text seem moot when you can operate your machine using augmented reality from a cloud based server. At some point the people questioning the skill-set of others' will themselves have their skill-set questioned.
There is a time and place for everything.
The evolution of industry is at a stage where the lines between PLC/PC/uC/uP are blurred. You will find that IT and OT are crossing paths more and this is only the beginning. Every buzzword I cringe at (Industry 4.0, Cloud, AR, VR & Digitalisation) brings with it changing capability in industrial devices. Arguments over ladder and structured text seem moot when you can operate your machine using augmented reality from a cloud based server. At some point the people questioning the skill-set of others' will themselves have their skill-set questioned.
There is a time and place for everything.
Just because I'm a 3rd shift, knuckle dragging, coffee swilling Bubba does not give me the right to be ignorant. But please remember, there zero training dollars available, and YouTube can only take me so far.
Keeping that in mind, I have no problem with code being written in whatever language the programmer chooses. I have no problem with it being written in a manner that I do not understand. I also believe it is my responsibility to maintain a high level of knowledge and understanding of current programming practices.
You might also want to keep in mind that it is 9:45 PM local time, and my day is just starting. If the machine you programmed using the most advanced methods and techniques fails to run correctly at 1:00 AM, I have no problem giving you a call to ask why. I will also call you at 2:00 AM, 3:00 AM, and a couple more times before I call it a day at 5:00 AM. The next day, you can probably expect a call from my very unhappy boss to your boss letting them know that he is very unhappy with your machine, and will not be buying another machine from your company again unless:
1) You modify the current machine so that it doesn't sit idle all night because Bubba is not as knowledgeable as you are in regards to advanced programming languages and methods.
2) You guarantee that all future machine will be serviceable by the staff we have, not the staff you wish we had.
To be honest however, #2 is likely a moot point. Once the current machine is modified to our liking, they still won't buy another one from you. There are plenty of equipment builders out there that are more than happy to build a machine that functions as intended, and can also be serviced by the people we have.
You can make of this whatever you choose. For me I'm going to start a fresh pot, and go hide in my cave until I'm forced to emerge because some machine or another needs to be whacked with a hammer.
Bubba.
Keeping that in mind, I have no problem with code being written in whatever language the programmer chooses. I have no problem with it being written in a manner that I do not understand. I also believe it is my responsibility to maintain a high level of knowledge and understanding of current programming practices.
You might also want to keep in mind that it is 9:45 PM local time, and my day is just starting. If the machine you programmed using the most advanced methods and techniques fails to run correctly at 1:00 AM, I have no problem giving you a call to ask why. I will also call you at 2:00 AM, 3:00 AM, and a couple more times before I call it a day at 5:00 AM. The next day, you can probably expect a call from my very unhappy boss to your boss letting them know that he is very unhappy with your machine, and will not be buying another machine from your company again unless:
1) You modify the current machine so that it doesn't sit idle all night because Bubba is not as knowledgeable as you are in regards to advanced programming languages and methods.
2) You guarantee that all future machine will be serviceable by the staff we have, not the staff you wish we had.
To be honest however, #2 is likely a moot point. Once the current machine is modified to our liking, they still won't buy another one from you. There are plenty of equipment builders out there that are more than happy to build a machine that functions as intended, and can also be serviced by the people we have.
You can make of this whatever you choose. For me I'm going to start a fresh pot, and go hide in my cave until I'm forced to emerge because some machine or another needs to be whacked with a hammer.
Bubba.
janner_10
Lifetime Supporting Member
There is always an 'across the pond' difference in these sort of threads on the countless times they raise their heads.
In the states it seems the consensus to write your code so the even the canteen staff can understand.
Whilst in Europe, it rarely, if ever gets mentioned, because good luck getting code out of OEMs let alone changing it.
To us, it mostly seems weird that Bubba is considered, I guess the reverse is true, you find it weird he isn't. It's like discussing politics in the pub at 10pm on a Saturday night, nobody is going to agree!
In the states it seems the consensus to write your code so the even the canteen staff can understand.
Whilst in Europe, it rarely, if ever gets mentioned, because good luck getting code out of OEMs let alone changing it.
To us, it mostly seems weird that Bubba is considered, I guess the reverse is true, you find it weird he isn't. It's like discussing politics in the pub at 10pm on a Saturday night, nobody is going to agree!
cardosocea
Member
I wonder how maintenance technicians dealing with DCS systems can troubleshoot things without having to go inside every routine... most if not all are developed precisely as theColonel is saying and people in these industries troubleshoot it as well even though there is only one implementation for a valve logic rather than for how many valves are in the plant.
I'm in the process industry and was actually told to cease chasing the implementation of a DCS system (I was looking between PlantPAX and PCS7) because the logic is very critical and must remain the same even though we're moving from PLC5 to S7-1500's.
Even when trying to sort of meet half way and use a dedicated library for the process equipment we have in the plant (mostly valves and motors), people look as if I'm joking and it's not good policy.
Modular code works and is easier to troubleshoot than files and files of ladder code.
I'm in the process industry and was actually told to cease chasing the implementation of a DCS system (I was looking between PlantPAX and PCS7) because the logic is very critical and must remain the same even though we're moving from PLC5 to S7-1500's.
Even when trying to sort of meet half way and use a dedicated library for the process equipment we have in the plant (mostly valves and motors), people look as if I'm joking and it's not good policy.
Modular code works and is easier to troubleshoot than files and files of ladder code.
geniusintraining
Lifetime Supporting Member + Moderator
Yep this has been beaten to death over the past years.... keep in mind that you are writing the program for someone else and they are paying you to do it so yes you should keep them in mind when writing the program.
"Just because you can doesn't mean you should"
Why over complicate a program makes no sense to me, should it be longer? if the customer is paying you to make it so bubba can read it easier then it should be done as such, if they want a working program and dont care then make it how you want but this is a conversation that you need to have with the end user, they are buying the program and have to maintain it.
"Just because you can doesn't mean you should"
Why over complicate a program makes no sense to me, should it be longer? if the customer is paying you to make it so bubba can read it easier then it should be done as such, if they want a working program and dont care then make it how you want but this is a conversation that you need to have with the end user, they are buying the program and have to maintain it.
It depends entirely on the customer.
Most of the time, I’m writing programs for someone else. That means I follow their standards and requirements. They pay me to write the initial program and do the runoff, but they handle any additional features or updates.
When I’m not writing to a standard, I try to make it completely in ladder. An industrial program, when done well, should look like an 8 year old wrote it IMO. This is for two reasons:
1. I want to make it easy to understand and be able to add/subtract from it when I get called out on a job that is 3 years old and I remember nothing about.
2. I don’t want to get called out at all if I can avoid it. This might go counter to some people’s arguments. Some people intentionally make the program difficult so they get called out for repeat business. I don’t operate that way; I like to end my side of the project so I can move on to the next one. So if the maintenance team is comfortable modifying the program, more power to them!
Most of the time, I’m writing programs for someone else. That means I follow their standards and requirements. They pay me to write the initial program and do the runoff, but they handle any additional features or updates.
When I’m not writing to a standard, I try to make it completely in ladder. An industrial program, when done well, should look like an 8 year old wrote it IMO. This is for two reasons:
1. I want to make it easy to understand and be able to add/subtract from it when I get called out on a job that is 3 years old and I remember nothing about.
2. I don’t want to get called out at all if I can avoid it. This might go counter to some people’s arguments. Some people intentionally make the program difficult so they get called out for repeat business. I don’t operate that way; I like to end my side of the project so I can move on to the next one. So if the maintenance team is comfortable modifying the program, more power to them!
Well... Look at the pics below, I wrote the same little bit of logic in GXWorks for ST and FBD (Did not bother with ladder as just as easy as FDB).
A number of points come to light, 1. It took longer to write the code in ST (Note: I am pretty fluent as I also write programs in other higher level languages).
2. The compile result shows smaller code in FDB/Ladder so more efficient as the IF statement without the else will set the output when the input logic is true but will not reset it so extra logic is required to be honest this is probably the equivalent of a set/reset.
In ladder as a graphical interface for monitoring the way the brain interprets pictures is quicker (well in my case) so that your brain follows the flow easier than in ST. This was obviously in Mitsubishi so I know ST has to be compiled into what we call STL so in effect the machine type code is run in the interpreter in the PLC in the same manner. It makes sense as why would a PLC have more than one type of interpreter to run the code. I cannot vouch for how other PLC manufacturers compile their code although I have a number of others installed I have not installed the licences yet or indeed if you can look at the code generated. So even though I like ST being a programmer in various other high level languages I think for the purpose of PLC control & maintenance graphical is best. One other point, I do not believe there are any instructions in ST that cannot be done in ladder so I do not think that ST is any better function wise.
On a number of occasions, I have worked alongside programmers writing code in high level languages and many of them remarked "I don't understand this ladder or FBD thing", after giving them a quick demo almost all of them remarked how good it was and wished they had the same functionality.
To me ST is like going back to the old days with a handheld programmer having to think about ANDLD, ORLD etc.
My rant for the day
A number of points come to light, 1. It took longer to write the code in ST (Note: I am pretty fluent as I also write programs in other higher level languages).
2. The compile result shows smaller code in FDB/Ladder so more efficient as the IF statement without the else will set the output when the input logic is true but will not reset it so extra logic is required to be honest this is probably the equivalent of a set/reset.
In ladder as a graphical interface for monitoring the way the brain interprets pictures is quicker (well in my case) so that your brain follows the flow easier than in ST. This was obviously in Mitsubishi so I know ST has to be compiled into what we call STL so in effect the machine type code is run in the interpreter in the PLC in the same manner. It makes sense as why would a PLC have more than one type of interpreter to run the code. I cannot vouch for how other PLC manufacturers compile their code although I have a number of others installed I have not installed the licences yet or indeed if you can look at the code generated. So even though I like ST being a programmer in various other high level languages I think for the purpose of PLC control & maintenance graphical is best. One other point, I do not believe there are any instructions in ST that cannot be done in ladder so I do not think that ST is any better function wise.
On a number of occasions, I have worked alongside programmers writing code in high level languages and many of them remarked "I don't understand this ladder or FBD thing", after giving them a quick demo almost all of them remarked how good it was and wished they had the same functionality.
To me ST is like going back to the old days with a handheld programmer having to think about ANDLD, ORLD etc.
My rant for the day
Output1 := LimitSW1 AND LimitSW2;
or you can write it like this, without choosing the longest possible way...
EDIT> I really would like to see ladder seting of hundreds IOlink I/Os over CC-link IE distributed on Balluff CC-link masters...
Last edited:
Ha Ha! I realised it after I posted it Doh!. however, This was a simple example of coding in text versus drag & drop ladder, do an experiment on combination ladder i.e. three or four AND rungs ORed containing say 6 contacts on each rung some N/O N/C and some with OR's around them equaling a bit in ST & ladder see which is quicker & easier to monitor, and of course check your logic is correct.
Edit: I was weaned on ladder but ever since FBD I have been using that and rarely use ladder, but I still maintain that for writing it ladder takes less effort and the brain responds better to green flow lines when monitoring without having to process AND OR etc.
Edit: I was weaned on ladder but ever since FBD I have been using that and rarely use ladder, but I still maintain that for writing it ladder takes less effort and the brain responds better to green flow lines when monitoring without having to process AND OR etc.
Last edited:
saultgeorge
Lifetime Supporting Member
This is exactly what I've been accustomed to doing. The integrators I've worked for have given me a task to write a program for a machine/process my company has either sold to the customer, or a machine/tool/equipment builder that has contracted us to do the software. I've had several projects like this; one lasted 2 years because of changes and mechanical issues. I write in whatever language the customer specs out. My boss tells the customer that perhaps ST or some other platform besides ladder is good, but in the end the customer gets what they want. I always try to keep it simple, organized and well commented with plenty of descriptors. And, I haven't gotten any 3 am calls on programs I've written because the plant people (sounds like a science fiction movie) ARE able to understand, troubleshoot and modify my programs on their own.
I agree Rson, I did a lot of work for a major food company, they had an ex Siemens engineer writing standard plc software as a wrapper for suppliers to use I cannot go into it's functionality but basically they provided the blocks and you interfaced with them with the core control code. The idea was a good one as far as I was concerned they supplied the engines and we wrote the code that made it all work together. The only problem was that there was little memory left to fit your code in (going back to the old days) so a bit of slick coding was in order, We as a company would always comply with the customer's wishes, however, I looked into many other suppliers code and not one of them had used it. In some cases they would drop the blocks in and only call the communication blocks that sent information up to the higher-level equipment (Scada), they would manipulate the data in their own way so the coms block would send what the higher-level system expected. this is a little hard to explain but as far as I know, there was no other OEM that had complied with the standard use of the blocks, I admit at first glance the standard blocks of code could be mind-boggling to understand and very little documentation apart from what was in the code. I found it very stable and saved me a lot of time creating my own engines.
boardmaker
Member
Let's examine this argument from this viewpoint:
Why would a programmer not write an easier to read/understand code that may possibly have more rungs and most likely not be as elegant visually or logically as long as it does the same job and possibly prevents future service calls.
Pretty sure that's a run on sentence but you get the point.
I laughed at willxfmr's post because it is 100% true. You will get a call every 1/2 hr.
Why would a programmer not write an easier to read/understand code that may possibly have more rungs and most likely not be as elegant visually or logically as long as it does the same job and possibly prevents future service calls.
Pretty sure that's a run on sentence but you get the point.
I laughed at willxfmr's post because it is 100% true. You will get a call every 1/2 hr.
Similar Topics
In my car I have 2 cigarette lighter outlets.
Dashboard outlet has a 25A fuse in the engine compartment.
Cargo area outlet has a 30A fuse next to...
A recent thread asked how people describe what they do and that is always a difficult thing to explain to people that have little or no...
Hi all, i tried to created a button which is visible only when the user "Engineer" is logged.
First, i created a macro with the following...
Best wishes to all of my fellow engineers! :lolis:
Hi
I am second year mechanical engineering student interested in PLC programming as a career choice.
Looking at job advertisements it looks like...
