It looks like my tumble dryer has an alarm built in to it that wakes me up about once a year. Last year it was a clacking clanking scraping sound (see here).
This year it's a thump thump-thump sound. (Sort of D in Morse code). OK, it's 1:30am so I don't get up, but try to sleep through it. After a couple of hours the dryer finishes its program and I get some sleep. Five o'clock comes round and I get up and investigate.
I've forgotten how to get the top off properly (just undo the side screws and the top comes off to the front. Don't undo the rear screws like I did. Again). To get the sides off I need to take the front panel off and to do that I need to take the bottom vent off. I forgot that it slides on these clips:
I finally have the top and two sides off and can now look for the D-thump. Turning the drum manually I can just feel a bump now and again. The rear bearings look fine, so I have a look at the rollers. They are fine too. Then I notice the drum has some black marks where something has stuck to the track the rollers run in.
I find that there's a big blob and several smaller blobs, which probably accounts for the D pattern of thumping. I scrape the blobs off with a wooden stick and re-assemble the dryer.
A quick test and the D-thump is gone. I have no idea what the black blobs were. At first I thought it might be material from the rollers, but they look fine, with no obvious missing material. Maybe something fell onto a roller and ended up smeared around the drum? I have no idea, but the dryer seems well again, which is good.
Saturday, 11 January 2020
More Magic Metallised Paper Experiments
I've been trying to make paper that works in the Casio FP-10 printer. See the previous post for attempts one to six:
Anyway, I was watching an episode of Wheeler Dealers and Edd mentioned that you use a conductive spray primer before you spot weld, sometimes. That was interesting as I had been looking for conductive spray paint. A quick google and it appeared that yes, this primer was indeed conductive due to either zinc or copper in the spray. Not only that but it as available at a local auto supply shop.
One trip to the shop later and I had a can of pretty expensive zinc spray paint. It was no problem to then spray a sheet of A4 paper:
When dry the surface is similar to the magic paper, and even shines up a bit if you rub the surface:
Unfortunately, even though I did measure some conductivity when drying, the paint seemed to not be conductive when dry. I did a couple of sheets with varying numbers of layers and ran some test strips through the printer:
As you can see, it's a bit messy and clogged the print head as the final product is quite thick. It also didn't work.
Attempt 6b
I then had an idea about testing the paper. I set up a PSU with 15V on it and attached one wire to the paper then dragged the other wire across the paper. This gave me an idea whether the paper would spark erode or not. The real Casio paper worked fine (as expected), but the only paper from my tests that worked was the 'gilded' aluminium one. Here's some scribbles I made, which are spark eroded. The black you can see is some paint I sprayed under the aluminium, just like the real paper.
Even though this manual test worked, it didn't print in the FP-10.
Tuesday, 31 December 2019
Fix of a Fix
The tripod I use broke a couple of years after I bought it. I think i dropped the tripod, or it fell over, I can't remember. I didn't want to throw it away and I must have just built my first 3D printer, so I modelled and printed a new part for it. A while later another clamp on the tripod failed, so I modelled that (it was a different size) and fixed that problem.
Recently I had started to notice that one replaced clamp was a bit loose. Of course, I carried on using the tripod until the part failed, which is did a few days ago.
The broken part is here:
I think this was printed on my Mendel, but however I did it it looks like I was using very little infill at the time. You can see here
that there's none, really.
I printed the new part at a higher infill figure (50%) and also at a layer height of 0.1mm rather than 0.2mm. This leads to a denser part that hopefully will last a bit longer than the original.
Ever since the 80's I've wanted to build a Z80 computer. I even bought the chips, but never used them. The reasons for this are varied. I never liked erasing and reprogramming EPROMs. My EPROM eraser died. I didn't have the money to make a PCB, or the software (or red and blue tape and a lightbox). In the 90's I did make a 6502 computer which was done with loads of wires on veroboard. Then the Arduinos came along and I didn't really need a Z80 computer as much.
I still wanted one though.
Then, in a flash, the scratch to my itch appeared: Why not make a Z80 computer with flash memory? Well, fine, but how do you program the flash memory? Aha! Why not use an Arduino to take over the bus and program the flash chip?
That should work, and once I had the idea of an Arduino to program the flash, it didn't take too long to think about using an Arduino to drive the Z80 clock and bus signals and provide flash data directly itself. This allows you to run the Z80 using the Arduino and read all the bus signals. You can single step your code at the resolution of a half T state (one clock transition). Once you are happy with your code, it can be burnt into flash. Once there, you can remove the debugger Arduino and use the board as a stand alone computer.
Of course, without IO and hardware bits attached to it, a computer like this isn't very interesting. So I added a couple of Z80 PIOs and the footprint for an Arduino shield. So you can plug shields in to the board and use whatever is on them. So you have a Z80 Arduino. Programmed in Z80 assembly (or C, or whatever you can get running on a Z80).
PCB manufacture is a lot cheaper these days so I had a few PCBs made up.
The board looks like this:
It is technically an Arduino shield as it plugs into the top of a Mega. It is also an Arduino itself, as shields (Uno format) plug into it. You run it either under Mega control where the Mega clocks the Z80 and emulates flash (the RAM is switched in as the mega runs the Z80, so you have 32K of RAM, more than the Mega can supply). Or you run it at 4.5MHz from the real hardware (with the Mega plugged in or not).
The specs aren't too bad either, there's 32K of SRAM and 512K of flash. The flash is bank switched, but needs a small piece of code in each bank at the reset vector. The Z80 runs at 4.5MHz.
The two PIOs have 32 GPIOs, each of which is bit addressable as input or output. I also put a Z80 CTC on there for timing things. This PCB uses through hole components apart from the flash chip, a 3V3 regulator and an A/D converter. There's some surface mount capacitors too. It's pretty easy to build, but does come out larger than an Uno, or Mega.
The mega plugs in underneath:
The shield plugs in on top:
Under the shield there's an A/D converter that provides the analogue channels when operating as an Arduino. There's also a 3V3 regulator, just in case:
There's various test code in the sketch. This code writes to the LCD on the LCD/button shield:
I've got a script that embeds Z80 .lst file output into the Arduino sketch so you don't have to manually edit the file, you assemble it then run the script and it's put into your sketch which you then compile.
I've written a terminal emulator script that lets you upload .ihx files that have been built using the Z88SDK C compiler. The terminal emulator also has a register dump facility. This uses a small piece of code that is executed between each instruction when the Z80 is being clocked by the Mega. This code dumps the register contents in a non-disruptive way and the data is picked up by the terminal emulator and displayed.
This is very much a work in progress, but that's part of the fun isn't it?
The files are here on github, there's all the code and the PCB files. I use geda.
I use Panasonic GF1 and GF3 cameras for stills and video. I use the 20mm lens that came with a GF1 and also a selection of Pentax lenses and micro four thirds adapters. The 20mm is an auto focus lens, but all of the others are manual focus. This is fine in the workshop when shooting video or taking macro shots of bits and pieces, but when out and about it's a lot more convenient using auto focus. I've been looking for a zoom lens for the cameras for weeks. they are quite expensive, probably because they can be used on a wide range of cameras. Not wanting to spend much money on the lens, I waited until a broken one came up for sale that I thought I had a chance of fixing.
The lens I bought had probably been dropped and the mounting flanges had broken off. I removed the part that was broken:
I tried the most sensible route to a fix: try to buy spare parts. As usual, they aren't available. I was told that my best course of action was to have the lens serviced at an authorised service centre. I suspect this would have cost more than I paid for all of the GF cameras and lenses put together.
So, instead of this I decided to have a go at making the part myself. I have a 3D printer and this is a plastic part...
Here's one of the prototypes I made along the way:
Did it work? Well, yes it did. In fact the first two photos in this blog entry were taken with the previously broken lens.
This photo wasn't, for obvious reasons:
I do get a few lens attachment errors ( I think the contacts need to be moved up a bit), and I lost a screw (not technically lost I suppose, I know where it is: somewhere in the workshop), I have only aligned two of the four mounting screws and I have to drill a few holes by hand, but it does work.
Auto focus and everything.
It works as it is, but I'll probably improve it to remove the annoying lens attachment warning. Just because it isn't perfect doesn't mean it won't do the job.
A Vinyl Cutter that Works with Linux
In the UK we have a well known crafting store. I have a look around now and again and buy a few things there. One of the things I always look at is a range of vinyl cutters that are sold there. They look very useful, and the 3020 CNC can't cut paper very well. I have the Can transformer for thin sheet metal, but the inability to cut paper and card was irking me.
I had a try at using drag knives on the CNC3020, but whatever I tried just didn't work. I now know that was probably due to the lack of a sticky sheet for the work piece (lack of research on my part I think) and maybe insufficient knife pressure.
After walking past the insect based cutter again, I decided to see if it could be attached to Linux. After a lot of hunting about on the web, I came to the conclusion that it probably was just about possible but that it wasn't a sure thing. Then I decided to research vinyl cutters. Then things looked up. I bought one of these:
It's a Smurf. Presumably because it has blue cheeks. I bought it here. It's great. It's about the same price as the other cutters, it can cut A3, it is a trade rated build, not hobby so is sturdy and it does work with Linux. The interfaces that it has are USB to serial, RS232 and a USB connector for a memory stick. Oh, and it comes with a pen holder so you can use it as a plotter as well. It was supplied with an A3 sticky mat and cables. There's a menu driven control panel on the top of the machine, a power panel at one end and an IO panel at the other:
There's good, bad and neutral news here. Good news is that I have tried the USB to serial and it works, as long as you send the file a certain way. There's bad news: I haven't managed to get the USB memory stick interface to work, but it turns out that I was formatting the stick wrong. The neutral news is that I haven't tried the RS232 at all.
The memory stick requires all files to be in the root directory of a FAT-formatted stick. I think it also requires the file names to have the PLT (or plt, I'm not sure) file extension. I've not tried it since I got the USB to serial working.
The protocol used is either HPGL or DM-PL. I use HPGL and a script that I wrote to send the files as there were a wrinkle or two when sending files straight to the cutter. I'm not sure what was happening but I suspect it was to do with auto detection of the protocol that was being used and buffering. I have a script on my github here. It's a basic script but it works for me. There's a terminal emulator so you can drive the cutter manually if you want to.
My work flow is a bit convoluted, but I found that InkScape can generate HPGL files that work with the cutter, so I use that to export files either from Inkscape itself or from files imported from LibreCAD.
The cutter has an ARMS auto contour mode, but I haven't managed to find any protocol for it, or really understand what it is. It looks like it's an auto registration feature for pre-printed material. It seems to need host help so without the protocol that isn't going to be available.
Thursday, 12 December 2019
MK-52 Calculator
The MK-52 is a Russian calculator that is interesting for a number of reasons. Being Russian, it has Russian manuals and Russian keys. This is a bit of a problem for me as I don't speak Russian. I find it difficult to remember the key markings and what they relate to on the keyboard. So, I thought it would be worth having a go at creating some English keys for the MK-52, just to make using it more comfortable.
My first idea was to machine the keys out of plastic and engrave the legends into the top of the key. This could then be filled with a coloured material and there you go. After some research I found that nylon has a high enough melting point that I could maybe machine a set of keys from it and then fill the engraving with polymer clay and then cure that at 105C. Hopefully the nylon will stand up to that treatment and the polymer clay will be robust enough if it is cured and recessed into the key.
Setting all this up is a bit tricky as the parts have features on all sides and work holding and work order is complicated. So, as a trial I had a go at 3D printing the keys. This actually turned out fairly well. I have printed in PLA, so polymer clay may not work, but I have a couple of keys that I've printed and engraved with legends. I then used a pencil to colour the engraving, rather than use polymer clay.
The result is a bilingual MK-52:
The two white keys have English legends. Here's a close up:
The engraving is a bit wonky, that's just the setup I used. this was just a trial and I was more concerned about the engraving. Engraving PLA is not easy, but after a few passes at different depths and RPM I managed to get pretty good 2mm high text. This is about 0.5mm deep which is OK for the pencil colouring, but for polymer clay more depth might be needed so more material is in the keytop.
I tried using the keys after I put them back in the calculator and they seem to work fine. The pin on the back that presses into the membrane mechanism is a bit shorter on the 3D printed part, but that doesn't seem to affect operation at all.
I also had a look at getting some keys 3D printed by Shapeways. I hoped that they'd do full colour printing but they don't, a single colour is all that they do, and that comes out at $6 per key. This makes it too expensive to consider, I think, which is a bit of a shame.
Holding the keys is a problem on the engraver, then I had a thought. The keys were held perfectly well on the 3D printer, why not use the print bed on the engraver?
On the Fisher the print bed is sort of circular and removable. So, I tried that and it worked:
I managed to engrave a set of 13 keys, albeit a bit off centre.
I've used an amalgam of English wording that I found on the internet. I've had to change the letters so that there's a maximum of three per key, as four doesn't fit with the text size I've chosen.
There's a problem using polymer clay with PLA: it requires too high a temperature to cure. Instead, I tried air-dry clay. I got some white and used it to fill the engraving, so there's a contrast between the letters and the button. I also tried a mould-able glue product (Sugru).
These are some of my attempts, together with an original button on the right.
The air dry clay has worked best I think, as it doesn't colour as much from dust when I sand and polish the top. Maybe if I left the mould-able glue to cure longer than 24 hours then it wouldn't pick up so much dust. The dust gives the letters an off-white colour that isn't as nice as the whiter finish of the clay.
I polish the tops of the keys which gives them a nice shiny finish. The sides are still the normal 3D printer layer finish. The bottom with the 2mm cylinder that pushes the key is a bit of an untidy mess.
I've decided to print the keys with a hole in the base and fit a length of 2.5mm styrene rod there instead of trying to print the feature. You can see the lower side of one of the keys here:
Printing this part has the advantage that it's flat on the bottom and sticks well, and the keytop is at the top of the part which means it has a nice finish which polished well and also doesn't suffer from the gaps that the first layer of a print seems to have. These gaps filled with white clay and created a pattern of thin lines on the top. You can also see a finished key in the above photo and also several keys that have had clay applied and are drying before I sand and polish the top surface.
I then made a full set of keys (well, the Russian ones, I left the original number and function keys) and fitted them in the MK-52:
These are air dry clay filled except for the R/W and ADR keys, they are filled with paint. I've also used some 2.5mm diameter styrene rod for the part of the keys that pushes on the membrane. I glued the rods in a hole that is printed on the bottom of the keys.
This is very much a trial, so we'll see how well they work.
You can see the keys working in this video:
Here's a short timelapse of the keys being engraved. You can see that one of them popped off as the tool came down to touch it. The fixing method isn't perfect! I could always engrave more keys and get some redundant ones for this sort of mishap. I engraved a block of keys like this several times and that key always fell off. At least it's consistent.
Posts
