Hoping someone can point me in the right direction. What is a good way to quote for writing PLC & SCADA software? Ive been told, quoting a price per I/O point was effective. If so, What time should be allowed per point?

hope someone can help!

 

One way is to quote based on no. of mandays required. You can estimate no. of mandays based on logic description, No. of I/O s & your expertise on application & software. Similarly, for SCADA software you can estimate mandays based on no. of screens, reports, trends etc. You can esimate your manday rate based on overheads/ profits etc. Hope that this will help you in estimation. Good luck for new project!

Regards

- AJ
[email protected]

 

It depends on how fast and good you are at programming. I have worked with other programmers that I was happy to pay $120-130/hour to becasue of their code production ability, and others that aren't worth $25.00/hour and will cost more in the long run.

Number of IO points is a rough but generally good enough indication of how long a job will take one particular programmer, but rate/point will vary between programmers.

 

> Number of IO points is a rough but generally good enough indication of how long a job will take one particular programmer, but rate/point will vary between programmers.<

Number of IO points is *VERY* rough. A complex function sequence may have only two or three IO points, while simly lowering a conveyor stop may be tied to 5-6 downstream prox switches. In this case you'll get paid twice as much to write one rung as you will to write perhaps 20 rungs for the complex function.

One model used in the IT world, and it's not a perfect fit here (actually it isn't a perfect fit there either), is to use function points. (Hey, they don't really have IO points in most IT group programs.)

I don't have a good model to suggest, but I sure would like to see a thorough discussion of this. Maybe something like

((IOpoints x Q) + (Functions x P) x FudgeFactor) = $Estimate

--
Michael R. Batchelor - Industrial Informatics & Instrumentation, Inc.
Linux is like a wigwam...
No windows, no gates.
Apache inside.

 

This is how I estimate internal project quotes as well. For most small apps or modifications I work on, I start with a base 120 hours. This would be something on the scale of a SLC 500 app with maybe a touchscreen and 75 to 100 I/O points.

then I look at how complex this project is in comparison to other projects that fit into the 120 hour estimate. To determine complexity, I use the same 'function point' analysis. For example:

on a small box erector control project:

Machine reset and home machine startup (pre-load blanks into position, etc.)
Normal Cycle:
- blank puller
- side pullers
- ram
- glue guns
- press area (for glue drying)
Error detection / reporting
Operator Interface (in this case, lights and a few buttons and switches)

By comparing this list of functions to other projects, I can adjust my base value of 120 up (or down, in this case) accordingly.

Next, I look at who the project is for. Some people simply require more overhead due to changing their mind on operation, or insisting on extra meetings. Add this time into your quote.

Depending on the length of the function list, I add anywhere from 0% to 15% 'fudge'.

I really do not use I/O count as part of the analysis. since I/O and internal bits are all used for a function, the number of I/O controlled is not nearly as relevant as what must be done to control them. A project with 1 analog in and 1 analog out might be a simple scaling function, or it might be a complex PID system that you have to code in ladder (AUGH!). Same I/O count, but your function list is much different.

--Joe Jansen

 

I am interested in knowing how the IO points effect the selection of the SCADA/HMI Package [ie number of tags]. We usually take the IO as an indicator to perform this function but with some PLC (like TI), which use structured data, the number of Tags rise exponentially [this I found out to my anguish in a recent project].

Joe, is there any basis for your 120 hr base?

- Shahid

 

The 120 hour base is something that I have come up with over the years. I guess 120 hours represents a sort of 'average' time spent on an 'average' project. (The size of projects I typically get, anyway.) Over the course of 10 years I have been in this field, I have found that it is a pretty reliable starting point, for me.

I would recommend looking back at any work you have done in the past and try to compare it against what you are quoting. Experience is really the best indicator. If you don't have anything to compare against, break it down into smaller chunks, look for similarities between these smaller pieces and anything you have done.

Keep breaking it down until you get small enough parts that you know you can finish in less than a day. Then add it all up, put on some extra time for getting it all to work together, and you should be pretty close.

--Joe Jansen

 

I agree for the most part with Joe Jansen's response. I/O points are insignifcant except for the most basic of apps.

I will also add to remember to look at VALUE offered, not just discrete I/O points or tasks.

I once added a discrete on/off button to a maintenance screen on a process machine that reduced the calibration time of the machine from 3.5 hrs to 1 hour. Those 2.5 hrs translated directly into dollars that could be measured.

The client realized that the machine gained approx 2 hrs additional production on calibration days.

Point being is that looking at that scenario as modifying a single I/O point would have GROSSLY undersold the value received.

Unfortunately, only expereince is going to tell you if you're on target or not. If you don't receive ANY price resistance when you quote, then you're probably too low to start with.

 

I use a simple but very effective way to quote PLC and HMI programming costs.

I/O points are your beginning point. You also need to determine to type of process in order to determine the complexity of the program. I use a multiplier system such as the following:

"3" = Basic PLC control functions no data storage or data tracking required. (Example: simple package machine, stand-alone cycle testing machine, etc.)

"4" = Some internal data calculations and functions required as well a machine functions, addressing for faults and MMI interface as well and any Analog functions. (Example: Pick and place machines, pump control stations, etc.)

"5" = High-end control functions using indirect addressing and PID functions required. (Example: robot control cell, conveyor-tracking system using extensive data tracking functionality, etc.)

# of I/O points multiplied by the multiplier variable (3,4 or 5) gives you a value. You then have to decide what a standard number of rungs per day or 8-hour period. I use 30 rungs for 8 hours as a base point.

Example: use the "4" process multiplier (for you process complexity) and you have 200 I/O points.

4 x 200 = 800 then divide by 30 rungs and you should get the total number of days required. 26.6 days PLC programming time. 800 total rungs/3.75 rungs/hours = 213.33 hours.

This system allows for processor and software configuration so do not let people tell you that setting up a processor does not take time. There are many issues to address when programming PLCs and some are not straight forward.

When developing a HMI there are several methods to determine the pricing. I would be happy to provide information on this as well.

 

I would appreciate it very much if you would provide your HMI pricing system.

Bob Pawley
250-493-6146

 

I just saw a programming quote from a major DCS supplier as follows:

8 process display/operator control screens (basic, fairly simple mimic screens)
42 analog inputs and outputs
communications with PLC
PID loop screens as required (8 or 9 in all)
PID loops under control of DCS, all other control by PLC

net price >$80,000

The hardware (42 analog inputs and outputs) was seperate at (conveniently) $42,000 and change, and did not include installation or any wiring, and are being installed in existing unused racks.

This was after the end user's 15% discount was applied.

 

I use a simple but very effective way to quote PLC and HMI programming costs.

I/O points are your beginning point. You also need to determine to type of process in order to determine the complexity of the program. I use a multiplier system such as the following:

"3" = Basic PLC control functions no data storage or data tracking required. (Example: simple package machine, stand-alone cycle testing machine, etc.)

"4" = Some internal data calculations and functions required as well a machine functions, addressing for faults and MMI interface as well and any Analog functions. (Example: Pick and place machines, pump control stations, etc.)

"5" = High-end control functions using indirect addressing and PID functions required. (Example: robot control cell, conveyor-tracking system using extensive data tracking functionality, etc.)

# of I/O points multiplied by the multiplier variable (3,4 or 5) gives you a value. You then have to decide what a standard number of rungs per day or 8-hour period. I use 30 rungs for 8 hours as a base point.

Example: use the "4" process multiplier (for you process complexity) and you have 200 I/O points.

4 x 200 = 800 then divide by 30 rungs and you should get the total number of days required. 26.6 days PLC programming time. 800 total rungs/3.75 rungs/hours = 213.33 hours.

This system allows for processor and software configuration so do not let people tell you that setting up a processor does not take time. There are many issues to address when programming PLCs and some are not straight forward.

When developing a HMI there are several methods to determine the pricing. I would be happy to provide information on this as well.

Hi, Thanks for providing this info, seems like this method is easy for even a project engineer to understand. Could you also provide your method for HMI as you spoke of?