Starlock Washers

Posted on November 23, 2019 by Justin

Long ago, I promised myself that I would build a steam loco. Progress is slow, but it is steadily progressing. The loco I am building is a kit from Roundhouse Engineering, and it has nice clear instructions. By the end of October, I had built the chassis and was starting with the valve gear. This loco uses a variant of Walschaerts Valve Gear. I still haven’t quite understood how valve gear works, but I’m hoping that by building it, enlightenment will happen.

All was going well until the step that involves installing starlock washers onto the axles behind the expansion links. The expansion link has an angled bit (see front of the picture below) which I don’t want to bend. The starlock washer is supposed to go on the other end. But I could not get the blasted thing on the axle.

It has to be installed when the link is already mounted in its bearings in the frame: the starlock washer holds the expansion link in place. So it’s got to be done in situ.

I emailed Roundhouse for advice. They suggested using a block of metal with a hole in it behind the axle. I’m not ready to start metalwork, and my feeble fingers aren’t up to the job. I realised I would need some form of clamp. So I gave up for the evening and went to bed.

Divine inspiration came whilst trying to get to sleep, and an idea for a simple clamp popped into my head. Here it is (one expansion link is shown here in the clamp, the other link is to the left so you get a better idea of what it looks like).

It is made of two pieces of plywood approx 10mm x 45mm, and two lengths of M3 threaded bolt (M3 because I happen to have some). The ply is 5mm thick, chosen to fit inside the angled bit of the expansion link. Holes are drilled in strategic places for the bolts and as a gap behind the starlock. By tightening the nuts, the starlock washer should hopefully be forced onto the axle by the plywood. This was prototype 1 of my clamp, and I expected it to break. I would rather the failure happened on my clamp, rather than on the parts for my loco.

I started to tighten the nuts. Success! The starlock is forced onto the axle.

The starlock is really quite resistant to being installed, and the clamp wasn’t very happy, bending precariously. But it did the trick. Once the washer was on the axle, I dismantled the clamp, and used the pieces of ply between my fingers to ease the washer into place, using a carefully cut up train ticket as a spacer between the washer and the bearing to make sure it isn’t too tight.

Success! Now to get my head around Walshaerts Valve Gear.

Posted in 16mm, Garden Railways, Trains | Tagged , , , | Comments Off on Starlock Washers

Model Railway scales

Posted on November 6, 2019 by Andy

Left to Right:

  • 16mm/ft (1:19) Baguley-Drewry Diesel loco (Accucraft)
  • O Gauge (1:32) Ruston (Triang Big-train)
  • OO Gauge (1:76.2) Duchess of Sutherland
  • N Gauge (1:148) 0-6-0 Steam loco (Fleischmann ?)

more detail here: https://www.wis.co.uk/andy/16mm/scale-and-gauge.html

Posted in 16mm, Garden Railways, Trains | Tagged , , , | Comments Off on Model Railway scales

Launching Windows programs on AWS

Posted on June 14, 2019 by Justin

A friend of mine is using Studio 2.0 from Bricklink to create digital models in Lego. He is particularly interested in rendering (creating real-looking images of models that only exist in the computer). The models are complex, and include transparent bricks, and his poor home computer isn’t up to the job. How difficult is it to run a Windows machine in AWS, to do the rendering “in the cloud”?

It’s easy to create Windows instances via the web-based AWS console. This page in the documentation explains how. The “t2.micro” instance size (1 GiB RAM and 1 vCPU) mentioned in the documentation will cost about 1.7 US cents per hour (depending on region) (or it might be free) including the licensing cost of Microsoft Windows.

Running a Windows instance with 1 GiB RAM and 1 vCPU (usually one thread on one core – see documentation) is going to be interesting. Most Windows users are familiar with Windows needing 8 GiB RAM to do something useful. After installing Studio 2.0, I attempted to run it, and it failed to start. Guessing that RAM was the issue, I stopped the EC2 instance and changed the instance type to t3.medium. This has 2 vCPU and 8GiB RAM. Then I launched Studio 2.0, opened one of the demo models, and opened the resource monitor.

Bricklink Studio 2.0 running on Windows Server 2019
on AWS t3.medium with 8 GiB RAM and 4 vCPU

When Studio 2.0 is doing nothing, it maxes out both vCPU. With this model, Windows uses less than 2 GiB RAM. Time to switch instance types again:
I tried c5.xlarge which has the smallest amount of RAM (8GiB) for 4 vCPU. A restart, a new RDP file, log in again, launch Studio 2.0 and open the resource monitor.

When Studio 2.0 is doing nothing, it maxes out all four vCPU. Time to try more cores. I tried the c5.4xlarge. New accounts have a service limit of zero for this instance size. Increasing the service limit is straightforward, but can take an hour to propagate. Instead I tried the c4.4xlarge (previous generation) instead. It has 16 vCPU and 30 GiB RAM.

Studio 2.0 was happy to consume 88% of all 16 vCPU , even when apparently doing nothing.

Over the course of these tests, I also tried the render options, which was the original idea all along, rendering the simplest static image test (not an animation) for this demo model.

The c5.xlarge   (4 vCPU) took 2min57sec to render the frame. 
The c4.4xlarge (16 vCPU) took 0min55sec to render the frame.

How much is all this costing me? Most of these instance types don’t qualify for Free Tier, so I’m incurring real cost. Windows instances are charged per hour or per part-hour. These tests typically took 10 minutes per instance type. Looking at London prices with Windows:

t2.micro    (1 vCPU and  1 GiB RAM) : $0.0178 per Hour 
t3.medium   (2 vCPU and 8  GiB RAM) : $0.0656 per Hour
c5.xlarge   (4 vCPU and 8  GiB RAM) : $0.386  per Hour
c4.4xlarge (16 vCPU and 32 GiB RAM) : $1.686  per Hour 
EBS volume: 30 GB * $0.116 /GB-month : about $0.02 for 5 hours. 
------------------------------------------------------
Total cost :                        : $2.18

Notes: 
 * c5.4xlarge is cheaper  : $1.544 per Hour

Further work involves automating the build of the machine using CloudFormation, and testing a render using a graphics-card instance.

Justin – June 2019

Posted in Computing, Lego | Tagged , , , | Comments Off on Launching Windows programs on AWS

3D print settings – Dremel 3D20

Posted on June 1, 2019 by Justin

I have a Dremel 3D20 printer. It uses proprietary software, which has some limitations

  • Dremel Idea Builder will load 3D files in .STL and .OBJ format, and will write them to the 3D20 via USB cable. Idea Builder has limited slicing features, and doesn’t allow the addition of supports or rafts. It can read proprietary .g3drem files and .3dremel files.
  • Dremel Digilab Slicer is a restricted version of the open-source Ultimaker Cura slicing tool. Strangely it cannot write .g3drem files or .3dremel files. But it can write .gcode files (a standard across 3D printers and other machinery).
  • With the latest firmware, the 3D20 printer itself does understand .gcode files, and will read them properly from its SD-card reader (but not via USB).
  • The full version of Cura is free, it is awesome, and there is a plugin that writes to .g3drem format.

The most efficient workflow seems to be to load STL or OBJ files into Cura, slice and edit there, save as .gcode or .g3drem, copy the file to an SD card, and plug that into the printer. There is no need to have a laptop connected to the printer.

Cura also allows fine control of a range of settings for each print, including the layer height, the density of infill in “solid” parts, the speed of the head, etc. For my first print of Lego-compatible helical gears, I used the standard settings: 0.15mm layer height, 10% infill, 200 degrees temperature, 6.0mm per second print head speed. Then I re-read the Thingiverse page from the creator of these objects: he suggests using 0.1mm or 0.05mm layer height and 40% to 100% infill.

  • the first attempt was adequate, but didn’t mesh very well.
  • the second attempt meshed reasonably, but the teeth stripped within a minute when I attached a motor.
  • the third attempt awaits a Saturday when I can re-print the gears.
Posted in 3D printer | Tagged , , | Comments Off on 3D print settings – Dremel 3D20

3D printing gears

Posted on June 1, 2019 by Justin

Back in March, I determined that using a raft was a waste of time. I tried printing some Lego-compatible helical gears, and this happened.

First attempt at printing a gear-wheel

The first layer wasn’t adhered sufficiently to the bed. The print head was merrily depositing further PLA, but the gear was no longer fixed to the bed and was fixed to the print head instead.

Back to Cura, load the model, add a raft, re-slice, and save as g3Drem, then import back into Dremel3D and upload to the printer. After a few minutes, I noticed that the raft wasn’t adhering to the bed. I tried to correct the problem by pulling the non-suck threads out the way .. but they just got entangled in the head, and I ended up with a mess.

“Stop fiddling with it”! I said to myself, and started it again.

The not-quite-stuck filament that you can see on the right was OK, and the raft printed adequately, and after a few minutes, the gears started to emerge.

The final thing looks like this:

There’s a bit of stringy-ness as the print-head moved back to “home”, but I’m satisfied that the raft was a good idea.

The gears separated from the raft cleanly. I mounted them in a frame to try them out, and they work. Play the video below to see them in action.

IMG_1167.MOV

Posted in Uncategorized | Tagged , , | Comments Off on 3D printing gears

England’s weird place names

Posted on May 28, 2019 by Justin

England has some of the weirdest place names. Until recently, my favourite was Dial Post. Yes, there really is a place called Dial Post, and anyone familiar with the A24 south of Horsham will have seen the signs.

image from Google Streetview (not taken whilst driving)

Someone I knew at school came from a place with the glorious name of Kingston Bagpuise. The name, like so many weird English place names, is a corruption of the French. Just like Biggleswade is a corruption of the more exotic Old German.

But my favourite so far has to be this one from the Cotswolds. Outdone by Lower Slaughter (probable inspiration for The Hobbit), Stow-on-the-Wold (famous for a battle in the English Civil War) and Cirencester (apparently pronounced “siesta” by locals), we found this on a signpost.

Image from Google Streetview (not taken whilst driving)

Guiting Power. Is that a Chinese energy company? No it’s the real name of a real village, which has had a small population for over 1000 years. The name is derived from Saxon, or Old French, or both. We haven’t found out how to pronounce it yet.

Posted in Uncategorized | Comments Off on England’s weird place names

My Commute Carbon Footprint

Posted on April 23, 2019 by Andy

(A quick back-of-the-envelope calculation)

I’d like to know how much CO2 I’m putting into the atmosphere from my commute.

I recall that I fill up about twice a month, and the petrol tank usually takes about 40 litres each time. I could work out the MPG, but this is a quick estimate. It’ll do for now.

Burning Petrol releases about 2.31 kg per litre (according to
https://people.exeter.ac.uk/TWDavies/energy_conversion/Calculation%20of%20CO2%20emissions%20from%20fuels.htm)

Therefore, in a month, 2 tank-fulls, or 80 litres burns into…

80 × 2.31 = 184.8 kg of CO2

Taking holidays into account, let’s assume I do that commute for 11 months of the year, which means my commute looks like

184.8 × 11 = 2032.8 kg, or just over 2 tonnes of CO2

There we go. 2 tonnes. The next challenge is to try to reduce it.

According to this article at The Guardian, manufacturing a small to medium sized car might produce 6-17 tonnes of CO2, which I need to factor in when deciding whether to replace the car

Note: My internet-based research said a car probably emits 4.6 tonnes, according to https://www.epa.gov/greenvehicles/greenhouse-gas-emissions-typical-passenger-vehicle. My car does less than the average mileage, and I get better fuel economy than the 22mpg stated in the epa.gov article, so I’m comfortable with the figures I’ve calculated.

Posted in Uncategorized | Tagged , | Comments Off on My Commute Carbon Footprint

AWS Logging (or “why am I being charged for free-tier S3?”)

Posted on March 26, 2019 by Justin

I have an AWS account. I created it less than a year ago, so I get some free stuff with the account. In the billing dashboard, I was somewhat concerned to see this:

It is only 5 days to the end of the month, but I thought I hadn’t uploaded that many objects to S3, and wondered where this was coming from.

A few weeks ago, I was exploring AWS CloudTrail, which logs every API call, and I had set it up to store data for some later analysis. Now seemed like a good time to do so. I also wanted to explore AWS Athena, which is AWS’ implementation of Presto as a service, and allows you to run SQL queries directly on your S3 content (without having to import it into expensive Redshift, or elephantine EMR).

On the Cloud Trail interface is a handy link to Athena: it’s like they WANT you to use it:

Clicking that link starts a simple wizard that creates the “External Table” in Athena pointing to the S3 bucket where your CloudTrail logs are stored. This table tells Athena how to find the CloudTrail data, how to interpret it, how to read it, etc. The syntax is familiar to anyone with a background in SQL, and the details are familiar if you have dug into the depths of Apache Hive (SQL-on-Hadoop).

Within a few minutes, and following some tutorials, I had a query running that counts the number of API calls on an S3 bucket. Here is the code:

 SELECT count(useragent) as QTY, eventname, sourceipaddress, awsregion
 FROM my_cloudtrail_logs 
 WHERE 
     requestparameters LIKE '%my-cloudtrail-logs-bucket-%'
 GROUP BY sourceipaddress, eventname, awsregion
 ORDER BY QTY DESC
 LIMIT 5;

This code gives the top 5 combinations of event-name, sourceIP and region. Here are the results:

We learn several things from this exercise:

  • The culprit, the reason I went over my Free Tier limit for S3, is in fact CloudTrail. It has put over 13,000 objects into an S3 bucket.
  • I should also be concerned with the top row: Athena doing 173,000 “GetObject” calls to parse my data. That count increased to 202,989 the next time I ran the script. Row 3 has similar behaviour.
  • The source IP addresses in lines 4 and 5 are my own. No concerns there.

The big money question: how much did the Athena script cost to run?

  • Athena charges: $5.00 per TB scanned. The Athena console says it scanned 35 Mb, so the Athena cost is $0.00017
  • S3 charges: $0.0004 per 1000 GET requests, which is about $0.08.
  • Incidentally, those PUT requests from CloudTrail cost a further $0.07.

Closer inspection of the log files suggests that CloudTrail is logging API calls made by CloudTrail when it writes to S3, which it writes to S3 … CloudTrail added over 170 new objects the next time I ran this query! Time to modify my configuration of CloudTrail.

Justin – 26 March 2019

Posted in Computing, Programming, System administration | Tagged , | Comments Off on AWS Logging (or “why am I being charged for free-tier S3?”)

A 3D printer diary – printing another box

Posted on March 14, 2019 by Justin

Following the 3D printer’s instructions online and in the book that came with it, I heated the print head up to working temperature, then carefully used a pair of tweezers to tweeze any filament off the brass nozzle. Doing this a few times removed quite a bit of the stringy stuff.

Then I tried another print job, and here is the result, with a Londoner for scale.

Some lessons were learned from this print job, too. The short version is as follows

  • Don’t start a print job at 8pm. You’ll get a late night.
  • My Cura settings were wrong.
  • The stringy version last time was caused by a partly-blocked nozzle.
  • Supports are a great idea.

The quality of this box is much better. I think this is because the filament was coming through the nozzle at the right speed. Here is an action shot:

In the picture above, it looks like the supports are quite solid. They were easy to break off with fingers. The photo below shows what the supports are like and also shows off the clean base of the box. Compare that with the previous one. And the one before that.

There were a few rough spots on the base and on the inside of the container, which just need a bit of gentle filing to correct. It’s sturdy, and as functionally good as the original.

As mentioned before, I’m using Cura to slice the model, because Cura can export to .g3drem files. I corrected my Cura settings by reading the GitHub page of the guy who wrote the .g3drem plugin. Why is reading the documentation the LAST thing we ever do?

Posted in 3D printer, Lego | Tagged , | Comments Off on A 3D printer diary – printing another box

A 3D printer diary – printing a box

Posted on March 12, 2019 by Justin

3D printing takes AGES! Even something as simple as the small container shown below takes four hours!

The 3D-printed version is on the left.
The original (injection-moulded) is on the right.

A lot of lessons were learned from this print job. The short version is as follows:

  • Don’t start a print job at 8pm. You’ll get a late night.
  • Supports are a great idea.
  • The raft underneath was a waste of time on this model.
  • The box is flimsy. See below for why.
  • My Cura settings were wrong.
  • The nozzle was still slightly blocked (as I found out a few days later).

3D printing involves layering tiny amounts of hot plastic, in layers of 0.1mm (or more, or less, depending on the printer). The software takes a 3D file (like a .STL file or a .OBJ file) and “Slices” it into hundreds of layers. This takes time. The white box above took nearly four hours to print, and I got to bed at midnight.

The observant will notice that the top of the box is a different colour. With 12 minutes to go, the white filament ran out. I cheekily pushed the end of a yellow length of filament into the top of the filament feeder, whilst it was still running, guesstimating the correct time to do so. I’m sure one is supposed to pause the model whilst doing this, but it worked for me this time.

The resultant box has weak sides, and feels flimsy. It feels like it’s made of thin paper, and the quality of the sides is terrible. There are two possible issues: one is that my settings in the Cuda software are incorrect. I’m using Cuda to add supports and the raft – because the official Digilab software won’t export in the correct format. the other issue (as I found out) was that the nozzle was still blocked.

The underneath of the box is much better than last time. Apart from a few stringy bits, it’s relatively clean. The supports were very thin, as they are meant to be, and broke off easily.

I’m not convinced that a raft was really necessary. It took 31 minutes to print the raft, even before starting to print the supports and the model. I felt that the raft was a waste of time in this case. There are good examples where a raft is important, particularly for models which don’t have a flat base.

Next, we will try giving the nozzle a really good clean, and try again.

Posted in 3D printer | Tagged , | Comments Off on A 3D printer diary – printing a box