OEM "Master" Programmers

If it weren't for others incomplete work, some of us wouldn't have a job!!!

I mean, I was hired to help / take over from / continue on with an integrators many projects that were at various stages of completion in our plant. 99% of what they did has been bettered in some way, added to, rearranged and some removed completely. Trust me, I'm no integrator and I come from the maintenance origins, but no matter what Iv learned from all of that. There were at least 6 of them here in total from one company. They all used the same templates but some made a big mess of it, others made it work like a charm. I learned from their mistakes as well. Yeah its annoying to see a SLC conversion project that looks like a Frankenstein to run 12 motors. I'm also referring to a freezer! I believed Iv complained about it before here. But think of the opportunities to pick up simply by picking up after others. The project often doesn't end up how you would like it but the managers are happy when you clean up a project that they have ignorantly paid dearly for and didn't do what they needed.
 
Some of our customers required us to submit plc code before the machine was shipped so maintenance could look at it and comment.

one guy always had issues, he likes sequencers. Liked to never got him out of that habit.

on my programs, once maintenance learned my programming methods, they had no issues, I worked with all of them and explained my programming methods. they liked my ideas and soon required it on all machinery.
every 5-10 rungs, use a seal in bit to let you know where you were.
if bit 3 was on and bit 4 was off, look in between for the problem.

of course, everyone programs differently.

james
 
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.

So much this... The company I just joined has to get a guy over to the plant to reset a few bits inside the PLC if there is a power flick otherwise nothing will work.

I was speechless when I realised that this has been like this for decades!!! Simply stupid.
 
.... I am of the opinion that end users 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.


You make a good point but from my experience the reason guys have to dig into the code to trouble shoot is because diagnostic devices or messages are absent, incomplete or simply don't work.

I just got done with a project where the customer wouldn't agree to put in valve opened & closed pilot lights. Maintenance has to either open the panel to see if the relay is closed or dig into the program. Stupid things like that are everywhere.
 
I just got done with a project where the customer wouldn't agree to put in valve opened & closed pilot lights. Maintenance has to either open the panel to see if the relay is closed or dig into the program. Stupid things like that are everywhere.

I've been involved with multiple projects where the end user said this is my HMI spec, follow it exactly. The machine builder returns two quotes: a low quote with the functionality the customer requested and a high quote with the additional diagnostics the customer actually needs.

Never seen the end user spend the extra once, but they're also never happy when it isn't there.
 
There are times where I appreciate this and times where I don't. We have about 8 machines of various styles from the same vendor. They are all physically similar (index table & stations), but also varying in different ways.

Although they do some things in a way that I would describe as less than simple or straightforward, they did tend to use the same structure throughout each machines program.

Once I gained some experience with one, I sort of had a head start with the rest in the event that we had to make a change, or the dreaded online troubleshooting.

I imagine its sort of a tricky situation, because its great to have a uniformly structured program, for a lot of reasons. If it gets to the point that you're making things way more difficult for the sake of being uniform then that's definitely a huge disadvantage.
 
Yes, to make things worse. One outfit send out a commissioning guy that doesn't understand the template made by the their other office location so he went around the structure at times just to make things "work" for one specific scenario after another.

2 years later, we rip the code out and started over on our own.

That's the problem with PLC sometime, it's so flexible that one can hung themselves it.
 
I've worked at some horrible companies. Go easy on the programmer. Most likely he don't have a choice in the matter.
 
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.

Was this a VRT freezer by chance?:geek:
 
We've been getting template programs for several years now from Japan. Besides having the PLC program setup for future stations the HMI's are also pre-canned with screens for future expansion. Talk about memory hogs.

Honestly, most times I could add the new additions on the fly instead of going through and changing the templates to work.

I do have some template programs for PLC's and HMI's that I start with but finished projects never have additional useless items for future changes. I like the lean and clean look when I'm finished with a project.

Jerry
 
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.

I'm very glad it's not a nuclear reactor if it faults after a year!

We have inherited similar sites. 12 wastewater pumping stations all done with PLCs. Complex state machines implemented for 2 pump duty rotation and stop start on level. Frequently have them get into a state where nothing runs because the original programmer got himself in such knots that he didn't consider a state transition condition.

I have a backup float system that saves the day every time until we replace these obsolete PLCs. 2 floats, one relay and a timer!
 
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.

I agree wholeheartedly. I work for an OEM doing Commissioning/Startups and we have developed easy to follow diagnostic screens on the HMI to make it easier for the average maintenance technician to troubleshoot without ever having to hook up the laptop.

I understand the use of a standard template for programming though. We don't have tons of unused subroutines or UDT's, but every now and then I'll find a rung or two bypassed if the particular machine doesn't have that option. The protocol makes it much easier for the Field Service Engineers to troubleshoot or do program changes if necessary. I also make sure to listen to the customers suggestions on certain things and relay any kind of bugs or possible improvements back to the program designers when I find them.
 
The worst examples I have seen are PackML programs.

Never. Go. Full. PackML.

Couldn't agree more. PackML implementation has the disadvantage of being memory intensive for PLC processors, unnecessary unused code as well as having an incomplete state/mode model for some machines.

Supposedly corrected in newer implementation but still an overly complex approach to simple machines.
 
Some customers like the old spaghetti code and their maintenance is used to this as well. I don't. It's hard to troubleshoot and does not read like a book. Now I just program the most efficient and clear way that I am used to. Use lots of comments and type paragraph tag names because I will brain dump this project soon enough. I do always show maintenance how to troubleshoot faults.
 

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,289
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,747
Back
Top Bottom