The parent's job, if you wanted to participate, was usually to hunt down the next brick — right type, right size, right color — from the chaotic mass of colorful and random parts that spilled from the box. Many times, I remember wishing the Lego store was nearby (and open on holidays) so I could just buy the blasted part I was hunting. Missing some tiny, unique piece could delay the entire project and become exasperating for my son, the project manager, if you will.
Automation project managers today can get themselves in the same bind. It's especially trying on those projects that will start generating income for the enterprise the minute they're commissioned, and it's your tiny automation part that's holding up the show. Many such parts get themselves a seat on a plane, if they can be located for same-day delivery.
That's why we work so diligently at planning, scheduling and procurement: We're aiming to minimize and, hopefully, eliminate such fire-fighting when the boss or the client is itching to flip the on switch.
Typically, it's the automation scope of the project that's completed last, as a result of having to wait on the heavy crafts and other disciplines to finish the majority of their work before the electrical or instrument specialists can install and interconnect the devices that attach to the process. It's a familiar predicament for most in the field.
Being last poses some unique challenges, and one of the more vexing challenges of our current complex universe of automation solutions is planning or sizing for the proper I/O count. For a while, I/O was showing up in bigger and bigger "clumps" of capacity or points.
Four-channel cards gave rise to eight, and eight begat 16, 16 became 32, and so on. We might select an assortment of cards based on the current I/O count plus some preordained spare capacity, say 20%. The cards could get expensive, especially if they were for a safety interlock system, and you didn't want to strain the project's budget to buy more than you needed.
But what happens more often than we'd like is that the scope changes.
"Scope creep" means someone decides that a compressor needs a spare, another thinks of a measurement or alarm they want, or they determine that some switch or contact closure indication needs to become a continuous, analog measurement. Non-safety I/O can become safety I/O when a hazards review determines an instrumented interlock is crucial to keeping the plant personnel out of harm's way. Scope creep means your original spare I/O gets nibbled at until 20% spare is 0%.
I/O cards acquired monstrous capacity in an effort to deliver less cost per point. If 32 points could share more or less the same infrastructure and footprint as 16, a supplier could deliver capacity for a fraction of the cost per point of its predecessors — and competitors. But on a project, once the 32nd point was wired and spares consumed, the 33rd cost a lot more — essentially as much as a complete new card. Add to this the potential delays and duress caused by having to add this 33rd point in "combat," if you will, and the savings of many points per card were easily eclipsed.
Today, we have access to a growing array of modular I/O that operate on numerous industrial networks, including EtherNet/IP, Modbus TCP/IP, DeviceNet and Profinet, among many others. I think you can find quite a few as you thumb through trade journals like this one. Many offerings have I/O bricks in one to eight channels or more, all of which are interchangeable with one another, some (but not all) snapping onto a usually proprietary bus rail. So when you need two more, you can buy two instead of 32, at a comparable cost per point.
If you have children who like Legos, I'd encourage you to join in the fun, even if you get stuck with the more mundane chores. Meanwhile, at work, you can have some bricks of your own to build with.
