One hour per I/O point is a floor, and only for digital points with simple logic. Build the real estimate from line items: analog points at 1 to 5 hours, PID loops at 4 hours, batch sequences at 8 to 40 hours, networked devices, communicated tags, screens by content, and site startup. A 120-point example carries the method to 276 hours.
Count 1 hour per I/O point and stop there, and the number holds only for a job of simple digital points with nothing attached to them. A defensible estimate is a list of line items: points by class, functions, analog handling, screens, communicated tags and startup, each with a rate you can name. This page gives the rates working estimators publish, the scope list to write before any hours, and a 120-point packaging line carried through the arithmetic to a total you can defend.
The rates estimators publish
These allowances come from working control integrators and estimation guides. They are rules of thumb: write the one you used into the quote, and track your closed jobs against it.
| Line item | Allowance | What moves it |
|---|---|---|
| Digital point | 1 h per point | The most widely shared rule; bundles an average of 6 HMI screens per project |
| Digital points in bulk | 8 h per 16-point card | 0.5 h per point, for repetitive points with no unique logic |
| Analog point | 1 to 5 h per point | Scaling to engineering units, status flags, error handling |
| PID loop | 4 h per loop | Loop programming; tuning happens in the startup shifts |
| Batch or recipe sequence | 8 to 40 h per sequence | Step count and abnormal-path handling |
| Networked device | 2 h per device | Configuration and handshake |
| Communicated tag | 1 h per tag | Values mapped past the physical I/O list |
| First-guess check | your gut figure × 2 | A shared rule for optimistic first estimates |
| Complexity check | desk estimate × 3 to 6 | Multiplier advice as communications and sequence logic grow |
Two digital rates sit in that table on purpose. A point that only reports status prices toward the card rate. A point inside an interlocked sequence prices at the full hour, because the hour buys the logic, the test and the tag. Choose per point and note which rate you used.
Write the scope before any hours
Hours attached to a moving scope are a guess with decimals. Fix the edges first.
Put in writing, before the first hour is counted:
- PLC logic and module configuration
- HMI development, screen by screen
- Bench test, documentation, and startup shifts at site
- The number of revision rounds included, and where they end
Leave out, in writing:
- Panel wiring and assembly
- Mechanical and instrument installation
- Any system past the agreed tag list
Flag as open decisions, with hours attached where you can:
- Operating sequences still being designed
- Analog ranges not yet fixed
- Devices the customer may still add to the network
A reviewer should read the estimate and see what it covers, what it excludes, and which open decisions can move the total.
Classify every point
Split the count before pricing it.
Digital points: record the count, the purpose of each signal, and the function it serves. A status input and an output in an interlock are different jobs with the same point count.
Analog points: record the count, the signal range, the number format on the controller side, the engineering units the operator reads, and the module's status and error flags. That last item is where the analog hours live, and it is why the published range runs 1 to 5 h per point.
Internal bits: no hour of their own. The sequence that sets and resets them is what you price.
Scaling is where analog estimates go wrong, because integer division truncates. With raw counts, 100 × 3 ÷ 8 gives 37 and 100 ÷ 8 × 3 gives 36; the order changes the answer. Multiply first, put the scaling in one block, and test that block at 0 and at full span before it is copied anywhere.
Price functions, not bit counts
The point list says what the program touches. The function list says what it does, and functions drive more hours than points on most jobs. For each function, write down what starts it, what stops it, what blocks it, and what it does when something fails. Estimate the build and the test separately: a function with only its normal path coded is half finished.
Use the table rates: 4 h per PID loop, 8 to 40 h per batch or recipe sequence, 2 h per networked device, and 1 h per communicated tag for every value mapped past the physical I/O list. Inside the 8 to 40 h band, step count and abnormal paths move the number; a 12-step sequence with defined failure handling sits near the middle, which is the 24 h used in the example below.
Count screens by what they hold
The per-point rule bundles an average of 6 screens per project, which covers status screens on a simple job. Screens earn their own line once they carry commands, operator entries and alarm banners. For each screen, list the live values, the commands, the entries and the alarm lines, and tie every object to its tag. Running the tag check that surfaces HMI invalid address errors during the build costs less than finding them at startup. When the floor also needs a plain status board separate from the operator screens, the andon board guide covers where a small screen fits.
Repeated sections: count one set, validate each
Near-identical machine sections earn the biggest honest discount in the whole list. Multiple conveyor discharge lines built the same way are counted as one set of I/O, then copied with an address offset. The copy is fast; the validation is real work. Before reusing a template, compare the instances for unique devices, different interlocks and different alarms. After copying, check every reference in each instance once, and put a per-instance validation allowance in the estimate with its basis written next to it.
Worked example: a 120-point packaging line
The job: 104 digital points, 12 analog inputs and 4 analog outputs, 2 PID loops, one recipe sequence, 2 networked drives, 40 tags shared with the plant system, 6 HMI screens (3 status screens, 3 with commands and alarm banners), and 3 startup shifts.
| Line | Arithmetic | Hours |
|---|---|---|
| Digital points | 104 × 1 h | 104 |
| Analog points | 16 × 3 h | 48 |
| PID loops | 2 × 4 h | 8 |
| Recipe sequence | one, steps defined | 24 |
| Networked drives | 2 × 2 h | 4 |
| Communicated tags | 40 × 1 h | 40 |
| HMI screens | 3 × 2 h + 3 × 6 h | 24 |
| Startup | 3 shifts × 8 h | 24 |
| Total | 276 |
The bases: 3 h per analog point assumes scaling to engineering units with the module's status flags handled; at the 5 h end of the range that line becomes 16 × 5 h = 80 h and the total reaches 308 h. The screen allowance, 2 h for a status screen and 6 h for a command screen, is this estimate's own rate with its basis stated; substitute yours and say so. The startup line covers interlock and E-stop tests, which run under the plant's energy control procedure with their setup time inside the estimate.
Cross-check: the flat guess before this list was 120 points × 1 h = 120 h, and doubling that first guess gives 240 h. The line-item total of 276 h sits 15% above the doubled guess, and the 40 communicated tags are the gap.
Decision: quote 276 h. If the number has to land near 240 h, the negotiable scope is the tag mapping: publish those 40 values on a floor dashboard instead of mapping them one by one, and read live factory data display for that choice; a screen for it comes from our shop-floor signage range.
What to send with the quote
Attach the basis, and the hours stop being a single number nobody can check:
- Point counts by class: digital in, digital out, analog in, analog out
- The function list, each line with its hours and basis
- The screen list, with the per-screen allowance and what each screen holds
- Startup shifts and travel, stated as shifts
- The rates used, taken from the table above
- Every open decision, priced as an option with its own hours
Recommendation: under about 50 digital points with no analog, no loops and no networked devices, quote the point count at 1 h per point, fold in the 6-screen average and add the startup shifts. Any job with analog points, a PID loop, a sequence or a networked device gets the line-item estimate, cross-checked at twice your first guess, with every open decision priced as an option.
Questions
Do the per-point rates include HMI screens and site startup?
The 1 hour per point rule bundles an average of 6 screens per project, and it covers desk work and bench test. Site startup is separate: price it in shifts of 8 hours plus travel, on its own line. Move screens onto their own lines as well once the job passes that 6-screen average, or once screens carry commands, operator entries and alarm banners.
How should I price my first job with analog points?
Use the top of the range, 5 hours per point, and write that choice into the assumptions. Analog modules bring their own status flags, format choices and scaling to engineering units, and the first pass at each of those is slow. Build one scaling block you trust on that job, and the next project prices nearer 1 hour per point.
Should internal bits add hours to the estimate?
No per-bit rate exists. Price the sequences the bits implement: a job with 300 internal bits behind two sequences prices like two sequences. Count the bits once to confirm the controller has the memory, then keep them out of the labor math.
What do I do when the scope is still open at quote time?
Quote the line-item total for what is defined, and price each open decision as an option with its own hours: a second recipe sequence is a number, a third networked drive is a number. Multiplier advice runs 3 to 6 times a first estimate as complexity grows; use it to sanity-check the total, and let the options carry the unknowns.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.