Engineers Vs. "Joe Maintenance"

Let me clear up what I was saying.

writing plc code that only the programmer can understand is foolish in my opinion.
Maintenance personnel are the ones who ultimately maintain the equipment and keep it running. we had a 1 million dollar machine that no one could troubleshoot because of grafcet programming. I rewrote the entire program, worked with the maintenance programmer and he understood what I did and why. downtime went from 592 hours in a year to 120 hours. this is a documented fact, the plant kept downtime records.

it doesn't matter how much a machine costs, if maintenance cannot trouble shoot the equipment, it's worthless. the machine don't run, management hears about it, the plant manager gives your boss a call, who on turn calls you into his office. that company now has your home phone /cell number and you get calls all hours of the night trying to help.

I have been programming since 1987 and learned on an Omron s6, then learned slc 100/150 and so on. and the one thing that I have learned is that maintenance needs to be able to understand the programming logic. they are your best friend when they understand the program, and your worst enemy when they don't.

my background includes Bs. engineering technology, 2 years industrial maintenance, panel builder, programmer, IS/IT department.

james

Often everyone forgets why we have a job.
WE ARE ONLY THERE TO PUT MONEY IN SOMEONES POCKET! End of story, period!
We do that by designing to be reliable and easily repairable.
Too often I see mechanical designs that are really cool but take forever to repair. Same with programs. REMEMBER that downtime is like bowling, if you miss that spare or strike that opportunity for revenue is gone forever.

#1 James, Arghh. Grafset ...... Like you James, I started in 1982 on Omron S6 C500 and a host of others using a handheld in many cases. In my opinion, ST is almost like going back to STL and I believe maintenance staff deserve a break, they have jobs where they have to be a jack of all trades, do not get the exposure or time to code like programmers and have to get into the mindset of the programmer, not an easy task when the production manager is breathing down your neck. I will say it again and I'm sure that you agree to code a complex boolean expression is easier in graphical (I mean ladder or FBD) than in ST after all what is ST, not much different than Siemens STL. Even they made their function blocks work in ladder after S5, in that instance, it was a step forward. I like the idea of transportable code it can make the programmer's life easier but in my opinion, does not make monitoring any easier unless you can view it in ladder (or maybe you can now on some platforms) I have only done it on Mitsubishi but honestly prefer lad/fbd.
Experience: Electronic design (digital & Analog, programming in Assembler, C C++, pascal & basic.

gas said:

WE ARE ONLY THERE TO PUT MONEY IN SOMEONES POCKET! End of story, period!

Click to expand...

That isn't true. You get paid.

This thread seems to be more about what programming language to use than maintenance vs engineers.

Others above, have got it right. Use the right programming language for the the application. Turning outputs on and off only requires ladder. Motion control applications require much more. We prefer a state machine and ST. The applications are often much more difficult and require a lot of math. In this case ST rules. Whether a maintenance man can understand it is a function of knowing ST but also understanding the math required for the application. One can blame ST but often it is the mathematics that is the real problem.

In our case we still make those french fry machines that scan and remove defects. Most of the code is written in C and there is no way for anybody but use to change it because they couldn't begin to understand the math. However, we do provide a PLC and HMI to allow the users to make simple changes for timing or offsets in position.

Most of my sawmill OEM customers to the same. The applications are getting to be more sophisticated.

Meanwhile the education level is not keeping up with the complexity of the applications that PLCs can now control. I have noticed that the average level of knowledge has increased but there is a huge gap between the low end user/maintenance man and the high end engineers.

I shake my head when I see a thread that has to do with scaling an AtoD or DtoA device or threads that are 700 posts long.

parky said:

after all what is ST, not much different than Siemens STL.

Click to expand...

No disrespect and I honestly believe you are exagerating here, but if you can't see a difference between STL and SCL (in Siemens world), then perhaps you need to brush up a bit more on what PLCs can do and how these are incredibly different.

parky said:

I like the idea of transportable code it can make the programmer's life easier but in my opinion, does not make monitoring any easier unless you can view it in ladder (or maybe you can now on some platforms) I have only done it on Mitsubishi but honestly prefer lad/fbd.

Click to expand...

I think your view of what PLCs can do and are increasingly doing is somewhat limited. Ladder worked and still works great for boolean logic conditions. There is simply no argument on this, I agree.

But if you were to program an algorithm or even a "home" made PID controller inside the PLC (which most are well capable of doing with enough knowledge of what a PLC is), then using a graphical language is both torture and stupidity as there's no way the technician troubleshooting why a machine isn't running is going to look into a block with some complexity. This obviously means the block has to be tested properly before deployment, but it's using the best suited language for the task at hand.

Sadly, in these discussions I think people get a bit fundamentalist and write off anything other than ladder without realising the true potential and best use cases for each.

parky said:

In my opinion, ST is almost like going back to STL

Click to expand...

As mentioned, It's absolutely nothing like it.

janner_10 said:

As mentioned, It's absolutely nothing like it.

Click to expand...

Actually, I was told once by a programmer with years of experience that the only difference between ST and STL was that one had a "L".

Of course I did have the opportunity to get into one of his programs to troubleshoot it later and think my son could have done a better job. (He's a musician, knows nothing about PLC's except what they look like)

Cardosocea, that is nonsense, I cannot think of any instruction in ST that cannot be done in ladder or FBD. I have written programs in LAD/FDB for PID (Before most had in-built blocks), Mathematical equations for temperature versus time to produce what we call cook value often called cook value thermal processing
Temperature-time, cook value ( C 100 = ∑ 10^(( T − 100/33) Δ t ), and pasteurization unit value (PU= ∑ 10^(( T − 60/5.5) Δ t ) profile for RF and steam.
I have also written PID control for rossi catelli In-line Steam core injectors machine control for servo drives used in precision grinding the list is endless.
Until I retired earlier this year, I was heavily involved in projects involving motion drives & process pasteurisation.
Most modern PLC's have an extensive range of in-built mathematical functions for FBD.

I am an engineer with a degree, but I am not best programmer in the world, nor do I pretend to be. If only I could walk on water like the original author of this thread. I have been on vacation, up in my tree stand, had deer walking all over around me, then had to come down and go into work because a system is down and I wrote a program that a programmer could understand, but not the common maint. tech. I guess it's selfish, but I write code so I don't get called off vacation or at 2:00AM. Other people can make fun of my code all they like....has no impact on me. If the system runs efficiently and maint. can troubleshoot without me, THEN I consider my code a success.

I've read through the whole thread. Some of the arguments for and against any one language have the flavor of 'religious' discussions.

What the maintenance people that I have dealt with appear to want, is a quick and easy interface to often-used trouble-shooting information. You can put that on a panelview, in ladder, in FCB, .. not sure how to put that in ST but I'm sure it's possible.

List the inputs to the system, the outputs of the system, any warnings or alarms for out-of-spec inputs. If the equipment stopped, what alarm stopped it. Most of my stuff is digital. And it's usually some input that is not working. Make that easy to figure out.

My programs log a bunch of stuff, have a bunch of timers and counters for my own troubleshooting. It's not easy to follow. But that's hidden in an AOI or a subroutine. Use whatever language makes it easy for you to troubleshoot. If the maintenance person needs to wade through your code and figure out errors in your math or logic .. you're in trouble no matter what language you use.

Make it easy for maintenance to locate problems that they can fix (position switches, level switches, start/stop stations, overloads, failed control transformers) and they will happily ignore everything else.

Background
I am an electrical engineer, with a minor in computer science. I've been programming various PLCs for 30 years. Mostly Rockwell for the past 15

Each language has its pro's & Con's, as the old addage goes 'horses for courses', however regarding making programs simple enough for Bubba to understand, I can't really agree with. If the program and diagnostics are written correctly and efficiently then any troubleshooting should be able to be carried out utilising the information given via the HMI negating any need for PLC connection. More often or not the very act of some maintenance guy who 'knows what he/she is doing' messing about in the program causes more fault than they cure, this said, I do realise that there are some very capable people out there, but in my experience they are few and far between.


Steve

parky said:

Cardosocea, that is nonsense, I cannot think of any instruction in ST that cannot be done in ladder or FBD. I have written programs in LAD/FDB for PID (Before most had in-built blocks), Mathematical equations for temperature versus time to produce what we call cook value often called cook value thermal processing
Temperature-time, cook value ( C 100 = ∑ 10^(( T − 100/33) Δ t ), and pasteurization unit value (PU= ∑ 10^(( T − 60/5.5) Δ t ) profile for RF and steam.
I have also written PID control for rossi catelli In-line Steam core injectors machine control for servo drives used in precision grinding the list is endless.
Until I retired earlier this year, I was heavily involved in projects involving motion drives & process pasteurisation.
Most modern PLC's have an extensive range of in-built mathematical functions for FBD.

Click to expand...

I'm not saying it's impossible. I'm saying it is unbelievably hard to troubleshoot in Ladder whilst being easy in SCL. The same way that troubleshooting boolean logic in SCL is a bit ****.

thingstodo said:

I've read through the whole thread. Some of the arguments for and against any one language have the flavor of 'religious' discussions.

Click to expand...

Agreed.


While everyone is arguing about what programming language they prefer, no one is addressing the quality of the code generated or the interface or how one goes about debugging programs.


Has anybody used Microsoft's Visual Studio? That development environment is very good but it isn't real time. How does one debug a real time system when the inputs, outputs and variables are changing so quickly? Solving this problem is a significant step forward because it can be applied to all programming languages.

I would say that if there was sufficient information displayed on the HMI for a non-programmer to see what was or wasn't on or happening then the code inside the PLC is irrelevant to them.

If anything happening would interfere with the operation of the machine have an alarm display, have screens showing all the relevant IO conditions and machine states.

Show enough information for a maintenance tech to know what sensor, switch or valve to check without having to go online with the PLC. I even do that for myself so I can maybe find the problem before connecting a laptop and going online.

When I first started in maintenance, 11 years ago, the company I worked for didn’t have any software or a laptop to diagnose a problem with a machine. All we had were the wiring schematics.

I am thankful that company didn’t want to keep software, it made me better than the average Joe. Try it sometime.