estemate program hours

How can one estimate the amount of time it takes to program a PLC? I realize this is a vague question, so forgive me. I am trying to come up with tools to help questimate the amount of time it takes to program for pricing purposes. Being a programmer I found that if I said 2 hours it would take me 10, if I said 10 it would take me 2. I have tried estimating time per IO, but that does not always work. Can anyone help?

Programmers I have dealt with in the past, base the price on 4 things:
1. number of analog I/O
2. number of digital I/O
3. number of sequential task
4. number of continuous task



I do not know what the price per is, but everyone seems to ask the same 4 questions.


Ken

The answer is "It depends."

I/O count alone doesn't give the answer. I have a lot of sytems with a lot of I/O, but has multiple PLCs for several identical processes. A system with a lot of communications and very few I/O may take more programming and start-up time. A system with hardware I'm not comfortable with can take several times teh hours as a system that I'm familiar with. A custoemr that is known to be picky and has a lot of trivial requirements specified will require more time to satisfy than one that is simply results oriented.

It ultimiately comes down to experience. No matter what, I win some, I loose some. One of the reasons I like to supply panels and field devices with my system is so there is enough mark-up that even significant errors in estimating time can be absorbed.

Itemize as much as possible. Number of I/O alone is usually very
poor indicator. Communication and documentation are usually
eating up majority of development time. For programming try
to determine things like number of programs, size of each program,
complexity of each program (you might have short program
that requires lots of thinking and testing), program dependance
on communication or handshaking with the rest of the system
(this will take some time in field to complete), who do you have
to deal with, are the scope and operation clearly defined,
how do you prove that your system is working fine and that
possible problems are responsiblity of others etc.

With all the diferences in software and other design criteria, and personal abilities, there couldn't be a pat answer.

I've seen guys say it takes one hour per I/o and it costs $75.00 per hour. For that kind of money, I'll through in the whole panel on a 100 I/O job.

With Fanuc, I used to figure a minute per line, with most rungs averaging 2-3 lines.

I seldom had anything really fancy, a lot of drum sequencers, simple timers, an occasionale analog input.

I stay away from Siemans since I've heard so much againt their software. I would figure that it would take me 3-5 times longer to program. I find that Allen Bradley will take me at least 3 times longer.

As they say, results may vary, do not use under water, professional driver on closed course, don't try this at home.

regards....casey

This is one of the biggest problems I've ever met with.

My company uses the following method.

1) Ask me
2) Multiply my answer by 3

(8{)} ( .)

(Yosi)

Yosi - My multiplier is 6.8

There are no hard and fast rules that we here have ever found. Too many things affect programming time.

Yes, I/O count is one, but that is mostly mechanical time (that is, assigning labels/descriptions/symbols) for digital I/O's.

Analogs and math cost more time-wise.

Communications cost yet more.

Specialty modules cost more.

But, the biggest factor is the quality of the specification documentation. If you can split a problem into several smaller, mostly independent modules, programming time is decreased.

If you can actually generate, or have a flow-diagram of exactly how things should work, programming is almost a linear translation time-wise. If documentation is poor, you start approaching bubble-sort programming times. I generally consider an average programming task to be in O(log n) times, but poor understanding of the problem before writing code can easily get to O(n^2) or O(n^3) times.

The 'n' in the 'Big O' notation above refers basically to time per I/O point, counting BOTH physical and HMI/Datalogging I/O.

Whatever programming time may be, Debugging will be at least 3 times programming /sigh.