Control Sheet No. 1
In this issue:
As we work with students and hire new personnel, we constantly experience how much it takes, before a new person that is not familiar with accelerators or control systems becomes truly productive and efficient.
And it is not just about the famous proverb »time is money«. An interesting calculation that I want to share with you illustrates that the cost is actually surprisingly high. Let's first define what we mean by cost. Surely, the salary and the company/institute overhead are usually the highest costs. They exist irrespective of whether the person is working or not. But we have hired the person to do work; therefore we are, rather than in pure cost, interested in the efficiency of the person, i.e. in the ratio of output versus cost. To simplify, let's assume that an efficient programmer has a ratio of output/cost of one: we get what we pay for!
Let's take some more simplistic but reasonable assumptions:
- The first two months, the output of the new person is zero. In my experience, the new person just gets acquainted with the environment in the first month, and in the second month he or she gets acquainted with work. This may not be the case for an expert programmer, but remember, we talk about people, new to the field.
- The next two months, the efficiency is 1/4. This is because the person does some useful work, but needs more time to finish it, or just needs to redo work several times until it is of production quality.
- The following months, the efficiency increases linearly every two months by 1/4 until it becomes one in the sixth month.
- From the sixth month onwards the efficiency remains one. This is probably too optimistic, but let's take this as an average over the second half of the year.
- Let's not forget that the new person needs coaching. In reality, there are several people involved, but in our experience, the net effect is one full person in the first month. Then the effort of coaching halves about every two months. Let's assume that coaching is not needed from the 8-th month onwards. The efficiency is thus the output divided by the cost of the personnel doing coaching plus the cost of the new person. To better illustrate the cost, let's draw the inverse of the efficiency, integrated from the beginning, which we call relative cost. The results are shown in the surprising graph below. Note that the relative cost over the whole year is still 2, although the relative cost in the second half of the year is 1. The reason for this is the initial high cost of coaching and the new person being very inefficient in the beginning. This initial inefficiency is further illustrated by the extreme relative cost of 20 in the first three months, and about 6 for the first half year.
What can we conclude from that? I'd say three things:
- »Firstly: when hiring for new jobs, it is worthwhile getting experts, even though they might cost twice the salary.
- »Secondly: once you have trained a person, try to keep him. The cost of losing a person is the cost of training a new one – and we can see now that it is quite a lot!
- »Thirdly: don't use new people for short-term tasks. It is much better to start them on a job that they will be working on for a longer period of time.
When I was asked to write something about the dark side of controls, I scratched my head and started to fast forward through my control system experiences. It wasn’t long before a certain memory popped up. It was four years ago, but from the technology point of view it could have easily been twenty-four years. And it came up every year after that, similar, but never the same. Merely thinking about that, I knew I had it – the control system integration of serial devices.
It seems that the appeal of zeroes and ones on RS232 line is too much for instrumentation vendors to resist when designing a remote control option for their products. The curse of the serial communication lies in its simplicity. You plug one end of 3-wire cable into your device, the other one in the nearby PC and you are ready to give the HyperTerminal a workout – it doesn’t get any simpler than that. Unfortunately it seems that this is the only communication test many of the devices have seen before finding their way to the far end of the control system cable.
The first bit of fun lies in the protocol which is somewhat like poetry; the first time you read it, it makes sense, but the more you think about it, the more you would like to know what on earth was the author thinking when was putting it together. And of course, just like poems, no protocols are alike.
The control system does not just chat with the device; it tries to control it. The process of getting there can reveal the features nobody suspected: instrument not yet ready for the next command (even when saying it is), expecting more time between commands (or less), printing messages when not expected (or vice versa), internal state machine with no clear purpose or documentation etc. Not to mention the always expected exercise in the fine art of line termination. Then, to make things more useful, somebody once said: “Hey, what about multi-drop?”back to previous content