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.
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.
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.
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.
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.
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.
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 inUncategorized|Comments Off on England’s weird place names
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 followingsometutorials, 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.
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.
3D printing takes AGES! Even something as simple as the small container shown below takes four hours!
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.
After printing a stringy mess, the nozzle of my 3D20 is covered in goo (filament). At room temperature, it’s a nice hard crusty smooth goo. The instructions explain how to clean the nozzle. There’s a nice video (with jolly music) that shows how to do it too:
Put the printer in heat mode to get the nozzle up to the correct temperature.
Don’t touch the nozzle – it’s 220 degrees C.
Remove filament from the top of the print head.
Don’t touch the nozzle. It’s hot.
Let the filament ooze through the nozzle for a bit.
Did we say the nozzle is hot?
Poke the cleaning tool in at the top and push out any filament.
I did this, and the cleaning tool went quite deep into the print head, almost to the nozzle. Then I pulled the cleaning tool out, and as I did so, I realised something had gone wrong. It felt like filament had been pulled out with the cleaning tool. I tried poking the cleaning tool in again, and it wouldn’t go. I guessed that the filament had solidified on the top of the metal part of the print head.
As expected, I’m not the first to experience problems like this. Here is a video, (with no sound), showing how to dismantle the print feeder, to get at the print head. Be careful not to loose the nylon spacers behind the heat-sink, behind the fan.
With filament back in the machine, a print job could be started. The results are shown below, and I’ll talk more about it in the next post.