You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old December 7th, 2017, 01:28 PM   #1
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
OEM "Master" Programmers

Is it just me or does it also drive other Plant PLC guys crazy when a Equipment builders over build PLC programs for new equipment.

This new equipment I've been integrating into our MES system is fairly simple and could of been done well in one program with 8 routines max. The new "master" programmer the OEM has now used 10 programs and about 50 routines. Obviously he has a "template" program he uses for everything but it had too of taken longer for him to set his template up than it would of for him to write this simple program from scratch.

We have bought multiple machines from this vendor over the past years and none of the programs have ever been this over built. Their new programmer must of been showing off to his boss when he wrote this one.

Even their onsite programmer that drew the short straw and had to come in during thanksgiving with us for the install, was struggling to understand why his programmer did what he did. The on site guy called his programmer at one point about another issue and asked him why it was so complicated and the programmer said, "Why are they (me the guy integrating it into our MES system) even in the program? We already tested it, when it was here at the shop." He acted like he had no idea that his system was going to be replacing a system we already had. (Slipped his mind i guess)

The craziest part about this whole thing is that the "master programmer" and OEM supposedly "fully tested" the whole system in their shop before sending it to us. After about two hours of troubleshooting this over grown monster during install, i found two different bugs in his machine state and machine conditions logic that kept half of the conveyors in this "fully tested" system from running.

Sorry for the rant but please don't forget about the plant controls guys that have to maintain these master programs. It may be easier for you to use one template for all the programs you build, but damn its time consuming for us to troubleshoot when its spread out over 50 routines.

I understand your time is money, but my downtime is $100ish/minute when it stops during production and i have to figure out whats wrong with it.
  Reply With Quote
Old December 7th, 2017, 01:44 PM   #2
James Mcquade
Member
United States

James Mcquade is offline
 
Join Date: Oct 2007
Location: Tennessee
Posts: 2,013
I feel your pain.

I would send the oem a bill and explain what happened and a copy of each plc program (the supposedly working machine and your corrected copy) and pdf with the details of where the bugs were found.

I would also request that the programmer never touch another machine you have built.

I had a 4 station gage machine for the same parts with 3 different programs.
my boss got a call from corporate asking why the machine wasn't running and I got the project.

2 weeks later I was told to explain what was the issue.

I sent the 2 programs (supposedly working and my copy), 2 pdf copies, a file comparison, and a word document with 174 program changes I made. He wasn't happy with his programmer and we had massive downtime in the meantime.

I also have a machine that has 255 subroutines which is a generic program, what a mess. I cannot debug it, have to call vendor.

james
  Reply With Quote
Old December 7th, 2017, 02:50 PM   #3
cardosocea
Member
United Kingdom

cardosocea is offline
 
Join Date: Nov 2016
Location: Duxford
Posts: 461
If it is as you say, then it's possibly someone with too much time on their hands or cannot grasp the possibilities for the machine and decided to just type away code.

This being said, I was on the commissioning and installation of a couple of machines that were completely or almost configurable and it was fantastic. A document explained all the setting variables inside each DB and all you had to do was test and go back to check the settings. It had been tested in the office and in the field for plenty of time and bugs were ironed out...

However, the first time I saw it, I had the exact same reaction as you.

The only downside was when a customer bought some add on functionality for quite a bit of money and all I had to do was toggle a couple of bits in the program and it was installed.
  Reply With Quote
Old December 7th, 2017, 02:57 PM   #4
jstolaruk
Member
United States

jstolaruk is offline
 
Join Date: Dec 2004
Location: Detroit, SE Michigan
Posts: 3,051
The "put everything in the PLC program that you will ever need" is popular with builders of standard machine that can come with options. The guy setting up the machine can go in the logic and turn features on and off. Also, if something is field installed, the field service guy only needs to turn on parts of logic.

Even for one-off machines, I also see a similar thing from GM and Ford. They give you a template filled with every FC, FB, UDT, and AOI that you should use and then you're required to delete the stuff you are not. HMIs are handled in a similar fashion.
__________________
"You can live to be a hundred if you give up all the things that make you want to live to be a hundred." Woody Allen
  Reply With Quote
Old December 7th, 2017, 03:23 PM   #5
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
Quote:
Originally Posted by James Mcquade View Post
I feel your pain.

I would send the oem a bill and explain what happened and a copy of each plc program (the supposedly working machine and your corrected copy) and pdf with the details of where the bugs were found.

I would also request that the programmer never touch another machine you have built.

I had a 4 station gage machine for the same parts with 3 different programs.
my boss got a call from corporate asking why the machine wasn't running and I got the project.

2 weeks later I was told to explain what was the issue.

I sent the 2 programs (supposedly working and my copy), 2 pdf copies, a file comparison, and a word document with 174 program changes I made. He wasn't happy with his programmer and we had massive downtime in the meantime.

I also have a machine that has 255 subroutines which is a generic program, what a mess. I cannot debug it, have to call vendor.

james
That's a good idea, this is really the first time that i've had a situation like this, where they blatantly lied about testing the equipment before hand and sent it in with a programmer that couldn't understand the code enough to fix their own mistakes.
  Reply With Quote
Old December 7th, 2017, 03:28 PM   #6
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
Quote:
Originally Posted by cardosocea View Post
If it is as you say, then it's possibly someone with too much time on their hands or cannot grasp the possibilities for the machine and decided to just type away code.

This being said, I was on the commissioning and installation of a couple of machines that were completely or almost configurable and it was fantastic. A document explained all the setting variables inside each DB and all you had to do was test and go back to check the settings. It had been tested in the office and in the field for plenty of time and bugs were ironed out...

However, the first time I saw it, I had the exact same reaction as you.

The only downside was when a customer bought some add on functionality for quite a bit of money and all I had to do was toggle a couple of bits in the program and it was installed.
I don't think they had too much time on their hands, i think they had a nice big robust program and decided to use it to control a very simple process.

Some of our vendors have huge programs with many configurable options and I'm with you it is awesome to install the equipment and then turn on the config bits and all the programming is already done.
  Reply With Quote
Old December 7th, 2017, 03:49 PM   #7
Iner
Member
France

Iner is offline
 
Join Date: Mar 2010
Location: France
Posts: 97
It's very common for standard machines builders to have options in the code wich are checked/unchecked following the end/user real configuration.

It reduces both the cost and the time of development, which are often much more important for end users than the readibility of the code.

Sending someone on site who don't have enough knowledge to start up the machine without calling home is another problem. Very often in standard machines the people sent are versatile, electricians, mecanicians, able to read the code to troubleshoot, also for reducing the cost and the number of people sent. The main programmers are not needed because most bugs have been already eliminated (contrary to special machines which need much more work) It all come down to the price the end users are ready to pay...

As for the cost of downtime..... I couldn't count how many hours I lost at customers plants waiting for a never starting production because of others machine breakdowns, shortage of parts , production guys suddenly deciding to wash their whole plant for several days.... It's a two way traffic
  Reply With Quote
Old December 7th, 2017, 04:44 PM   #8
ASF
Lifetime Supporting Member
Australia

ASF is offline
 
Join Date: Jun 2012
Location: Australia
Posts: 2,374
I've seen the same thing on a freezer we had to integrate to a production line. The PLC in question didn't even handle the refrigeration section - that was done by another PLC. All it controls was the conveyor belt, the evaporators, and the temperature sensors.

The program has 3 tasks, 32 programs, 270 routines, 42 AOI's (the vast majority of which are used only once, defeating the purpose of an AOI), 318 AFI's, and generates around 70 minor faults per second.

We recently discovered a bug in the program where if you don't select a new recipe, after around 1 year of running the PLC will fault.

It's a f***ing freezer. Not a nuclear reactor.
  Reply With Quote
Old December 7th, 2017, 09:54 PM   #9
bill4807
Member
United States

bill4807 is offline
 
Join Date: Mar 2013
Location: michigan
Posts: 55
Putting configurable bits in logic is very popular within the machine tool builder industry. Using visible and hidden parts of logic and parameters for paid for options and such.
Having to work with them everyday on machine tools, I have actually found myself implement them in a small way into my other projects, using standard AB plcs.

But I will admit some of our overseas equipment come over with absolutely every posible way to control some process and it gets quite confusing.
In these situations it easier for me to just rewrite certain sections more simply.
It's a give and take from my perspective.
  Reply With Quote
Old December 7th, 2017, 11:47 PM   #10
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 1,962
Quote:
Originally Posted by Jsu0234m View Post
Sorry for the rant but please don't forget about the plant controls guys that have to maintain these master programs. It may be easier for you to use one template for all the programs you build, but damn its time consuming for us to troubleshoot when its spread out over 50 routines.

I understand your time is money, but my downtime is $100ish/minute when it stops during production and i have to figure out whats wrong with it.
Devils advocate...

Your company buys from the lowest bidder, to be competitive from a price stand point this is what you might be getting to ensure costs are minimum as possible to win the job.

Not to minimize downtime costs, but make sure you always understand what you actually paid for (and what happened in the buying process) versus what you're expecting and what you WANT it to do versus what it was SPEC'd to do. Not saying you don't have a valid point in this instance, but I'm sure the OEM has a valid perspective as well.

"MES integration was removed from the scope per Upper VP, we had offered a customized programming option for this customer with MES integration but they opted for the 'canned' software package saving $50,000 on the project. Pros/cons were discussed and Upper VP signed off"

Just saying that sometimes you get what you pay for.
  Reply With Quote
Old December 8th, 2017, 01:09 AM   #11
kalabdel
Member
Canada

kalabdel is offline
 
Join Date: Feb 2015
Location: Ontario
Posts: 237
Quote:
Originally Posted by Jsu0234m View Post

Sorry for the rant but please don't forget about the plant controls guys that have to maintain these master programs. It may be easier for you to use one template for all the programs you build, but damn its time consuming for us to troubleshoot when its spread out over 50 routines.
I understand your concerns but the whole idea of routines is that you don't have to get into each one to troubleshoot. You should be able to ignore those that control processes that have nothing to do with the problem.
  Reply With Quote
Old December 8th, 2017, 07:36 AM   #12
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
Quote:
Originally Posted by bill4807 View Post
In these situations it easier for me to just rewrite certain sections more simply.
It's a give and take from my perspective.
Yeah that's what i usually do after the OEM guys leave. 95% of the time after the OEM guys leave they don't ever see the programs again because we do the PLC maintenance, troubleshooting, and repair in house anyway.
  Reply With Quote
Old December 8th, 2017, 07:39 AM   #13
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
Quote:
Originally Posted by ASF View Post
It's a f***ing freezer. Not a nuclear reactor.
Yep, i'm with you.
  Reply With Quote
Old December 8th, 2017, 07:52 AM   #14
Jsu0234m
Member
United States

Jsu0234m is offline
 
Join Date: Apr 2013
Location: Alabama
Posts: 53
Quote:
Originally Posted by Paully's5.0 View Post
Devils advocate...
"MES integration was removed from the scope per Upper VP, we had offered a customized programming option for this customer with MES integration but they opted for the 'canned' software package saving $50,000 on the project. Pros/cons were discussed and Upper VP signed off"

Just saying that sometimes you get what you pay for.
Oh i know what you mean, I usually do the control specs for our plant, but every so often engineering brings in a big project and i get left picking up the pieces. MES integration wasn't part of the spec that's what I get paid for and its usually not too difficult to setup some messages, heartbeats, and control bits to send start, stop, and status signals. This program was so convoluted it took me the better part of a week to get everything functioning correctly. Which is what started my rant.
  Reply With Quote
Old December 8th, 2017, 08:35 AM   #15
JesperMP
Lifetime Supporting Member + Moderator
Denmark

JesperMP is offline
 
JesperMP's Avatar
 
Join Date: Feb 2003
Location: Copenhagen.
Posts: 13,116
It can make a lot of sense to use the same template for various tasks.
A standard template can provide useful "goodies" that may be valuable even for small tasks.
I am thinking diagnostics functions (for the enduser) debugging/profiling functions (for the developer), testing and calibration functions (for maintenance), datalogging functions, recipe funtions, simulation functions ....

Using such a template and reusable code will mean there will be additional layers and dormant code, as compared to an absolute bare-bones program.
That is the disadvantage, but if the template-based code works well, then it is not an issue. I am of the opinion that endusers and maints should not have to look into the PLC code to use or troubleshoot the machine. To me if that is necessary it tells me that the code and user interface is not fully developed. I cringe when I hear that maints have to look at the PLC code to troubleshoot a machine.
If the code does not work well, then the programmer has made a bad job of it, template or not.
__________________
Jesper
3 strikes and you're out
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Twincat 3 with multiple programmers jonfarrugia LIVE PLC Questions And Answers 3 March 1st, 2017 10:30 AM
am i allowed to run windows 7 OEM on VM ? MaGoOoDy LIVE PLC Questions And Answers 24 February 28th, 2017 11:31 PM
"WET" Contact / "DRY" Contact Terry Woods LIVE PLC Questions And Answers 20 June 6th, 2010 07:15 AM
Unlock an OEM Locked (Allow / Deny Future Access S:1/14) MLX 1500 Processor 69FIREBIRD LIVE PLC Questions And Answers 4 March 26th, 2009 06:13 PM
How to simulate a FOR..NEXT loop? New2PLCs LIVE PLC Questions And Answers 26 May 9th, 2002 12:36 PM


All times are GMT -5. The time now is 05:40 PM.


.