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?