First-off, lets discuss the old school designers. These guys have a solid understanding of mechanics. They have probably read nearly the entire machinist’s handbooks and memorized everything in the 517 mechanical movements book. They understand how to translate any simple application of force into a complex motion. They understand how to fixture a part so that it will not move, and ensure repeatable location all day long. They don’t need a fancy CAD package to tell them when to add gussets or when to beef up a plate. They know what’s machinable because most of them have run the machines they are sending the parts to. The issue arises when the process needs to be more adaptive. Since they are so used to ensuring positive location mechanically and locking down a part, when you look to place a camera on the end of a robot to locate the part and let it float anywhere they may panic. They learned servo motors back when repeat-ability of 1/4in was great and encoders needed to have batteries to keep positions from being lost (some still do!). Any model based position control was done with shifting hard stops. A good portion of these guys are novices regarding any technology. Some have learned enough to drive the CAD software necessary in today’s engineering, however there are still a number of guys handing pencil drawn sheets to college grads to model up for them.
At the opposite end of the spectrum, you have the Controls engineers. This group tends to use sensors to control everything. A square cube may have a sensor at the bottom two corners to make sure its square, a sensor beneath to make sure its flush to the bottom of the nest, and a sensor at the top to make sure that its within tolerance and the part coming overhead won’t hit it for the 1 in 1000 chance that something moves out of sequence. These guys need to develop a program as well, so every action and reaction needs to be documented and covered. They tend to be meticulous in ensuring that every situation is thought of and discussed up from. In large part, this is due to the nature of programming. Software development can’t leave the machine in a state where it won’t continue. Every possible outcome must be handled. No self-respecting controls engineer would be satisfied to turn on a solenoid to a pneumatic valve, then after a timer of 3s elapses assume that the cylinder has made its position and move to the next step. What if safety was tripped? Air pressure was off? Solenoid is bad? Blown seal or broken fitting on the cylinder? Depending on the situation, this could cause some damage. The other side of the coin for this group is unique due to the dual ended nature of the job. Controls is typically the last group on a job, both at the shop and in the field for startup support and debug. This group also gets the bulk of the service calls when the issue is not immediately clear to the end user. Since control logic is invisible, many tend to assume that there is a programming issue. This can be minimized with proper diagnostic fault messages, however once again that is another topic. Many times when a Controls engineer, or a technician working to become an engineer, is called on-site to diagnose an issue, they find a mechanical failure, part tolerance, or model complexity issue that has occurred which was beyond the ability or willingness of the end users maintenance staff to diagnose. This is especially common when a machine is still under warranty, or in lean manufacturing facilities dealing with service parts and retooled equipment. Due to this, the failing of many pieces of equipment gets highlighted. What is not highlighted however, is the path that caused the failure. In some instances, the equipment has been running for 7 or 8 years, and material fatigue has just given way. There may have been a product change that pushed something just outside its tolerance. A surface may have worn down slightly over time until it just didn’t reach any more. It may have been the application of the design rather than the design itself. It may have been improper maintenance schedules. Machining tolerances may be wrong. The point here is that in most cases, there is a reason why it failed. Typically, the controls staff is not in a position to have all the data to analyze the root cause behind the failure. You can end up with an argument that a specific design feature will fail in the field, when realistically it failed because the part placed on it was 5 times larger than it could support. The current application may be sized correctly, and work just fine.
Finally you have the middle ground, the CAD jockey. These guys learned to design in 3d from day one. Most of the time they have a hard time visualizing 2d drawings to make sense of the part shown to them. They are used to the features of the software, and can run stress analysis tools, fluid flow simulations, weight balancing, and load requirements at the click of a few buttons. These guys are typically thinkers with a large imagination who want to find new ways to tackle old problems. They look at everything with an eye for improvement and want to tinker till it’s just right. The problem lies in the job constraints. You typically don’t have the time on the calendar or dollars in the budget to reinvent every wheel. Most wheels have been looked at so many times in so many ways that the likelihood of someone making a better wheel now is slim to none. It’s a bad investment to let people go wild trying to improve tried and true designs. This is what causes the friction with the old school toolies. They view it as insulting when the younger guys think they can do everything better just because they can use the software on the computer. The younger guys don’t have the experience yet to discern what is worth looking into and what isn’t. Let’s face it, the old school toolies have been at it since before the CAD software these guys are using was even thought of! CAD guys tend to underestimate the impact of reality on the 3d world. Customer product will vary not only in tolerance batch to batch, but in presentation depending on the operators on hand. Materials may differ from one batch to the next. Suppliers may change causing even greater differences. Tolerance stack-ups may bring things to places they never expected. Since this group has typically never worked on the shop floor, they tend to overlook manufacturing processes. Someone needs to be able to make the part they just drew! You see a lot of components doweled in place, instead of transfer at assembly. You see provisions for CMM in places that are difficult, if not impossible, to adjust after assembly. Grind spacers and shim packs are nowhere to be seen. All of this however relates to a lack of experience and meaningful feedback.
Now that we know where the problems come from, what do we do about it? The answer lies in one of the most elusive and abstract goals an organization can throw around: communication. You need to be able to look at every scenario through the eyes of each party, and essentially become a translator for them. The CAD jockey truly wants to make a better mouse trap, but they respond negatively when they feel insulted and attacked when focus is given to only the negative aspects of what they’ve done. The controls team wants to minimize time away from home. They want the commissioning and install to go quickly and smoothly, and they want to avoid service calls that have them traveling on the road. To accomplish this, they need to make sure everything is as linear and well documented as possible. The old school toolies want robust, solid machines that will handle whatever is thrown at them. They want them to be flexible enough to adapt to the customer’s product, no matter how far off the CAD it is. They want the process to just work. They want to build on top of the foundation they’ve spent the last 40 years solidifying. They are focused on the product and the process, not the underlying mechanics to get there. They want to just stick with what’s been proven, and avoid anything unknown. Unknowns mean problems. It’s worked for the last 35 years since they had a team of 30 engineers review it and all agreed to make it a standard.