What’s in a name?

The project I am currently working on is the first one where I have had to simultaneously program machines with many other engineers. I have certainly worked on teams before where there were multiple programmers on a line, but this one is unique because there are 15 completely independent machines with similar components but all doing different things. There are probably 8 or 9 controls engineers on the project with more coming into or out of the project at various times. About half are contract and the others are permanent employees of the machine builder.

What I find interesting is comparing the mechanical and electrical layouts of the machines to each other. Last week I had to take time out from my machine and start the program for the one next to it, there are very similar palletizing/depalletizing sections on these machines, but they were designed by different mechanical engineers. The controls designers were also two different people so the approach that was taken on layout and naming of the actuators was completely different. Of course from the customer’s perspective they would like everything to be as similar as possible but so far this is not to be.

I am going to draw on some of my experiences last week to generalize about the way things are named by designers. Of course there is always an opportunity to go in later and rename things to make them consistent, but as these differences propagate through the project this can become VERY time consuming so often things end up remaining as they are.

Actuators:

Extend – Retract
Advance – Return
Raise – Lower
Advance – Home
Rotate CW – Rotate CCW
On – Off

Of course not all of these terms are interchangeable and some are more descriptive than others. Raise and lower are unambiguous and preferred whenever possible in my opinion, the same with Rotate CW and CCW to a degree, but even here you start having an interpretation problem. From what perspective are you looking at the rotation? OK, from outside of the motor or cylinder axis rather than the shaft side. What if there is a belt or pulley that reverses the rotation of the tooling? What if the actuator has two shafts? Hmmm…

Advance – Return
Extend – Retract

These are pretty much redundant so its easy enough to say let’s just pick one. Now: are we talking about the movement of the actuator or the tooling attached to it? Most people choose the tooling movement and I prefer this also. On this project the company has even gone farther in defining that the motion is described as the movement of the tooling with respect to the product that it operates on. This is still open to interpretation if the tooling moves between two products.

Another naming convention this company has adopted is calling the motion opposite of advance or extend “home”. I have a problem with this as it is easily confused with the home routine which may actually home the actuator to the extended position. Mechanical and electrical designers often don’t know or don’t think deeply enough to make this decision early in the project. Often it is left to the programmer and drawings don’t always get properly updated if there is a time constraint.

Another aspect of naming is the description of the device or mechanism itself. As an example the two machines I mentioned before had the following differences for the same component:

Lifts – Fingers
Indexer – Shuttle
Locators – Clamps
Pre-Stop – Entry Stop
Elevator – Lift

Now since I have to make the program naming conventions the same, I changed the second machine to the names of the first. The problem is there are many CAD drawings already printed and out on the floor and the designers have moved on to other projects. This is where red-lining comes in, but I am not sure these always get changed on the final drawings before the machines get to the customer. Since I am contracting I don’t have much control over this but to be sure I always try to at least make recommendations and opinions known.

Much of this can be avoided by proper defining and planning on the front end. Templates can also help here along with documentation of company standards. Another technique I personally like on large projects like this is assigning a champion for each machine sub-element: as an example each engineer gets assigned from the following parts of this current line:

Robots
Vision Systems
RFID Readers/Writers
Conveyor Traffic Control (stops, lifts, etc.)
Loaders/Palletizers/Depalletizers
Torque Drivers/Screw Drivers
Safety Circuits
System Control (Auto, Manual, Homing, Cycle Start/Stop, Cell and process interfacing, etc.)

Again templates can help here, but if nothing else there ends up being one central arbiter or decision maker for each technique. This costs a bit more time on the front end but can save a lot and help build a better product at the end. Of course it also opens up room for lots of disagreement on the way things should be done, but politics is a topic I choose not to discuss on this blog 😀