Living Life Backwards on the Romance Car Express

Ever since the very first time I visited Japan, nearly three decades ago, I've wanted to travel on the Odakyu Line's Romance Car Express. They have these really cool trains with the driver's cab 747-like on the roof, so passengers in the first car have a panoramic view of the track ahead. And how could you resist the name? I've even contemplated travelling the length of the line just for the sake of it. On a recent trip I finally had a reason. We were travelling to Hakone, for a stay at a traditional Japanese inn (ryokan) and to do some autumn leaf spotting, and the Romance Car is the ideal way to get there, in fact the only direct service from Tokyo.

So we went out to Shinjuku station, supposedly the biggest station in the world if Tokyo hasn't overtaken it by now. Tickets are only available from machines, and while I suppose I could have figured it out in the end, I was very relieved when a helpful member of staff showed up and guided me through the whole thing, including buying the special all-inclusive Hakone Tour ticket. This kind of extraordinary personal service only happens in Japan. I chose our seats in the very end part of the Romance Car, and off we went to catch our train.

All passenger trains in Japan have the locomotive built in, from the Shinkansen down to the humblest one-car rural train. That means they're symmetrical - the front is the same as the back. And in the case of the Romance Car, that means there is an observation car at the back as well as at the front. And guess where our seats were... the booking system doesn't warn you that your view will be of the track receding behind you.

The view of course is exactly the same. But - which I hadn't expected - there's something very surreal about seeing the world zooming away backwards behind you. After a while it begins to feel like your whole life is running backwards. The journey only lasts about 90 minutes. If it lasted for several hours, I'm sure you'd start to get younger, eventually becoming the little boy in short trousers whose Dad used to hold him on the bridge parapet to watch the trains go by.

The most surprising thing is the level (grade) crossings, of which there are a great many. They open within seconds of the train passing - whereas they close much earlier, for safety. So as soon as you pass, the barriers open and - Japan being a crowded place - cars, bicycles and people flood across the road.

On the way back we bought regular tickets for a car in the middle of the train. We weren't sure we could take the Living Life Backwards experience again.

Business Meetings in Japan

If you're used to doing business in the US, business meetings between Japanese companies seem very strange at first. In the US, a meeting generally lasts several hours and is planned well in advance. The discussion is focussed, with an agenda and a deliberate progression towards a conclusion. At the end, though there are generally no formal minutes, there are action items and agreements. You know what you've achieved, whether it was a lot or a little.

When I first started working closely with my Japanese colleagues, I just couldn't understand what was happening. Meetings, even at a high level, can happen at short notice. They're rarely longer than an hour. And at the end, as a Westerner you have little idea what has been discussed, and no idea at all what has been concluded. It's just like a cosy chat amongst old friends. Very often, it's not at a formal conference table, but sitting in armchairs around a low table. For this reason I call this meeting style the "Fireside Chat".

An OL ("office lady", a kind of general administrative assistant, invariably female and fairly young) brings in drinks - hot tea in winter, cold barley tea in summer. The head people from the respective teams start a conversation, others join in occasionally, showing due respect. At the end one of them looks at their watch and says, "ah, I think it's time to finish" (actually what they say is a lot less explicit than that). Everyone stands up and files out to the elevator, performs the ritual elevator bow, and the visitors depart. "What was that all about?" you're left thinking to yourself.

Since business does get done in Japan, just as effectively as anywhere else, you can't help wondering how this works. Of course the well-known Japanese dislike of conflict plays a part. But there are as many reasons for business partners to disagree in Japan as there are anywhere else - price, specification, availability, all that stuff - yet they evidently do get resolved somehow.

In the end I realised that geography has a lot to do with it. In the US, such meetings typically involve a plane journey, often an overnight stay. They're expensive and it's important to get the most out of them. In Japan, most large companies have their offices in Tokyo. It's rare that it takes more than a half-hour taxi or subway ride to get there. So meetings are cheap, and you can afford to do them quite often. They don't need to be so focussed, it's OK to let things kind of evolve naturally over several of these apparently rather loose discussions. That coupled with the natural Japanese way of doing things just leads to this completely different style.

Of course, as with everything in Japan, it may be that I've missed the point completely.

boost serialize - not such a good idea!

I'm a big fan of the boost libraries for C++. Mostly, they are a huge productivity gain - things like regex, function and bind can reduce the work involved in a complex program by half or more. So when I needed to pickle a very large (gigabytes) and complex data structure between restarts, boost was the obvious place to look.

Boost serialize certainly looked like the answer. Just add a few lines to each class saying what you what to save and restore, then with a single function call, you can pickle the whole structure and later reload it. It takes care of loops, diamonds and all the other things that happen in real-life data structures. And if you don't like the default way of saving something, it's easy to write your own. How good can it get!?

Well, that's the theory, and it could have been the practice too. But it isn't. For some reason known only to themselves, serialize's authors decided that the C++ inheritance mechanism wasn't for them. They invented their own completely parallel mechanism for dealing with polymorphism and subclasses. The effect is that trying to save my structure results in an exception thrown from somewhere in an enormous depth of function calls. I persevered, and tracked down what was happening. For some reason - and it's just impossible to plough through all the code and figure out the details - it silently ignores some of the calls to the subclass registration process. After several days of trying to figure out the details - on a live application because that's the only place the data can be collected - I have finally given up. I'll live without this capability in my program.

Unfortunately this is a common problem with boost. It seems to be de rigeur to invent new ways of doing things even though they are more complex and don't work especially well. The build system is another case in point - instead of using make, known and hated by generations of programmers, they invented their own, bjam, which is unknown and incomprehensible. If it works for you, great. If not, forget it.

I'll carry on using boost, but you do have to be selective. Unfortunately.

More thoughts on Boost here.

Divisumma, the Star!

A few weeks ago I got an email fom someone saying, in essence, "Can I come round and get some pictures of your Divisumma please?"

I was surprised, especially when I discovered he was coming from Detroit - I would have thought there would be more around than that. He is making a video about architecture for Yale, and had been specifically asked to include some footage of the Divisumma. He'd evidently had trouble finding one in the US but - thanks to this blog - he found mine.

He came by today and spent half an hour or so in the sunshine, shooting very close-up footage of the keyboard and the case. And, when he's finished putting it together, Divisumma will be a movie star!

Halfway to Upside Down

When I started this blog it was with the intention of writing regularly about aerobatics - hence the title. But you know how things are... I got involved with learning to fly the heli, which dramatically reduced the amount of acro I fly.

But today I flew the Pitts, and I took my camera with me. It's hard to take pictures of aerobatics while flying solo, I can tell you - trying to fly a tricky manouver left-handed while holding the camera with the right and trying to get it to focus on the right thing.

I did however manage to get a nice picture of a knife-edge. That's when you hold the airplane in a 90 degree bank, which means that the wings aren't providing any lift. So the only way to maintain altitude is to hold a very steep fuselage angle and let the fuselage provide the lift, which means LOTS of top rudder - in the Pitts S2C, full top rudder. Of course the drag is huge, so you slowly lose airspeed and eventually you will fall out of the sky. But you have long enough to take a nice pic, like this one.

Full size photo, and others from the same flight, here.

BBC News RIP

For years I've got my daily news fix from the BBC news site. It was well arranged and would give instant access to the top world stories and, when I was feeling nostalgic for good ol' blighty, the UK. There were always a few interesting tidbits. And it was free, too.

Then, a few months back, some genius in marketing (I presume) decided that the page needed a New Look. Ever since, I just can't find any news on it. It's not just me, I have a colleague (Iranian) who has exactly the same feeling. Somehow, they just messed it up. I guess all the same news is still there, but it has lost its interest and salience.

Today I signed up for a subscription to The Times (the London one). Goodbye BBC news. I'm sorry to have lost a friend.

Flying under the Golden Gate Bridge

I did it! On Sunday we flew the helicopter under the Golden Gate Bridge. It was pretty exciting. The picture shows us just approaching the bridge from the east. We're at 100 feet, about half the height of the deck.

The sight-seeing operators do this all the time. I was astounded when I first saw the red Jetranger that does these flights around the city zoom under the bridge. It's quite legal. There's a special exemption to the regulations that allows helicopters to fly pretty much anywhere without the distance requirements that apply to airplanes. (Take a look at FAR 91.119 if you're interested).

I'd discussed it with my instructor a few months ago. The plan was to fly through the SFO Class B airspace up to the city, under the bridge, then back again by the same route. Unfortunately though, since the incident earlier this year, SFO Tower is being much more cautious about Class B transitions. During the busy part of the day, they are generally not available. And indeed that's what San Carlos tower told us . Our second plan was to cross the hills at route 92 over to the coast, and go round the Class B. Although it was cloudy, there was plenty of room under the clouds to do this.

But then San Carlos handed us off to Norcal Approach, who cleared us through the Class B at 3500 feet. I've been given this transition before and it works well. Sometimes you have to ask for it, a bit like Special VFR. So we climbed before we got to the clouds, flying over the undercast and also the SFO departure corridor. It was very pretty, the airport and the city were both visible through gaps in the clouds, although I didn't manage to get a decent picture.

Then a very rapid decent once we were past the Class B surface zone, down to 700 feet and ready for the big adventure. We went over the south end of the bridge, slowed right down in a left descending turn, and at a stately 40 knots or so passed under the bridge at 100 feet. It was over all too quickly.

Although it's perfectly legal, we were both a bit nervous that people might react badly, so we climbed well away from the bridge, back over the south end, and then across the Bay to Oakland for the transition back south.

More pictures on Flickr.

Audrey Hepburn and the Eiffel Tower - twice!

There are two movies that feature both Audrey Hepburn and the Eiffel Tower (well, I suppose there could be more). One is well known and you will find it by googling those two subjects - Funny Face, one of her hallmark movies. It's a great movie, which we saw at the Stanford Theater last night. (One of the really nice things about living near Palo Alto is this movie theater, lovingly and expensively restored and specializing in classic movies, mostly pre-1960).

By coincidence, we had watched the other one the previous night at home. Any guesses? It's the Lavender Hill Mob, one of the greatest of the British Ealing comedies, from 1951. The main characters are Alec Guiness and Stanley Holloway, with other classic stars from the time like Sid James and Sidney Tafler. The Eiffel Tower has a central role in the plot, including a fantastic scene where the two heroes run down the emergency staircase. And Audrey Hepburn? In 1951 she was still an unknown. She has a tiny walk-on part at the beginning. You wouldn't recognize her unless you were looking. It was only when the closing credits rolled by that I saw her name.

Going back to Funny Face, there are some wonderful period-piece scenes. For avaiation fans, the scene of the TWA Constellation taking off is enough to make the whole film worthwhile. Then they land at Orly, where on short final they fly over Notre Dame and the Champs Elysees. Funny, this never happens when I go to Orly.


Another great detail is the Isetta, a 1950s "bubble car". It's a weird little thing, with a single door which is also the front of the car. For the movie they gave it a funny pweep-pweep horn, which the real thing didn't have.

o hisashiburi desu nee!

Just looked at my blog and realised it's months since I wrote anything. (The title is Japanese for "it's been a long time, hasn't it!"). A lot has happened in that time. I got a wonderful hexapod (six-legged) robot from Micromagic Systems, with lots of intentions to write software to do all sorts of clever things. I figured out the math for how to make it go where I want to, which involved re-learning a lot of things that I never really learned in the first place, like matrix math. I got a lot of code written, too.

But then real life intervened - I gave myself a new work programming assignment, and I really can't do two big, new pieces of software at the same time. So I haven't touched that in several months.

The maze solver got put to one side when the hexapod showed up. I'd realised that you just can't track the rotation angle of the 3pi by monitoring the motors. So I had to make the compromise of requiring mazes to always have 90 degree angles in them. I started to make the necessary software changes when, again, real life got in the way.

Then we went travelling, first to Japan where we had the immense good fortune to attend a friend's traditional Japanese wedding, then to France on holiday.

I'm still flying - I've got (at least somewhat) back in the groove with the Pitts, and I fly the heli once a month or so. My precision autos are getting better, and there are times when I think that autos are the most fun you can have with or even without your clothes on. (Maybe that's just a sign of advancing age though!). I've also started work on my CPL-ASEL (commercial license, that lets me get paid for flying, should I find anyone willing to do so), though that hasn't gone very far for all the above reasons.

The Divisumma still sits on the corner of my desk, with its very attentive operator. It still seems to be working.

And that's about it, four months of my life summarised in a couple of paragraphs. Hope to get time to keep this blog a bit more up to date in the next few months.

Robots: Pololu 3pi

In the last couple of months I began to get a bit frustrated, technically speaking. The big programming project that I've been working on for the last year has finally come to an end - now we need to find some customers for it before we decide what to do next. So I scratched my head and decided that maybe it would be interesting to find out more about robotics.

A week later I'd read a lot and decided what I wanted to do to get started. I sent off an order to Trossen Robotics (there are of course quite a few suppliers, but these people seem to have a very good range) for a few bits and pieces from the Phidgets range, which are a great way to do robotics direct from a regular PC. I also ordered a Pololu 3pi, to get some quick experience with embedded programming. The 3pi is a small, round (10 cm across) robot made for following lines, with two independently-powered driving wheels, some infra-red sensors to see the lines, a microcontroller, some buttons and LEDs, and a tiny display.

I was amazed by how easy it is to work with the 3pi. I've never done anything with tiny microcontrollers before - my day job involves embedded programming too, but with a 400 MHz PPC with 1GB of memory, comparable to a PC. The 3pi has an Atmel 328p, which has 2 KBytes of DRAM and 32 KB of flash to hold the program. Compared to the PDP-8 I worked on in 1973, this is luxury. But when you're used to writing complex frameworks in C++ with Boost, it takes a bit of a mental gear-change.

Atmel provides a really excellent C compiler, actually GCC, and an IDE, loosely based on Visual Studio. It takes less than half an hour to download and install them, download the examples from the Pololu site, and be up and running. Then it was off to Office Depot (which I hate - never shop anywhere with "Depot" in the name - but they are just around the corner) for some paste board and black tape. Within a couple of hours I had my 3pi running round mazes, using the sample code.

"Every schoolboy knows" that if a maze has no loops in it, you can solve it by just turning left (or right) at every opportunity, until you reach the goal. So the interesting challenge is to solve mazes that do contain loops. The wall-hugging strategy will never actually get stuck in a loop, but it won't find the goal either, except by chance. (Actually it does kind of loop, because eventually it gets back to the start of the maze, and since it can't recognize that, it just starts over).

Solving looped mazes requires knowledge of absolute position. (If you have a useful upper bound on the size of the maze, I believe you can do it without such knowledge, but it's a lot harder to figure out how, and will take a lot longer to find a solution). If you know where you are, then you know when you reach an intersection you have already been to, assuming you have enough memory to keep track. (Remember, only 2 Kbytes of DRAM). The 3pi has no explicit position measurement, not even encoders on the motor shafts. The only way to track position is to integrate the motor speeds. It took me about a week to come up with working code to do this. It would be much easier to do in floating point - but the cost in both code space and computation time is unacceptable. I absolutely hate doing scaled integer math, it's a constant trap of overflows and underflows and just plain getting it wrong. But it's the only way.

Once I eventually got the code to work, I was surprised by how little of the available compute power it took. According to the simulator that comes with the Atmel IDE, keeping track of position every 10 mS takes about 0.5mS, i.e. 5% of the CPU. That's good, because it leaves plenty for doing other things, such as following a line, and keeping track of the maze structure.

Although the IDE includes a simulator, in the end I had to get the code working with Visual Studio as well, so I could get a "brain dump" of the computations at every 10 mS interval without having to step through them with the debugger. It's very easy to do this - just create Visual Studio and Atmel IDE projects in the same directory, and they work off the same source files. Of course a few #ifdefs are required to get things to compile in both environments.

One complication I ran into is that the motor speed response is not linear with the applied voltage - which is not a surprise. At lower voltages, a greater proportion of the power is used to overcome friction. Also, the two motors are not absolutely identical, so if you apply the same voltage to both of them, the 3pi gradually curves around. I wrote some code to calibrate the motors, which for the moment is a manual process although it would be a lot better to automate it. With the motors calibrated, it looks as though it should be possible to get a position estimate that is reliable to within about 1%. That should be good enough for mazes up to a couple of meters across.

That's about as far as I've got, at the moment. I'm now in the middle of writing the code to actually solve the maze. This is logically tricky but at least it doesn't involve any fixed-point math. More on that later, if and when I get the whole system to work.

Divisumma Diary - It Works!

The Divisumma has been sitting on a corner of my desk in full working order for a couple of weeks now. There's a picture of it at the bottom, complete with case and very attentive full-time Divisumma Operator.

Progress since the last posting involved several more variations on the Battle of the Springs, and a lot of lubrication. The problem with springs is that they age, losing some of their strength. Replacing them with new springs is a risky business, because in many cases the exact strength of the spring is important.

I mentioned before the problem that multiplication sometimes gave the wrong answer. At the same time, I noticed that the key that allows you to transfer the result of a multiplication to the multiplier register - for example when computing powers or strings of products like 123 x 456 x 789 - no longer worked.

The Divisumma uses a clever trick to speed up multiplication. If it needs to multiply by 4 or less, it uses repeated addition. For 5 or more, it instead adds an extra one to the next digit, then subtracts. So to multiply by 9, it subtracts once, then adds an extra one to the next digit. If you multiply by 99999, it only performs two actual arithmetic operations, effectively multiplying by 100000 and subtracting 1. The effect is to halve the time to multiply, on average. As you can imagine, the mechanism to do all this, purely mechanically, is frighteningly complex. As ever, I'm lost in admiration for the designer of the machine, Natale Capellaro.

The error in the multiplication could be explained if in certain cases, a value was added instead of being subtracted. To cut a long story short, the problem turned out to be where I had replaced a spring, the long spring 277 from the Battle of the Springs, by a stronger one. It completely solved the problem there, but unfortunately the static end of the spring is not really static, it's a little hook on the end of something that moves. The stronger spring was holding it a fraction of a millimetre away from its correct resting position, and that was enough to block two pieces of the machine: the lever that decides whether to add or subtract, and the lever that causes the multiplication result to be transferred.

So I had to revert to the original spring, and solve my Battle of the Springs problem another way. The service manual says that in certain cases, to get things to work, you should "act upon" various cam followers and the like. So indeed I "acted upon" the little lug 150a, until it stayed out of the way of lug 286n when it was supposed to. It's now twisted quite a lot, I'm sure more than the spirit of "acting upon" would demand, but the machine now works.

Another spring problem caused an equally odd problem. Sometimes, an add or subtract would trigger a total operation, wiping out the value just entered. Curiously, this was related to the length of the number just added. If it had just one digit, the problem didn't happen. If it had 12 digits, it always happened.

The immediate cause of the problem is the mechanism for printing the result of a multiplication or division. This uses the total machinery, and it does it by pulling down the total key at the end of the cycle. It's almost as if a big arm reached out of the machine and pressed the button down. The arrangement for triggering this is amazingly complex, with flimsy levers that run the whole length of the machine. It turned out that the mechanical shock to the machine when the digit carriage was restored, was just enough to trigger one of the pieces of this.

The mechanical stresses in the machine are pretty high. There is very little time to restore the digit carriage within the overall quarter second or so main cycle - maybe 50 milliseconds, to move something quite heavy through 5 centimetres or so. So when it hits the stop, it is moving fast and there is a lot to absorb. Designing these machines to work reliably, considering everything that was going on, was a lot harder than just getting one to work on a bench in the lab.

Anyway, the fix in this case was just to use a new, stronger spring. Problem solved.

Then it was time to put the machine back in its case. The first step was to replace it on the steel base. It hadn't been too hard to get it off - there are just five bolts that hold them together. But getting the holes lined up again was nearly impossible - they have to be correct to within less than a tenth of a millimetre or the bolts just don't engage with the nuts. And two of these bolts are completely inaccessible. Luckily I had just bought these bolt-handling tweezers from Micromark, which were exactly what it took to weave the bolt through the levers and get it to the right place. Even so, for one of them I had to hand-turn the machine to a certain point in a division cycle, to move a lever out of the way and give me access. I can't imagine how they did this assembly in the factory, there must be a trick that I missed.

After that it was just a matter of putting the case back on, cleaning things up, replacing the ribbon, and now I have a perfect piece of retro-computing sitting on my desk. I even use it occasionally, instead of firing up the Windows calculator.

Flying the Helicopter

It's been a long time since I wrote anything about the heli. I've been flying it generally about once a month since my checkride. That means training and currency flying - apart from the one flight with my wife, everything has been with my instructor. And that means lots of autorotations. They're one of the most fun aspects of flying helis anyway, plus you need to be good at them in case the engine ever stops.

Most practice autorotations are done down to the flare, about 10 feet above the ground, and then you re-apply power and fly away, or hover. That's because the greatest danger - mainly to the aircraft - is in the very final phase. But if it ever happens for real, you need to know how to get the last bit right too. That's called a "full down auto", when you actually land. I've done quite a few of those, my instructors hands poised ready to take over in a heartbeat if necessary. But actually the last couple I've done have been fairly good, resulting in a gentle touchdown and a short roll-out, or I suppose it would be more accurate to call it a scrape-out, considering the absence of wheels.

Another variation on autorotations is the 360 degree auto. This is what you would have to do if you had just flown over the only viable landing spot in sight. Chop the power, then execute a steep (30 degree or more) banked autorotating turn, keeping a sharp eye on rotor speed, airspeed, altitude, and the outside world, all at the same time. The trick is to touch down exactly under the spot where you chopped the power. Let's say I'm getting there.

And then last weekend, something completely different. We've been talking about doing a mountain checkout for a while - we had it arranged a couple of months ago but on the day it was snowing hard in the mountains. Last Sunday, the weather was perfect, so two of us together our instructor flew up to Tahoe, then on to Reno and Truckee before returning home. I flew the outward leg, about 90 minutes from Palo Alto, first in a straight line to Jackson and then following Route 88 up to Kirkwood before cutting across to the pass and then a steep descent into Tahoe. Much easier in the heli than in the plane, where you just about invariably end up flying out over the lake to lose altitude. It was a beautiful flight, with the unparallelled visibility that you can only get from a heli.

We had the heli deliberately loaded up to gross with some ballast, so we got to feel what a high-altitude take-off and landing is like. Also, at altitude you need to watch power carefully, since the limit is lower there. But overall it was fairly straightforward. We went on to Reno, and then I flew the leg from there to Truckee. And learned something important.

In an airplane, your take-off options are limited. You use a runway, and there aren't many of them, and the tower always tells you which one to use. It's something they take seriously! But a heli is capable of taking off from anywhere you like - the ramp, a runway, a taxiway, the grass - and most towers are happy to let you do so, as long as they approve it. But at Reno we ended up with a misunderstanding - the tower expected me to do something different from what I actually did. Nothing bad happened, and they were nice enough about it, but it was an excellent lesson. In the heli at a towered airport, always make certain that what you are about to do is what the tower is expecting you to do.

Flying around Tahoe was a great piece of heli-tourism too. The views were wonderful, especially on the legs where I was sitting in the back, and could take some pictures. Here are a couple to be going on with while I get them all organised and onto Flickr.

Divisumma Diary: A Little Lubrication

My Divisumma worked, somewhat at least, straight out of the carton. With some very minor attention, it briefly performed all four functions, despite sitting unused in a cupboard somewhere in Italy for probably three decades or more. Not everybody is as lucky. There's an excellent article here (in French) about the restoration of a Tetractys, the Divisumma's big brother (with practically identical internals). The author describes all the lubricants as having gummed up to the point where he had to clean and relubricate it extensively before it would even do basic addition.

I asked a couple of people how best to lubricate the machine, and they both recommended the same thing: AeroKroil. So I sent off for some, and a few other products from the same source while I was at it. Meanwhile, my Divisumma was not working very well at all, culminating of course in the catastrophic jam. There seemed to be no lubricant present, except some dark, dried-out grease in a few places.

When the AeroKroil showed up, I squirted tiny amounts of it into every bearing I could find. What a difference! It was now much easier to turn over by hand, and seemed to run smoothly under power as well, although after The Jam I had become very reluctant to use the motor anyway. I also came across an article in Italian which, after Google translation, said "Lubrication life is entrusted to 4 types of lubricants, each optimized for the kind of friction generated in the appropriate place: dense oil, fat, low viscosity, fat infusions and grease molybdenum disulfide Molykote.". This seemed like a mistranslation - it's hard to imagine them using lard - and indeed it turns out that "grasso" is Italian for both grease and fat. However there's still no indication what the "low viscosity fat" and "fat infusions" actually are. Molykote seemed easier to track down, but there's a bewilderingly huge variety of greases under this name. Also, since it's an industrial product, most suppliers want to sell it to you in 20kg drums or packs of 10 tubes. Luckily I found this supplier. Perusing the list, the BG-20 grease seemed about the best fit, so I sent off for some of that too.

At the same time I was dealing with the machine's various other caprices and dysfunctions, such as The Battle of the Springs. Finally, the Molykote showed up. I spent an hour or two applying tiny beads of it on the end of a nickel spatula (the extremely useful result of the two weeks I spent studying Chemistry at university) to everything that slides - all the cams, the various sliding bearings, and of course the motor and its gearing. That, and plenty of AeroKroil, have made a huge difference to the smoothness of things. One little indication: if you've ever used a Divisumma, you may have noticed that at the end of every operation it makes a gentle "clunk, clunk" noise. That's the one cam that turns directly off the motor output, not through the clutch, bouncing as the motor runs on. When I first got the machine, I barely got three clunks. Now I get eight or nine - an indication of how freely it is now running.

There have been plenty of other little adventures too. For example, for a while when it multiplied, it would sometimes add two to the value of the multiplier - so 9x1 was 11, and 7x1 was 9. I figured it must have been a feature for working with sales forecasts. It's fixed now - it turns out to have been an improbable side effect of The Battle of the Springs. I'm sure you can't wait to read about it.

The Upgrade: Help! I can't get help!

Now that my VPN problem is solved, my Windows 7 system seems to be working reasonably well. I still can't find the IE cache, or rather I can find it and some things are there but a lot of other things aren't. And videos always start jerkily in the first few seconds, but then they get smoother. All of this is survivable.

But I did come across yet another "what were they thinking" a few days ago. I have quite a lot of old software on the machine - my very own Winlife32, dating back in its origins to 1992, for one. I have a version of "Corel Essentials" that I bought nearly ten years ago. I don't use it enough to justify going and spending $100 on a newer version, but it's handy when I do need it. PhotoPaint is an OK-ish inferior version of PhotoShop, with the great advantage compared to PhotoShop that I know how to use it. And CorelDraw is absolutely indispensible for making jam labels. So the other day I needed to annotate the pictures for my Divisumma Diary. I wanted to draw some arrows on them, which ought not to be difficult to do, but I couldn't find the trick. For once Google was no help, so I was driven to the ultimate recourse, the documentation. Or rather, since there isn't any, the online help. So I clicked the help button. And my brand new Windows 7 system said "I don't know how to open this file", or words to that effect. It turns out that brand spanking new Windows 7 can't open those crufty old fashioned .HLP files that came out with Windows 3.1. Which is a major pain if you have applications that still work that way, like my Corel stuff or indeed Winlife32.

Ah! But then there's an option that says "would you like to download WINHLP.EXE for Windows 7?" So I said yes, and was led through a maze of twisty little web pages, until I got asked which of several files I wanted to download. There was no basis for choosing, and the one that looked most likely (it had 32 in the name where the others had 64) downloaded then said, "this program will not run on your system". Eventually random selection found the right one. And then Corel help worked fine. So does WInlife32 help, although I have now discovered that the API it uses for drawing doesn't work on Windows 7 or Vista, so I guess I'll have to figure out what gratuitous change Microsoft has made there and figure out the fix for that.

So, some genius in Redmond decided that although there's a perfectly fine version of Winhelp that runs on Windows 7, and there are undoubtedly thousands of old apps out there that want to use it, they wouldn't put it on the (huge and bloated) distribution. Instead you have to go through an arcane process to download it, whereupon it works fine. What were they thinking???

Oh, and it turns out that there is no way to draw arrows with PhotoPaint, at least not the version I have, short of drawing the heads by hand, line by line. By the way there's also no way to draw a simple oval line with transparent fill, such as you might put around something to draw attention to it. I guess maybe I really should get one of the cheaper flavors of PhotoShop.

The Divisumma Diary: The Battle of the Springs

Last time, I had just managed to repair the disastrous jam which tore out a tiny rod deep in the heart of the machine. With much patience and ingenuity, I'd finally got it back in place, and the machine briefly seemed to work. Since then, it has spent a lot more time not working than it has working. Currently, everything is fine except that, like a math-phobic small child, it refuses to do divisions.

I spent a long time dealing with a problem which is really a great illustration of why these machines were so fiendish to service. I'll call it "The Battle of the Springs". The picture shows the two protagonists, and the second picture is a closeup of the actual battlefield, which as so often is far from the comfortable homes of the instigators.

First, a little Divisumma anatomy. Everything that happens in the machine is driven by the main camshaft. In one machine cycle (about a quarter of a second) it turns round once, and drives a single basic operation such as an addition or a subtraction. Exactly what happens depends on which key was pressed to start the cycle. Well, that's almost true. For the total and subtotal functions, there's something called the "extra cycle" which happens prior to a normal machine cycle, to preset various things. It arranges for the printer to leave an extra blank line and print in red, it disconnects the keyboard from the internal operation of the machine, and a few other things. Incidentally, it's the machinery for the extra cycle that causes the "clonk, clonk, clonk" that you hear at the end of every operation.

Another piece of the Divisumma's anatomy is the "memory", the place where quotients are built up during division, where the multiplier is held for multiplication, and which can also be used just to store an intermediate result. This register has a very different physical structure from the normal arithmetic register. It lives at the back of the machine, behind the "executors" which move values between the keyboard, the arithmetic register, and the printer. Some operations need to place a value into the memory, while others need to retrieve a value already there.

And now finally to the battlefield. Operations which need to read the memory value initiate this by releasing the long lever labelled 286 in the picture, so that it can be pulled towards the back of the machine by the spring 277. (The numbers come from the Olivetti service manual). That movement ultimately results in the vertical racks of the memory register being moved into contact with the executors at the right time. Because this is a bit like a total, in this case an extra cycle is performed, and the movement of lever 286 is permitted by the extra cycle machinery, which among many things moves forward the little tab 276m.

With me so far? But there's one problem with all this. This is just a normal operation, so although the result is to be printed, it should not be in red or have double spacing, which the extra cycle would normally do. It's the little tab 150a which, when it drops down, causes these things to happen. 276m moves forward in the extra cycle and 150a drops down. By happy chance, all these things are in the same place. So all that's needed is that when lever 286 moves backwards, the little lug 286n slides under lug 150a, which can no longer drop down, and the value is printed normally. Perfect.

Except that this is actually a race between two springs. The long spring 601 pulls 150 down (gravity could do the trick, but nothing in the Divisumma depends on gravity. It will certainly work on its back, and quite probably upside down too, although I haven't tried it). Meanwhile the short spring 277 pulls 286 backwards.

It's probably about time I told you what problem I was actually having. Sometimes, when I pressed the total key, I got a value of 999999999999, and the current value wasn't cleared. As you can imagine, it took quite a lot of tracking down to figure out what was happening. And as you can guess, I ended up in the Battlefield of the Springs, which is a long way from anything else to do with the total operation. And here's why. When 276m moves backwards, lever 286 has to follow it, and stop 150a dropping down, before 150a makes any movement. If it doesn't, 150a effectively wedges 286n and stops it moving. The result is an impasse - 150a doesn't drop, but also 286n doesn't move backwards. That means that the memory operation doesn't read the memory, but it also stops lever 286 from being fully restored to its normal position. And, via some other complicated linkages, this also means that the total function remains disconnected from the arithmetic register. So the result of this contest of strength is that the machine simply stops working. It just takes one tiny movement of lever 286 to put everything back where it should be, and the machine will work normally again. But for the office worker in 1960, her precious Divisumma was broken. Time to send it to the men in brown coats. You can see why there were so many of them in those days.

Those readers who are following this with the service manual in hand (admittedly improbable) will have noticed that I've diverged slightly from the straight and narrow here. I've commented before on how excellent these manuals are, but in this case Homer nodded. There is no spring 601 in the manual! And lever 150 is really lever 150', and it doesn't have a lug 150a! How can this be? What I think happened is that Olivetti enhanced the original double-spacing mechanism, which was much simpler, but my manual reflects the older design. The web has a surprising number of pictures of the insides of the Divisumma 24, and they all the seem to be the same as mine. This is a problem though, because nothing describes exactly how all these extra pieces are meant to work together, so it's largely guesswork.

Now that I'd finally diagnosed the problem, what could I do about it? The apparent reason was that spring 601 was too strong compared to spring 277, so the obvious thing to do was to put a stronger spring at 277. However I didn't have any suitable springs. I sent off for a pack of 200 small springs (lots of people sell this kit but I'm pretty sure they're all the same one), but while I was waiting I thought, it doesn't actually matter whether the total is printed in red, so why not just stop lever 150 from dropping at all, ever. So with a piece of wire I fixed it to a convenient place at just the right height. That was a real mess! It turned out that the place I fixed it to also moves, and that was enough to mess things up completely. I'd broken one of the Divisumma cardinal rules, which was to forget just how incredibly inter-related everything is in this machine. Lifting lever 150 a bit too far put it in the way of something else, and almost nothing worked correctly.

When my box of springs showed up, I eagerly replaced spring 277 with something stronger. I carefully turned the machine over by hand, and as the extra cycle did its thing and lug 276m slid forward, lever 286 gracefully followed it, preventing the evil tab 150a from dropping down into its path. YES!!! Problem solved, through ingenuity and creativity. How happy I was!

Briefly. Because after that, the total stopped working again, intermittently, but differently - instead of showing all 9s, it would show some apparently random value. That was when I discovered inertia. What happens is this. When the memory read cycle is over, the extra cycle machinery gets put back into its normal position, which means among other things that lug 276m gets pushed forwards and hence lever 286 also. This should restore it to its normal position. Visually, it does. But it just doesn't go quite far enough to latch in place. This leaves it free to move forwards during a total cycle, ultimately resulting in the memory register being engaged. The actual effect of this is that each digit, as printed, is the lower of the value in the memory and the value in the register. It isn't obvious to figure this out!

This time, the problem was that spring 277 was too strong. It turns out there is a tiny gap between the two lugs 276m and 286n. With the original spring, there's enough inertia to move lever A the extra fraction of a millimeter so it engages. But the stronger spring stops this, so the machine doesn't work again, but differently.

To adjust the machine, sometimes the service manual tells you to bend the lugs. So, I thought, the next step would be to tweak the exact position of lug 286n to get things to work properly. I did, and that, I rather think, is why my Divisumma will no longer divide. But that's a story for later.

The Upgrade - Part 2, Mainly getting the VPN to work

Well, once I got Windows 7 running, everything seemed fine. For a while. For a stand-alone machine, Windows 7 is OK. Personally I don't find it any better or worse than XP - different sometimes, but not noticeably better. The graphics are all different but honestly they don't make any real difference. It's kind of cute the way taskbar items give you a preview before you expand them, but again it's not exactly life changing.

I can't comment on whether the performance is better than XP, as some people claim, because the machine was so badly broken before that it isn't a fair comparison. Some things are however much worse. For some reason re-sorting a large directory can take ages - tens of seconds - if the content consists mainly of images. I suspect it is re-extracting the thumbnails from the files. It's a typical example of trying to be gee-whizz helpful and just making the user experience painful, which unfortunately is fairly characteristic of Windows.

It was when I tried to install the VPN so I could use the machine to work from home that things started to go downhill rapidly. Like many companies, we have a Cisco PIX (well, it's called something else now) which provides VPN services among other things, and the Cisco VPN client. Getting hold of the Windows 7 client and getting the VPN to come up was amazingly easy. So far things were looking good. I could SSH to my Linux system, and I found a so-so free X server and that worked too. For some reason I stopped there, and it was a few days before I tried the next step.

Which was... to open a Windows Explorer window on the Linux filesystem. We have (just like lots of people) a server that runs Samba. When I tried to connect, it just hung for a long time and eventually said it couldn't reach the server. What's more, this time, I couldn't get SSH to work either. Using Wireshark, I could see that packets were being sent into the VPN client, but they were never coming out on the wire side. And in fact, the client's statistics window showed an increasing "discarded packet" count. It's impossible to find out why the client discards packets. The log shows nothing, even when you turn the logging level up to maximum for everything.

At this point I gave up for a while on the regular VPN client, and tried using the SSH client. This was amazingly easy to install. But it didn't work. I eventually discovered that even though I had my work network set as "trusted" in the ZoneAlarm firewall, I still had to turn the global internet security level all the way down, effectively disabling the firewall altogether. The SSH VPN came up that way, but of course this is way too dangerous as a normal setting. So much for that solution.

Luckily, I was able to ask for help from a security expert at Cisco, who parenthetically remarked that it's just about impossible to get the VPN to work with the ZoneAlarm firewall running. Aha! I turned it off, turned on the Windows firewall, and now everything except remote mounting my Linux server worked fine. So, lesson #1: don't use the ZoneAlarm firewall if you want VPN to work.

More Wiresharking showed that this time, packets were getting through to the wire, and were getting replies. Yippee! Strangely, the Windows file client was trying to connect to port 80 (i.e. HTTP) and getting an immediate reject from the server. I have no idea why it tries to connect to port 80. Another interesting thing I saw was that after a couple of failed attempts at connecting, Windows just sulks. When you click on "connect" it immediately comes back and says "can't" without even sending any messages. I suppose it has cached the failed result, but it's a real problem when you are making configuration changes to try and get it to work.

Then I suddenly remembered something. Windows remote file access uses a protocol called SMB. SMBv1, used up to XP, is a truly awful protocol. It sends literally hundreds of messages, and waits for the round trips, for even the simplest operation. That's why accessing a remote file system over a wide-area connection is so slow and painful. Finally, after a decade or so, this problem was addressed in Vista, with SMBv2, which supposedly makes things better. However Samba still only speaks SMBv1. Now Vista, and Windows 7, are supposed to auto-negotiate, i.e. if the server can't do SMBv2, they fall back to SMBv1. Supposed to, but evidently they don't. If the client doesn't get the answer it's expecting when it tries SMBv2, it just sits and waits an irritatingly long time, then tells you it can't do it. So, the obvious thing to do is look for a way to tell the client always to use SMBv1. I looked everywhere in the "advanced" configuration, but nowhere is there a checkbox that says "don't even think about using SMBv2".

So I Googled, and I found an excellent page on an Israeli IT-help site that says exactly what to do. It just involves typing two unbelievably complex commands at the Windows shell. However this isn't the whole story, because Windows 7 has this great idea that even if you have Administrator privilege, you don't actually get that privilege unless you ask nicely. So after you have typed this humungous command, the response you get is "access denied". Luckily, Google had the answer for that, too.

So the whole procedure for disabling SMBv2, assuming that you have Administrator privilege, is:

1. Right click on the "Command Window" icon, then select "Run as Administrator".
2. Type:
   sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
   sc config mrxsmb20 start= auto
   
   

Don't miss out the spaces after the equal signs - they're important. Someone at MS evidently skipped parser school.

So, after a very frustrating couple of sessions, I can now fully access my work system from home. But (a common refrain I'm afraid), why is it so hard?

That wasn't all though. When I was physically rebuilding my system, I kept noticing that the CD/DVD drives stopped working. Each time, I'd remove all their cables, plug them back in again, and when I rebooted, they worked fine. The cables didn't seem loose or damaged, so it was a bit surprising, but I figured I must be disturbing things somehow. Later, I finally figured out why my DVD drive refused to write DVDs... it isn't a DVD writer, just a reader and a CD writer. Well, that was easy to fix, so it was off to Fry's for a fancy new SATA DVD drive. That was actually an amazingly simple and smooth installation. Absolutely nothing went wrong at all.

Then, while I was trying to solve my VPN problems... the CD drives wouldn't work. When I inserted disks, the lights would flash, and sometimes the drawers would pop open, but nothing showed up for the disks themselves. Now though, they use completely separate cables and adapters, right to the motherboard. So it can't be a cabling problem. Finally, I rebooted the machine... and they worked just fine. Turns out (thanks again to Google) that Windows 7 has a well-known bug that sometimes, CD drives don't work. How on earth did that get through the QA process?

On Upgrading - or "what were they thinking?"

My desktop machine at home has had creeping software sickness for a long time. It was new about 4 years ago and has gradually got less and less likely to succeed at any given task. Visual Studio crashes quite often, which I've never seen anywhere else. Google Earth kind-of runs but is pretty much unusable. And so on. I've no idea why these things happen, there's no logical reason why software should wear out, but it seems that it does.

I resisted Vista for all of its sorry lifetime, wisely as it turned out. But everyone seems to be saying nice things about Windows 7, so I decided it was time to upgrade. At the same time I decided to swap the 250 Gbyte hard drive for a brand new 2 terabyte one. Not that I have anything that will use up that much disk space, but 250 GB was getting full.

The machine is something called an HP Media Center. It was a distress purchase, my previous machine had scrambled its hard drive and I had exactly 10 hours to get something important done, so I just rushed out to Fry's and bought what they recommended. Until now, I'd never had any reason to take the covers off. When I did, I found that the hard drive was totally, utterly inaccessible, hidden inside the machine, and mounted vertically (rather than horizontally as usual). No normal screwdriver could access any of the mounting screws. I tried undoing various other things, but nothing gave access to the screws. Eventually I figured I could just put the new drive loose on the floor of the box. But, since I don't give up easily, I wondered how the factory had ever managed to assemble the machine. More on that later.

So, having swapped the drive cables over to my brand-new, unformatted 2 TB disk, it was time to install Windows 7, which I had (legitimately) on a USB memory stick. (As an aside, in about 1994 I worked on one of the very first video-on-demand projects, at DEC. Part of the system was a 1 TB drive farm, which occupied four full-size racks. Of course the whole project was more than a decade ahead of its time, and flopped completely).

Since I had a new disk, I actually wanted to do an install from scratch. But still there is a great mystery here. Microsoft built Windows 7 because the adoption rate of Vista was so low - I've seen estimates of 20%. Yet you can only do an in situ upgrade from Vista. So if you're one of the 80% who never moved from XP, you're out of luck. Or rather, Microsoft is, because that's who loses money if people don't upgrade. XP is a perfectly fine system, I would not have upgraded but for my "software wear-out" problem. Most not-very-technical users will be completely put off by the complication of a from-scratch installation, followed by reinstalling all of their apps, and in all probability just won't bother. So what was Microsoft thinking when they made this decision?

So, I booted from the memory stick, Windows 7 started and everything seemed fine. Then it put up a screen asking me which disk I wanted to use. When I selected my new drive, I got an error, "cannot create system partition". That's dumb, I thought, surely a from-scratch installer should be able to partition and format a disk? Still, I was able to rig things up so that I booted from the old system, with the new disk connected. That way I could format the new disk from XP. Then I restarted the Windows 7 system again. The same thing happened.

It took a lot of frustration, much bad language, and a lot of googling before I found the solution to this. It turns out that since the early days of Vista, the installer has not been able to cope with having more than one drive or partition visible to it. If it does, it gives this misleading error message which gives absolutely no clue as to the problem, and which will certainly stop most people dead in their tracks. Yet MS had at least a year to fix this, preferably so installer could handle multiple connected drives, but failing that at least to give a better error message. Once again, what were they thinking?

Once I had this figured out and unplugged everything except the target drive, everything went fine. The system installed remarkably quickly, and subsequent reinstallation of all my apps went smoothly too. It took quite a while for further problems to emerge.

Meanwhile, I hadn't given up on the disk mounting problem. I picked up various tools - stubby screwdriver, offset screwdriver - from my local TrueValue, but none of them could get all of the hidden screws. Finally a trip to Fry's got me a tiny ratchet offset screwdriver with interchangeable bits. Using that, and a lot of missing flesh from my hands, I was able to remove the drive and install the new one. Still I wondered how on earth they did this at the factory? Then by chance I tidied my office and found the original hardware manual for the machine. This revealed the secret latch which allows the whole drive bay to be dismantled and removed. Of course it is much easier that way, but there would be no way to identify the secret latch without the manual.

Windows 7 ran smoothly for a while, but then I ran into a very odd problem. Double clicking on certain system-ish folders gives the message "Access Denied". Now, I am the only user of the machine, and of course have Administrator privilege, so what is going on? I tried changing access rights, but of course since I didn't have access in the first place, that didn't work. Finally, some extensive googling found a way round this, which involves going into the deepest depths of "advanced options" in the security screen, and changing ownership of the parent directory. It's at times like this that Linux is so attractive - although the commands are arcane, it is always reasonably easy to figure out what is going on. With Windows, it's either easy or next-to-impossible. The dumbed-down user interfaces give you few alternatives when things are partly broken.

So now, my new system seems to be working fine, and does very nearly everything my old one did. (There are still a few things to reinstall). One mystery is a system-created "shortcut" (i.e. softlink) which points to itself. This confuses Explorer no end, but since I have no idea what the folder is for, I daren't delete it. I also still haven't managed to find the cache directory for IE8 - I've found one of them, but only some files show up there. That's another mystery.

Divisumma 24

Update August 2020: the person who supplied the manuals has sadly passed away, and they are no longer available from this source. I have placed them online here (Part 1) and here (Part 2). Be aware that they are very big - about 250 MB in total.

It's arrived! My circa 1960 Olivetti Divisumma 24 electromechanical calculator has arrived from Italy. It's in good condition although so far I haven't got it fully working.

First a little background. When I was about 17 (a long time ago!) I worked one summer at an advertising agency doing analysis of some surveys. For this I was equipped with a Divisumma 24. This was, for its time, an amazing machine. It could not only add and subtract, but also multiply and divide, for numbers up to 12 digits. It was very compact, unlike most such machines, and also a very nice piece of industrial design. It fascinated me, and I was especially intrigued as to how it worked. I wrote to Olivetti, and they kindly sent me a green booklet describing in complete detail how one of the simpler machines - just an adding/subtracting machine - worked. A while later I wrote to them again, thanking them profusely and practically begging them for information about the Divisumma. Obviously my letter went to someone else, because this time I got a reply more-or-less accusing me of stealing the book and asserting that Olivetti would never, ever, under any circumstances, give such information. So that was that.
I still have that little green book, and a few weeks ago I took it out of the bookcase and re-read it. I was as intrigued as ever about how the Divisumma worked. A lot has changed in 40 or so years - Olivetti no longer really exists, for one thing, and nobody has used mechanical calculators for three decades. So with Google's help I discovered this source for Olivetti manuals, and a great many others too. A few days later a parcel showed up with seven volumes of green-covered manuals, and I started reading. It's not that hard to understand how it works, but what is truly mind-boggling is that someone was able to design it. Even allowing that it was a process of evolution from simper machines, it is still extremely impressive. Unlike software, which has some structure to it, these are three-dimensional puzzles, where two completely unrelated functions that just happen to need to do something at the same time, can share the machinery. (For example, the mechanism that arranges double line-spacing for totals just happens to be in the right place to reset a lever that controls the way the registers engage for memory operations).
Of course reading these manuals just whetted my appetite again. A bit of searching showed someone in Italy who had one to sell. I paid about $150 for it, but of course the postage - even surface mail - nearly doubled that. And this week it arrived. The seller had done a super job of packaging, including a wooden framework to protect the machine inside the box. It was complete, apart from one minor knob on the keyboard, and the power cord. It even had a roll of yellowing paper.
I rigged up a power cord for it (don't tell the safety nannies about this) and plugged it in. Unfortunately, it didn't work - one of the keys was jammed, and the motor just ran without anything happening. Not really a surprise, but a bit of a disappointment. So then it was off with cover. That comes off surprisingly easy, no screws, just a couple of toggles.
The insides of the machine are in remarkably good condition. There was some fluff around the keyboard, but no rust or damage. All the metal parts seem to be cadmium plated, which means they look the same as the day they were assembled.

I need to say something about the manual, too. The Olivetti technical manuals are also works of art. Every tiny aspect of the machine's operation is described in great detail, with beautiful engineering drawings for every page showing the various levers, bridges, pins, racks, springs and so on - just those relevant to the current description. Once you've digested that, they also include complete instructions for assembling a machine from scratch. The numbering of the parts is consistent through the seven volumes, so once you read in chapter VIII (as befits an Italian product, much use is made or Roman numerals) that lever 73 is key to some particular function, whenever you see lever 73 later on, you know exactly what it does.

So with the help of the manual, I was able to figure out what was jammed, and unjam it. And the machine worked! Well, briefly. For about fifteen glorious minutes it would add, subtract, multiply, divide, and move numbers to and from the "memory" . Even the 30-year old ribbon worked, well enough to read anyway.
But then disaster struck. I started a divide, but instead of the usual kerchunk-kerchunk of the running machine there was just a faint hum, the horrifying noise of the stalled motor. I unplugged it and tried a few things, and eventually it unjammed. Phew! But then I realised things weren't working right, and when I looked, I realised that disaster had struck. Right in the very heart of the machine, a frame had got twisted so badly that it had let a metal rod fall out. This was a totally inaccessible place, without completely dismantling the machine. I was mortified. Just when things had been going so well (I had never really expected the machine to be working), and now, just so much scrap metal. I could almost have wept.
I studied the manuals again, and very carefully, removed the paper roller and associated bits and pieces, saving all the parts in little plastic bags. There was only one problem - a circlip which in the time-honored tradition flew across the room. Luckily I found it easily. That gave me access to the mechanism, from above. Then the real fun started. I found that I could just get a pair of tweezers between the individual elements of the register, and that way I could hold the rod in more or less the right place to insert it. But actually getting it into the holes at either side of the frame was another story. Let's just say it took a long time. Finally the trick was to hold everything in place with wire (actually green garden wire, which gave a certain rusticity to the whole operation). After several hours I had it back in place.
Very carefully I turned the machine over by hand. It seemed to work correctly. But then I discovered how delicate these machines really are. Just like an exceptionally old wine, which is wonderful when opened but undrinkable within ten minutes, so it seems that my early success with the Divisumma was not to last. Every operation revealed some new misalignment or jam, and when that was fixed, another one showed up.
There is really a lost trade and craft here. Back in the day when these machines were commonplace, every town had numerous little back-street workshops, where bent-backed mechanics in brown coats would pore over them when they jammed or refused to work. I'm sure it was a common occurrence. In the few weeks I was using the Divisumma all those years back, it jammed once and had to go for repairs. Probably every machine was in the shop every few weeks. "Oh yes," the brown-coated old guy would say, "looks like the returbitating cam has shifted again, just move it a bit and tighten up the unflurging spring while I'm at it..." and the machine would be as good as new... for a few more weeks.
Anyway, my Divisumma definitely needs some more tender loving care before it will be dividing again. It's a wonderful piece of engineering, and I'm very lucky to have it. It's certainly something to fill those long winter evenings!