LAD, FBD, STL, and other?

[ToolGuyFred]

Bubba ain't stupid, we just don't program PLC's all day every day. Some of the things we might need to do on a daily basis include;

1. Troubleshoot faulty limit switch.
2. Fix hydraulic proportional valve.
3. Replace blown up VFD
4. Wire 2MVA transformer.
5. Unjamb paper out of secretaries printer.
6. Change bearings in 100HP motor
7. Fix plant managers excel spreadsheet/monthly report.
8. Fix the A/C for the office.
9. Weld a broken piece of something back together.
10. Make a new X in the lathe.
11. Tune a motion controller.

To the poster that said "we'll find a different Bubba". I can do all of these things, can you? Should we hire another 15 people who are experts at all these things and then go out of business because costs are too high?

Ho Yuss.

Sounds familiar. I have worked the last 20 or so years for machine builders, mostly writing PLC software. I can follow STL as well as the next key-tapper but when you're looking at someone else's code, nothing beats ladder. This is the same reason one previous employer uses Pascal and Delphi for PC applications. C++ is fine when written by an expert wanting someone else to be able to follow his code - BUT - C++ can be as obtuse as you like. Pascal is just easier to follow. I don't want clever-clever. Give me serviceable every time.

 

[S7Guy]

To the poster that said "we'll find a different Bubba". I can do all of these things, can you?

Yes. I can weld, run a lathe, run a milling machine, repair heavy equipment, I have 10000 hours experince as an industrial electrician, worked on high voltage applications in the military, and studied (and used in real life) hydraulic and pneumatic system design. In addition to PLCs, I do C, VB, CNC, SQLServer, and whatever else I need to do to get the job done. I have never taken a computer course in my life.

And that's what I don't get. I need to know all of these things to be able to continue to find new business (I work for myself). And I run into plant techs all of the time who need to have the same skills, and most of them have no problem whatsoever with learning new approaches and skill sets. Maybe it's a regional thing, because I never even heard the term "Bubba" outside of this forum (with the exception of Dukes Of Hazzard and Hee Haw). I can take anyone with a basic understandiing of logic and show them how to interpret STL, build a basic SQL query, or understand a CNC loop. I don't think self-proclaimed "bubbas" should be speaking for others who have no problem with tasks like this.

 

[ToolGuyFred]

I can take anyone with a basic understandiing of logic and show them how to interpret STL, build a basic SQL query, or understand a CNC loop. I don't think self-proclaimed "bubbas" should be speaking for others who have no problem with tasks like this.

But if you have to train a dozen electricians (in between their breakdown calls) spread over seven days and three shifts, some of whom won't be interested in learning anything new and software anyway - THEN you'll see why STL for STL's sake is a no-no.

I have inherited several machines here written purely in STL. The electricians won't touch them, they call for me (day or night, including weekends). That shouldn't be necessary. The person who accepted this kit should be slowly tortured in front of a warmly applauding audience.

S7Guy - if you had to train all these people at no extra charge on one of your projects - would you still insist on STL?

 

[S7Guy]

But if you have to train a dozen electricians (in between their breakdown calls) spread over seven days and three shifts, some of whom won't be interested in learning anything new and software anyway - THEN you'll see why STL for STL's sake is a no-no.

I don't write STL for STL's sake.

I have inherited several machines here written purely in STL. The electricians won't touch them, they call for me (day or night, including weekends). That shouldn't be necessary. The person who accepted this kit should be slowly tortured in front of a warmly applauding audience.

I supply HMIs that provide tons of diagnostic data. They can do all of the troubleshooting they would ever need to do that way. They are welcome to the source code (some ask for it, and some don't), but if they have to pour through code to fix a problem, then I've failed them. I'm glad to say though that that hasn't been an issue.

S7Guy - if you had to train all these people at no extra charge on one of your projects - would you still insist on STL?

Yes. And actually, I always take the time to go through the code with anyone who is interested. Why wouldn't I do that? As you said yourself above- "some of whom won't be interested in learning anything new and software anyway "-, a lot of people aren't going to leave the break room anyway. But there will always be two or three that are right over my shoulder, and I don't mind at all.

 

[ToolGuyFred]

I don't write STL for STL's sake.

Pleased to hear it. As I said above, I don't have a problem if its the right tool for the job. Your earlier posting implied that you use it for everything because you think its better for everything. I don't agree and neither do most of the electricians I meet.

I supply HMIs that provide tons of diagnostic data. They can do all of the troubleshooting they would ever need to do that way. They are welcome to the source code (some ask for it, and some don't), but if they have to pour through code to fix a problem, then I've failed them. I'm glad to say though that that hasn't been an issue.

Maybe not now but perhaps in some years time when you're not around...

And actually, I always take the time to go through the code with anyone who is interested. Why wouldn't I do that?.

Because you'd have to come in six times at peculiar hours, including weekends - and then you still might not see the people you need to see because they've been called out to breakdowns.

But there will always be two or three that are right over my shoulder, and I don't mind at all.

Then you are fortunate to have customers prepared to release staff to watch you, you really are.

 

[geniusintraining]

There is a big difference between writing a program (I can do this) and writing a program the correct way...

From reading S7Guy’s post over the years, it is obvious that he can write one that all of us bubba’s would love to have (STL or LAD), with a HMI you can tell bubba what has failed and what they need to fix. This way of programming, very rarely should you have to go into the program at all that way, unless you are changing the program.


But your programs are the exception, should be the rule and this type of STL programming I have no issues with at all.

The issue I have with STL is the programs that don’t have a HMI or are written poorly, endless loops that do nothing and go no where.

I hate the generic programs, one that is made for 100 machines and just need a little tweaking for machine x or y, these programs have a ton of **** in them for the options of all 100 machines, if the OEM does not go through them and clean them up, then they are a nightmare to troubleshoot.

So you can have a bad program in STL or LAD...

 

[SLC_Integrator]

There is a big difference between writing a program (I can do this) and writing a program the correct way...

From reading S7Guy’s post over the years, it is obvious that he can write one that all of us bubba’s would love to have (STL or LAD), with a HMI you can tell bubba what has failed and what they need to fix.

But your programs are the exception, should be the rule and this type of STL programming I have no issues with at all.

The issue I have with STL is the programs that don’t have a HMI or are written poorly, endless loops that do nothing and go no where.

I hate the generic programs, one that is made for 100 machines and just need a little tweaking for machine x or y, these programs have a ton of **** in them for the options of all 100 machines, if the OEM does not go through them and clean them up, then they are a nightmare to troubleshoot.

So you can have a bad program in STL or LAD...

The generic programs are written to cut costs.
Unfortunately alot of the time end-users dont want to pay to have custom code written for each and every machine/install

We package up systems for various industries and unfortunately thats the way it has to be done to be profitable.

I understand the argument about crappy STL code, but to be fair isnt a badly written program a nightmare no matter WHAT language its written in?

I have seen some HORRIBLE ladder code, especially in 984LL.

Maybe I should screenshot some old code from our 'black museum' and give out a gold star to whoever figures it out first

 

[ToolGuyFred]

There is a big difference between writing a program (I can do this) and writing a program the correct way...

From reading S7Guy’s post over the years, it is obvious that he can write one that all of us bubba’s would love to have (STL or LAD), with a HMI you can tell bubba what has failed and what they need to fix. This way of programming, very rarely should you have to go into the program at all that way, unless you are changing the program.


But your programs are the exception, should be the rule and this type of STL programming I have no issues with at all.

The issue I have with STL is the programs that don’t have a HMI or are written poorly, endless loops that do nothing and go no where.

I'm sure S7Guy is a top programmer. STL is to PLCs what assembler is to a computer. I have seen some brilliant assembler code in my time, properly structured and commented, easy to understand and a joy to work with. I have also seen code virtually impossible to understand without much time-consuming study which has blatantly been de-bugged into existance. Most of the PLC code I find is mediocre, some is dire and some is like programming art. The point I am trying to make is that poor and mediocre code from untalented programmers (unfortunately the majority of what I see) is easier to understand/monitor/modify when written in ladder than STL.

 

[SLC_Integrator]

The biggest challenge when writing code I guess is the transition from 'theory' to 'working'.

What can initially be beautiful, well commented and structured code can turn into a huge mess when its been hacked around for a couple of days during startup.
The blame here cant always be laid at the programmers door though.
How many times have you got on site to find the customer wants a few 'little extras' that totally mess up the original idea of how the machine/plant was supposed to work?

Its a case of the programmer being bothered to go back once its all tested and comissioned and 'cleaning up' the code.
This may be as simple as re-commenting or as intense as rehashing entire subroutines or pages of code to make them more fluid in how things solve.

Of course the customer doesnt always want to pay for this extra work.......

 

[geniusintraining]

The generic programs are written to cut costs.
Unfortunately alot of the time end-users dont want to pay to have custom code written for each and every machine/install

We package up systems for various industries and unfortunately thats the way it has to be done to be profitable.

I understand that but you can delete the **** a lot easier then I.

If I buy a machine from you I expect it to be reliable and the best that it can be. It does not have to be perfect but at least try.

I have added code to my programs to troubleshoot or start up or copy one from another machine, but I have also gone through and cleaned it up.

It's a matter of pride and customer service.

I sold a cable last week and lost 10 dollars, was that bad business? no its called customer service (saving face), I was out of stock and it was ordered... I would rather loose a few bucks and have a happy customers, I hope they will come back and buy more someday.

I am not saying that you SLC_Integrator don't take pride in your work but the company that you work for needs to look at more then just the 'all mighty dollar' and look at return customers are they happy? could they be happier?

 

[SLC_Integrator]

The problem with removing code completely is what if down the road the customer wants to add in some of the 'optional extras' ?


Theres probably 60 networks worth of plunger control or choke control.
Should I delete it from each of the 120 + packages we do each quarter then add it back in each time a customer wants it?

Its just NOT feasible.

From a customers point of view, if they didnt want the plunger package and the logic has a 'FALSE' always off contact in front of it then he just ingores it.

Its not that hard.......

In fact weve NEVER had a customer complain about 'too much code' in one of our programs.

As for the 'almighty dollar' theres customer service then theres being profitable.
Theres plenty (about 50%) of businesses go under, I'm sure some for being overly-charitable.
With some customers, you give them an inch and they take a mile.

 

[geniusintraining]

As for the 'almighty dollar' theres customer service then theres being profitable.
Theres plenty (about 50%) of businesses go under, I'm sure some for being overly-charitable.
With some customers, you give them an inch and they take a mile.

A lot of them fail because of their reputation, it kills them in the end

I don’t have a issue of asking for a inch and taking a mile… but I will give you a PO for that mile. I do it all the time “hey while you are here...”

It’s all about fair business, I ask something of you and I pay for your services. But give me something good to work with.

You said it’s not feasible to remove the code? Due to later I might want a up grade, its just as easy to delete the code and re-paste it back in.

 

[SLC_Integrator]

A lot of them fail because of their reputation, it kills them in the end

I don’t have a issue of asking for a inch and taking a mile… but I will give you a PO for that mile. I do it all the time “hey while you are here...”

It’s all about fair business, I ask something of you and I pay for your services. But give me something good to work with.

You said it’s not feasible to remove the code? Due to later I might want a up grade, its just as easy to delete the code and re-paste it back in.

"but I will give you a PO for that mile."

Alot don't. Or wont.


"It’s all about fair business, I ask something of you and I pay for your services. But give me something good to work with."

We do. As I said, we havnt had any complaints about giving the customer too much code.

"You said it’s not feasible to remove the code? Due to later I might want a up grade, its just as easy to delete the code and re-paste it back in."

Your assuming.
What if:
1: The programming software doesnt support cutting and pasting code from one instance to another?
2: The changes can be made offline. maybe the customer only allows online changes and no plant downtime.

 

[RMA]

I hate the generic programs, one that is made for 100 machines and just need a little tweaking for machine x or y, these programs have a ton of **** in them for the options of all 100 machines, if the OEM does not go through them and clean them up, then they are a nightmare to troubleshoot.

Those are the systems I've been working since last Christmas! Working my way in probably took twice as long as it would have had they been tidied up a bit (not necessarily completetly).

As SLC Integrator says there is obviously a cost question involved here. I get the impression the OEM supplier is very lothe to change things significantly and quotes an absurdly high price for those things he doesn't feel inlcined to do.

If that weren't the case, I wouldn't be sitting here waiting for the OEM supplier to finish the installation of a new production line, so I can get started on the line sorting out the remaining faults (including some of the same ones I've found on two other lines, one of which is five years old!) and increasing the throughput of the line by a minimum of 50% and if possible 100%! That it's worth it for the customer to pay me do this all this time (with no end in site this year) says something about what the initial quote must have been like - and there's not just me, another of our guys has been here six months longer doing all the statistical analysis which decide where I do what and when!

 

[Mickey]

We do. As I said, we havnt had any complaints about giving the customer too much code.

You would if I was your customer. I hate code like that, code thats there and not being used or ask for. To me its the ultimate
in confusion.