overall PLC program management...

I've been programming plcs for several years now and I'm at that point that I want to streamline. All of our machines are custom, but all are similar, in most regards. Some machines just have more processes on them then others (I.E. Dereelers, inspection stations, servo feed vs mechanical feed, etc). I've been getting by fairly well, but I'm looking for ways to keep things as simple as possible, and easily repeatable.

Given a varied customer base, I use three different PLC types, AB SCL500's & Micros, Omron, and the occasional 90/30.

I am not the end user of any of the machines, so I do my best to document the program well, and keep my programming style as simple as possible. Whichever manufacturer, I break everything down into smaller blocks/subroutines/whatever each manufacturer calls them, just to simplify things, and to make the programs easier to manage. That seemed like a no brainer. After all, if your going into someone else's program to make a timer value change on the inspection station, it's nice to go right to the "Inspection" section of code rather than bounce around searching.

Our machine's use several types of motion: servo, cam-driven mechanical stations, pneumatic, all depending on the processes required, and on the budget.

What I'm looking for is suggestions/tips on simplifying the programming process as a whole...
What's the best way to manage such a wide variety of machines, some with 2 stations, some with 20 stations?
Is it best to incorporate a "Main Cycle" subroutine to manage all of the stations, to verify completion of all of the other sub-stations?
Is it best to allocate a certain section of memory for a given process (always use the B3:100 word for dereeler logic, and B3:102 word for dereeler faults, and always use the B3:104 word for inspection logic, and B3:106 word for inspection faults) so that I never have to go through the task of re-assigning addresses? (except, of course, the I/O addresses involved)

The list of potential 'shortcuts' could go on forever, and I have already found a lot of ways to make things easier on myself, and I'm sure that all of us have our own tricks, I'm just looking for a more global approach to programming. Something more Cut/Paste. Something easier, and more practical, that saves more time and as a result, saves more money.

Most of this is probably second hand knowledge to most of you, and forgive me if I sound elementary. As I said earlier, I've been getting by just fine with the knowledge that I have, but as most of you are well aware, time to market is critical, simpler is usually better, and the sooner a project is completed, the better. But it's easy to spend years doing something 'your own way' only to find out that you could have been doing it 'this much easier way', and saved a ton of time in programming and debugging time.

Thanks, in advance, for your tips/tricks/shortcuts and input.
John

In a situation similar to yours, I found it best to modularize the code as well. For addressing, I used symbol based addressing. With RSLogic you can save your files as library files in a PC5 (ascii) format. You create a new project and assign your symbol names to the appropriate addresses. You can then insert your PC5 files into the new logic with Address Load Mode set to Symbol. The imported file will be checked for symbol collisions. If a symbol exists, the address of the imported file will change to match the existing file. The symbols could keep things consistent throughout your programs even when the addressing may have to differ.

I only had to use PLC5s, but had dozens of configurations of the machine. I used conditional subroutines to call the appropriate sections. I had a global bit file that stored the configuration of the machine. You could set a bit in this file to select the different features that were installed, and those bits would activate the correct sections of logic. This allowed me to use one program for my HMI and make the PLC programs as similar as possible. I would not, however, want to put enough logic for 20 stations in a machine that only has two. You could have one master program that had all the features you could ever need, and then just delete the sections that aren't used to keep it simple for you and the end user.

Another thing that could help is input/output mapping. You can have 2 ladder routines, called "Inputs" and "Outputs". All scaling, masking, is filtering done there. That makes it possible for the core programs to be identical even though the actual wiring and I/O types, or even PLC types may be different. As part of startup you have to verify the I/O anyway, and you can edit these two ladder programs as part of that process.

Doing the PC5 library file thing requires some initial investment in time to get set up, but should pay off once you have a system down.

Hi John. I am in the exact same boat as you, years of experience, OEM manufacturer and all. Just like you I have learned that splitting the code into sections is the ideal way to program. Spaghetti code is just unmanageable. We strictly use AutomationDirect PLC's, but I think the process should be universal. Here are some things we do here:

1. Flow Chart
Lay out the process with a flow chart. Split up the different
stages into the smallest chunks as possible. You can go too
far when deciding the stages. You don't want one line per
stage, but you don't want 50 lines either. This just takes
experience. Keep modifying the flow chart until you are happy
with the process before you write one line of code.

2. IO Definitions
I use internal bits for every input and output point so I can
buffer or do whatever I want to the io points. For example if
X0 is the actual input point I will turn on output C100 (which
is an internal bit) and I use this internal bit in my
program. This allows me to do things such as say that X0 must
be on for 250 milliseconds before C100 turns on. I do the
same thing for outputs (I start the outputs at internal bit
C200) so I have more control and checks before I turn on the
actual output. I have an Input control stage that basically
is always scanned and an Output control stage that is scanned
only when there is not a fault or estop condition.

3. After you have the flow chart and IO definitions the program
will practically write itself. If you keep the same standards
as far as a master control stage and input and output stages
and use the same IO conventions (start at C100 for inputs and
start at C200 for outputs and start at C300 for internal
flags) then all of your programs will have the same kind of
framework.

Hope this helps, remember that everyone has their own way of designing systems and the two most important things to remember is that you are comfortable in the way you design and that you stick to the same layout when designing systems.

John,

Probably one of the first things you may want to consider...in order to make things easier for you is standardizing on one controller platform.

Right now, you have three different platforms, which means three different software packages, three different manual sets, three different vendors.

Review your requirements for all your systems identify the controller that best fits your maximum requirements. Remember, you can always take away, but you may not always be able to add.

I can see one potential problem in this being your end customer and their specifications for controllers. Happens all the time.

With our products, we give our customers ammunition on how to address this issue should it arise. Here is some of the information we provide to assist them. There may be something there that helps.

www.entertron.com/oem.htm
www.entertron.com/info.htm

Therefore, should you standardize on one solution, you will have to be prepared to defend it.

If your company offers any product the customer wants, in order to make the sale, then you may run into some resistance with this method. In order to attempt this, you will require complete company backing.

The reduction of vendors should streamline what you are doing as well, in that the one resource that you can never get back will not be over extended....TIME.

Companies today are looking to cut costs where ever possible, in order to remain competitive. Engineers are doing production because they don't want to hire anyone...forcing R&D to be pushed back for the sake of a sale.

We have been on both ends...we have benefited from customers choosing to standardize on our products. We have also lost customers because they wanted to standardize on a certain controller. What's the saying..."No one has ever been fired for choosing Allen Bradley"...lol.

Should this not be an option, I am certain that others who are quite talented at programming will be able to offer you some suggestions, on how to better optimize your time in that aspect.

Hope this helps.

God Bless,

Thanks everyone for your input/suggestions. I hadn't thought of using indirect addressing...not a bad idea.
AB has a really nice import/offset command that allows you to take your logic bits/words (I.E. b3:00-b3:15) and offset them by 'x' amount of words. That has proven very handy. For example, you can write your re-usable codes all in word 0 and them bring them into the project as word 10, word 11, whatever you want. Nice feature. If you have multiples of the same station, you just import the code with a different offset value and your ready to go. (after changing your I/O addresses, of course) I fairly certian that you set up a symbol table in notepad, or Excel, but I havent done so...yet.

Omron has relatively simple way of importing addresses/symbols from a simple tab-delimited text file. You can do it line by line, or multiple lines, and probably the whole file too. You can even define memory types. I am in the slow process of building this file, but when done, I should be able to take a section (let's say a dereeler), change the I/O addresses in the text file, copy that whole chuck of "Dereeler" text, and paste it right into my symbol table, including memory types that I use for timer presets. Haven't tried on a large scale yet, But I think if I copy and paste rungs from other projects, and the symbol names match, CX Programmer will automatically change the addresses to what is in the symbol table.

Stephen, regarding your Entertron ePLC...
While your suggestion seems idea on the surface, the very last thing I want to do is learn yet another platform, and then try to sell that concept to our entire customer base. Honestly, most of their plants have standardized on one PLC platform, and even if they don't like it, they stick with it, because, well, for obvious reasons. Being an OEM puts me in a position where I need to be flexible enough to provide them with what works best for them, not just for me.
The market for building machines is a tough one right now, and we all know it. Being flexible is the key to getting, keeping, and maintaining our customer base. If it means I have to jump through all of the hoops involved in using multiple PLC platforms, then so be it. (Even if I have to manage 20 goofy cables...I hate that) And it also means that if a customer wanted to use an Entertron ePLC, then I'd do it, with only minimal complaining. ;-)

Yep, it reminds me:


This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
It should not be too hard to follow...

Hundikoer: well put, I didnt want have to be the one say it

Whoa, hold it...

We all know Stephen works at/for Entertron, but I for one have no objection if a vendor contributes usable information from the standpoint of the platform he is familiar with. Stephen's arguements for standardizing are universal, not specific to his own platform. You could just as easily use them to argue for standardizing to AB or Siemens.

Personally, though, I agree that you have to be flexible. I love Unitronics, and push it wherever I can, but if my boss told me one day, "From now on, nothing but AB"...well, I'd show him how it would triple his cost and that would put a quick end to it, but you get the idea.

At the end of the day, you do what the boss (customer) tells you, or you find another place to work...


TM

I was not going to say anything but....

A question was asked on the best method to do something and Stephen offered an option. In the process he did provide information pertaining to his company BUT if you "READ" it fully he was also stating that the same principle could be applied by using any "ONE PLC BRAND".

If a person happens to work for AB, ABB, AD, Siemens etc and provides link(s) to specific information why aren't comments made about advertising then?

If a person happens to work for a specific company and can not offer information because it can be construed as advertising this would prevent many of the professionals from participating.

John,

I think you misunderstood my post.

First, there was no advertising involved. Nowhere did I suggest considering Entertron's products. I merely provided you with information, that although directed towards Entertron specifically, could have been used by yourself.

Second, because I work for Entertron, and know our products better than anyone, not to mention the industry in general, should not penalize me for the information I provide as being "advertising". Sounds like a double standard to me. Just because you don't work for the company who's products you use, allows you the luxury of promoting them to others?

Had an Entertron product been an ideal fit for your application, I would have mentioned it. Just as anyone else would have mentioned a controller from a different manufacturer.

Are you going to penalize Casey for promoting our products too? Shameless advertising on his part. Please!

I wasn't suggesting the use of our products, but merely suggesting that of the three (or four) PLC platforms you are currently using, selecting one and developing your solutions around what you have selected.

The links provided, although directed towards our product specifically, may have offered some additional insight to your objective.

The focus of my response was on the three (or four) different PLCs you are currently using. You had mentioned that your machines are custom but similar. As an OEM, I would think you would want to focus on what you have created once and developing a library of options. In this case, rather than one library, you have four. That has to be difficult to manage, no matter how efficient you become with programming.

There might be little things you can do to make your programming of each more efficient. However, you are duplicating your efforts times four.

Let's use this scenario. The same exact machine, two different customers, two different PLCs. As an OEM, you lose your economy of scale, your efficiency. What could be done with one PLC - as your standard, now requires two. As you know...two different PLCs, two different programs.

I understand your need for flexibility as a custom OEM. But you are paying for it in time lost, duplication of effort, software cost and loss of buying power through quantity purchases. Even if you standardize on one platform, you can still offer the others as options with a price adder.

If you make a good product, regardless of what controller you use, the sales will come. Would it be safe to say that your machines sell because of your relationship with your customers, what the machine does and how well they are built?

In dealing with many OEMs, their primary focus lately, is reducing cost, in order to remain competitive. This means getting rid of layers of cost. This means improving efficiencies. How much does it cost your organization to support all these platforms? Not only hard costs, but soft costs (time)?

You work for one OEM, I deal with many on a daily basis.

Would I want to have you as a customer...certainly, but only if it makes sense to you. In your current scenario, it doesn't make sense.

Well...

My main job is for one research and develpment centre (quite famous in Europe) and the main problem is that companies see only one selling benefit: COST

In long term it does not work as globalization, Asia, etc. Only one company can be cheapest and there can be always someone who provides "same" equipment with cheaper price.

So, you MUST find another benefits, why people (companies) will buy from you.

These should be :
Functionality
Performance
Flexibility
Customer Relationships

and other two that are as "good" as Cost:
Delivery
Quality


Just my free training about making good business (creating wealth) in long term

On a side note...Ron & Tim, thanks for your comments.

God Bless,

Hundikoer,

If you are solely selling on price alone...then no it doesn't work. You win on price...you will eventually lose on price. When selling solely on price, there is no value created by the manufacturer. He basically states that buy our product because it is the cheapest. What happens when a cheaper product comes along? The manufacturer has nothing to promote or differentiate his product from, other than price, for which he is no longer the "cheapest"

However, this is not what was being discussed.

We are not talking about selling cost...we are talking about production cost. The cost to make what you sell. Eliminating costs from your final product.

In John's case, there are multiple areas that his company can minimize or eliminate costs associated with the final cost of the machine. It is up to them to decide how best to proceed for the longterm benefit of the company.

From some point this topic does not make sense to me anymore.
Anyway

it is true that pricelist price of an "item" does reflect the TCO (total cost of ownership).

Is it reasonable to:
1)change current brands to new one (probably keep some old stuff for previous customers in stock also)

2)train all personell to use new brand (also train new people to use old brands to give proper support)

3)make customers to belive that new brand is better
etc...

well, it is everyones own decision

You used some very good examples, what we did at USFilter Control Systems, before they were bought out, was create program libraries, Dereelers will look like this and be I/O pionts a-f, so you look for what you need and put it in. While I agree standardization helps you have to be flexable for the customer, I'm now working for an end user and it is a nightmare, I have 12 different PLC manufactures I have to maintain, because each oem built using their standard.