Broken Beko washing machine spins really fast

I know this is a tedious blog about fixing my computer problems, but since I feel duty bound to give information back to the interwebs after it's helped me, I hope a post about washing machine fixes will be acceptable.

So, here's hoping this post will turn up for people google-ing for the same problems as me this morning.

My Beko WMA520W washing machine broke last night. Half way through a wash there was a "wheeee!" noise and the drum stopped. We turned it off and took the laundry out. Thereafter, every time I turned it on, it pumped water out, then spun really fast, then stopped. Even turning it off at the wall or holding down the cancel button would not re-set it, as it was convinced it was mid-cycle.

I bring you a two-part solution. First, according to this post, there is a magic raindance on the front control panel to re-set the machine:

• Turn the power button off but leave the machine on at the wall
• Select a 90 degree wash
• Hold the start/cancel button down for 3 seconds and turn the power button on whilst still holding buttons down. The start light will flash.
• Select any spin position.
• Hold down the start/cancel button again for 3 seconds. If other buttons start to flash, press start/cancel again for 3 seconds.

Now the machine is happy to accept instruction. We tried a nice rinse cycle, with the machine empty. It filled with water okay, but when it got to tumble-time, the drum just span up to warp speed again, then stopped.

After checking various things, we removed the motor and the issue turned out to be a shattered tachometer magnet. The magnet pieces no longer rotated with the motor shaft, so there was no induced current in the tacho coil. The control unit therefore assumed the motor was not rotating, so increased the speed until it reached some safety cut-off.

In this model, the magnet appears to have been formed around a textured brass ring, so even if spares were available (and the internet doesn't seem to have any) it seems unlikely you could get a replacement on without shattering it. We opted for some Araldite Rapid Steel epoxy and have tried to glue the two pieces back together. This may not last us very long, and we don't intend to leave the washer on when we're not around, just in case! It we want a longer-term fix, it seems the only option is to buy a whole new motor which seems a bit stupid just for a magnet, but hey ho. We'll try the £5 fix over the £80 one any day. Of course, the third option is to obtain the new motor less expensively by cannibalising other Beko machines at the skip or otherwise obtaining a broken one for spares.

Other news from my fascinating journey round the Beko's guts:

We've always had to pour another 20 litres of water through the tray on a wash cycle as the machine doesn't put anywhere near enough water in. However, it looks like we can make adjustments on the fill pressure sensor (top front right corner) in the future, but let's break one thing at a time for now.

Some corners of the web mention timing wheels and other such nonsense. I didn't see any of those inside our beastie, so I conclude most of the control goes on inside the processor (an Atmega32). When that gets toasted, it'll be £50 for a new board :-(

Equation referencing in Word 2007

It baffles me that something so essential is not simple with micro$oft word. If you are going to want to put equations in your document, of course you will want to talk about them! (Otherwise, why bother?) To talk about them, of course you will need to reference them and the best way of doing that is with numbers. Why then is there no simple way to do this? Why give an equation tool but no easy numbering method?

So: how to insert a numbered equation in Word 2007 and reference it in the text. For the first part, I follow this blog post.

1. Insert a 3 column, 1 row table.
2. Format the table to fill 100% of the page width, with the column widths in percent as 15:70:15.
3. Centre the text in the middle column and remove all table borders. Make the spacing below the table the same as other paragraphs.
4. Insert your equation in the middle column. (I use insert>object>M$ equation 3.0 since the new equation package won't work on my machine).
5. Insert a number in the right-hand column by insert>multilevel list. You can define your own so that the numbers are formatted like (x).
   

Here is the nice part (ha ha). Since my "equation gallery" is broken too, I can't save these shenanigans for easy re-use. To insert a new equation later, I simply copy the whole table and paste it elsewhere and change the equation! The numbers automatically sort themselves out (hallelujah).

To reference the numbered equation in the text:

1. Highlight the equation number and insert>bookmark. Give it a nice name.
2. Put the cursor at the place where you want your reference inserted and insert>cross-reference. Insert a reference of type "bookmark", select the name of your equation and insert the reference to the paragraph number (full context).
   

There. That was a complete pain, wasn't it? And it took about 40 mouse-clicks! Doesn't your equation look horridly rendered too? Oh, I love LaTeX and I want it back.

Excel axis labels workaround

Problem:
When making an x-y scatter plot in Micro$oft Excel 2007, there appears to be a bug which prevents the x-axis tick labels displaying correctly (at least on my machine). When you set the x-axis tick labels to text, e.g. "apple", "banana", "pear"..., the chart just displays the labels as 1, 2, 3... even when you are careful to select the cells containing the text labels as your x-data, and despite them showing up correctly in the "select data" dialogue box. This only appears to be an issue for the x-y scatter plot type.

Workaround 1:
Install linux boot disc...

Workaround 2:
Add a new dummy data series to your graph with x = {"apple", "banana", "pear"...} and y = {0, 0, 0...}, or some other value below the y-axis minimum. Select only this series, and set the chart type to area. The x-axis tick labels should now display correctly for the whole chart. Obviously delete the dummy data label from your legend, if you have one.

Sidewaystable prints upside down

I have two consecutive landscape tables in my thesis using the "sidewaystable" package. The package rotates them so that the top of the table is closest to the spine of the book, however this manifests itself in the pdf as the page headers and footers appearing to the right of one landscape page, and to the left of the next. When I print double sided, one page has a header which is upside down. My preamble is thusly:

\documentclass[a4paper,11pt,twoside]{book}
\usepackage{rotating}

... the solution was to choose:

\usepackage[figuresright]{rotating}

So that the figures are always in one direction. Now my headers are always to the right of the landscape page. Hopefully this will now force them to be the right-way-up! If they both print upside down, I suppose I must choose [figuresleft] instead. I've no idea if this is just a symptom of my particular combination of pdf reader and printer, but hey-ho.

Thanks to the Szwer for solving this one for me.

Incompatible ranks?!

Here's a fun problem that I have encountered. It might be a bug, or it might not (I've run out of patience with google-ing it now I have my program working).

I have a two dimensional matrix. I sum it down one dimension and then find the position of the maximum entry.

subroutine ionfinder(subframe,x_dim,y_dim, irow, icol)

! define imputs, and function type itself
integer, intent(in) :: x_dim, y_dim
integer, intent(in) :: subframe(x_dim,y_dim)
integer, intent(out) :: irow, icol(4) !ion positions

! the code follows...*********************
irow = maxloc(sum(subframe,1))
write(*,*) 'ions in row (y): ', irow

end subroutine ionfinder

...but this causes my compiler (gfortran) to shriek:

irow = maxloc(sum(subframe,1))
1
Error: Incompatible ranks 0 and 1 in assignment at (1)

Huuuurrrmmm. Seems a bit silly, but the following kludge fixes things:

subroutine ionfinder(subframe,x_dim,y_dim, irow, icol)

! define imputs, and function type itself
integer, intent(in) :: x_dim, y_dim
integer, intent(in) :: subframe(x_dim,y_dim)
integer, intent(out) :: irow, icol(4) !ion positions

! define other datum within function
integer tmp(1)

! the code follows...*********************
tmp = maxloc(sum(subframe,1))
irow = tmp(1)
write(*,*) 'ions in row (y): ', irow

end subroutine ionfinder

Well well well. I should probably investigate the cause further but I'm not going to because I have physics to do, not Fortran to fix.

Oh Fortran, how I love thee.

Fortran's logical operators that operate on integers happen to be bitwise. I didn't care about this until now. Here's a summary for two integers, a and b, which can take values 0 or 1.

logical AND:

(ab)	iand(a,b)
00	0
01	0
10	0
11	1

logical OR:

(ab)	ior(a,b)
00	0
01	1
10	1
11	1

logical XOR:

(ab)	ieor(a,b)
00	0
01	1
10	1
11	0

logical NOT:

(a)	not(a)
0	-1
1	-2

WTF? I have been bitten by the bitwise bear! In order to get zeros and ones, I must use ieor(1,a) instead of not(a). Pah.

Also, the tables in this post look all shit in my browser but I can't be bothered to fix them when I have Fortran to do instead.

Today's post was brought to you by the numbers 0 and 1 and the letter F.