OEM "Master" Programmers

Jsu0234m

Member
Join Date
Apr 2013
Location
Alabama
Posts
94
Is it just me or does it also drive other Plant PLC guys :eek: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 :eek: 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.
 
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
 
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.
 
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.
 
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.
 
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.
 
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
 
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.
 
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.
 
Sorry for the rant :eek: 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.
 
Sorry for the rant :eek: 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.
 
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.
 
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.
 
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.
 

Similar Topics

I've had a Danfoss OEM drive come in from an Ingersol compressor. It is essentially an FC302 but the OEM part is IR302. the drive appears to be...
Replies
0
Views
368
As I understand it, Codesys is the foundation for many different OEM branded HMI software packages. What are the advantages and disadvantages of...
Replies
5
Views
1,597
Can anyone share the hardware/software in integrating Radio-frequency identification (RFID) security on a plant floor's OEM machine HMI's? I...
Replies
3
Views
2,942
Hi Guys, I need some help with a machine that has an SLC 5/04 communicating with a wonderware panel over DH485. I can monitor the logic while the...
Replies
16
Views
3,291
Hello, I'm a novice PLC user but advanced Excel VBA user. I've created a program to capture and email data from our PLC. The capture happens...
Replies
21
Views
3,748
Back
Top Bottom