The Foundry: Put a Lid On It

In the previous foundry post, we made the foundry hugely more efficient by adding a fan to force air into it using an old hairdryer. Although it made the fire super hot it introduced many problems. It forced the tiny pieces of ash sitting in the foundry into the air, and towards anyone in a 2m radius. Some of the fuel also gets forced out which makes it less efficient. Bad all round, especially for the neighbors clothes on the washing line, which probably smelt smoky after each burn. We came to the conclusion that we needed a lid to hold in that glorious heat.

The fire burning
The fire burning with a steel tin on top to stop the ash flying out.

We went to the internet and found the easiest way to make the lid is to just make it in the same way we made the foundry itself, but with a few modifications. Firstly we made much less, we only want a lid about an inch thick (2.5cm) for a lid. This size was thick enough to be strong, but not so thick that it was unusable. We also used a plastic bucket rather than a metal one. As plastic can be bent it allows some movement to get the set lid out of the bucket without breaking either. You also need something to make the hold in the centre, we used a bottle, but if you can find something with a nice base then use that, the bottle had its drawbacks. Make sure the item you use can be ruined, and has a slight taper, because it needs to come out when the lid is set. Once put together we left the lid for a day to set, just like with the foundry.

The new lid
The new lid sitting inside the bucket setting, with the bottle in the centre to make the hole.

As you can notice in the above image we added a way to pick up the lid. This is firstly really useful to take out of the bucket, but will also be useful when we are actually using the forge and things get hot. It is much easier if we have something to actually grab on to. We used standard off the shelf D rings from ScrewFix, but anything that has a good ring and plenty of metal for the mixture to mould around then it should work fine. For us, it made the act of picking up the lid much easier.

the first lift test
The first attempt to lift the lift after it had been taken out of the bucket.

So once it was out, we left the lid out of the mould overnight, and then tried it out the next day. For the first burn with it we were gentle, and barely put on the hairdryer. This was to make sure that we didn’t damage it, we really wanted to help the curing process. You can see the difference in the below picture though, all the heat is confined inside the forge, and no ash or particulate is coming out the top. To add or remove the lid from the top we used kitchen tongs, as the D rings get very hot. We also hd head gloves to make sure we didn’t burn ourselves in the process. Safety is paramount if doing this yourself. It is easy to make a new lid but it isn’t easy to fix third degree burns! you have been warned. That being said, from our perspective that is a working forge! Now onto melting things.

The lid setup
The full setup, with the lid on it , the first burn was much gentler to allow the lid to set better, we though an extrer first burn could damage it.

Hope you enjoyed this post, hopefully there will be another update soon, but for now search the rest of the blog, as there are some awesome images of rockets, interesting history about aerospace, and you might learn something about electronics. Thanks for reading.

Semi Autonomous Robotic Platform

As part of my degree I had to complete a project as part of the third year in the field of robotics and electronics. I chose to make a robotic platform, a simple idea that could be completed to a high quality with the right amount of effort. What is a robotic platform I hear you ask? well it essentially is a small buggy/rover that that moves around an assigned area completing simple jobs such as transporting goods, picking up parcels or any job that needs a moving vehicle. Usually autonomous, and very expensive, the majority of systems are very application specific. Some simple systems without any sort of control system can cost tens of thousands of pounds, and are not easy for the average employee to operate. Tackling the problem of expensive, application specific robotic platforms was the basis of my project.

4WD robotic platform
The Nexus 4 wheeled drive mecanum robot has an arduino based control system, and mecanum wheels, but will set you back $1500

Named the Semi Autonomous Robotic Platform, the idea was very simple, make a modular system, with building blocks that could be easily interchanged, and didn’t cost the world. These modules were things like motor controllers, sensors and power systems. If a user had a working platform built from this system, it would take minimal effort to swap out any of these modules to bigger motors or better sensors. This means a user can make a robot and only buy the bits they need, and even make their own modules, as long as they fit to the standard written as part of the project.

system block diagram
The initial block diagram of the system, showing how the modules can be controlled in hierarchy structure.

In most robotic systems, mainly to keep costs cheap, there is one controller that controls everything. This idea makes sense for small integrated systems that don’t need to change, but doesn’t really work when systems need to be dynamic. For instance, say you decide that your DC motors driving your robot aren’t giving you the control you want. You source some stepper motors, but this means completely changing the motor controller and therefore the software that controls it. Because one controller is in charge of everything, the software for the whole system needs to be re-written, and re-tested. That small change could have affected any of the other systems that that controller is in charge of. Make a change that breaks something important, you could set back a project weeks. This shows how painful a setup like this can be, especially when it starts to become a complex robot. Add on top of that the potential for computer intensive algorithms being used on the robot, like route planning or SLAM, and that controller suddenly has a lot to do. My system design separates these jobs out to a selection of individual controllers, such as a system specifically for motor control, or power systems. These controllers can deal with the nitty gritty hardware, and leave the master controller to orchestrate a higher level version of control.

Final Year Project
My design, near the end of the project, with the mecanum wheels, ultrasonic sensors and multiple controllers.

The added benefit of separating out all these jobs means that multiple engineers can work on the same robot, at the same time on different areas and not be worried about breaking the other person’s design. The system specification defines how the modules interact in terms of communication speeds/type, the way to alert other modules and how those communications are scheduled. The master controller (shown in the system block diagram in green) schedules all these communications and decides which modules need specific information. Warnings, control signals and user inputs are all calculated and scheduled, then communicated to and from the required modules. A power system doesn’t care that a user has pressed a button to scroll through an LCD screen, and the master controller means it doesn’t see it.

The above video shows how the robot moves with its mecanum wheels, and how it can easy move around environments. I will explain the more technical parts of the project in a later post, but this simple idea became a very heavy hardware based project, rather than the software project it started as. I learnt about mechanical design, PCB design and good techniques associated with electronic design. For these reasons, the robot won the “Best Project” award for 2017. Thank you to: Cubik Innovation for help with electronic design, and providing PCBs, VEX Robotics for donating the wheels, and Altium Designer for providing their electronic design software. I would not have been able to produce the robot I did without them.

The Foundry: Blowing Smoke

In the last post, we saw a fire actually burning in the foundry. The concrete has set, and doesn’t fall apart while being used. After researching other designs, and using some logic, we figured we need to force more air into the system. As we designed previously, there is a large 30mm hole on the side of the forge to allow air into the fire. Unfortunately, this doesn’t seem to provide the amount of air we need to get the desired heat. We have tried a number of ways to force air into the hole, with varying success. First we literally blew into it, like you would a campfire, and it works well, but soon you start to really hyperventilate, and it’s not good. The next idea was to take a chopping board (but any board will do) and flapped it, forcing air towards the hole. This worked much better than simply blowing. Lots of air fuels the fire, and it burns really hot. The big downside is that it wastes most of the air produced, and creates some interesting smoke patterns that seem to be inefficient. Either way, it is a good cheap way to improve the forge performance.

First Tests
The foundry during its first fire, not particularly hot.

The method we eventually used to force air into the system was in the form of a fan. Before I start this section, it comes with a warning, you need to wear goggles if you try this, as will be explained. You have been warned. The initial fan was in the form of an old hairdryer, bought from a charity shop for £3. Putting it right up to the hole forced hot air directly into the hole, with very little waste air escaping. It worked very well, and the fire started to burn much hotter. It also meant we could control the amount of airflow by using the switches on the hairdryer, or simply moving it further away.

Forcing air into the forge
Forcing air into the forge using a hairdryer, the fire is visibly hotter.

Two issues came up while using this method of airflow. The first big problem is the mass of air being forced into the hole needs to go somewhere. The only place it can go is straight up, and as we don’t have a lid it just fires ash into the air. This is dangerous if gloves and goggles aren’t being worn. This ash can be hot and can take some of that fuel and heat away from the forge. A lid will fix this, and that will be covered in the next post. For this test we kept it at a low fan speed, and found a nice point where we weren’t firing ash into the air, but still giving lots of air to the fire. The second problem was that the hairdryer started getting really hot, and the plastic began to melt. Essentially this means it was too close to the fire, but if you move the fan away then the air just misses. To fix this we found a 30mm diameter iron pipe, and attached the hairdryer to it. This allowed the air to be funneled in with the fan unit being further away from the forge.

The fire burning
The fire burning with a steel tin on top to stop the ash flying out.

So what have we learnt from this fire? We need a lid. This will be a topic of further posts, but for now we know we can produce a hot fire, and the air going into the fire can be controlled. Thanks for reading, and hope to come with another update soon.

Four Bit Carry Adder/Subtractor Circuit

After creating my 1 bit full adder design found in a previous post, I decided to go for something a little more complicated. I wanted to prove to myself that the ripple carry system worked, so the obvious choice is to make a multi bit device. 4 bits seemed like a good amount, it’s a value used in some early ALU’s so it can be used in a future project. To make it more interesting I added in the ability to make the device a Subtractor at the same time. When you look at the schematic, it only requires one more device per adder, so it’s not even an expensive thing to implement, but adds lots of functionality. As with the 1 bit adder, I have attempted to build this adder using only single logic chips.

4 bit adder-subtractor circuit

The first stage is to know the logic circuit, its widely known and can be found pretty easily all over the web. I’m not going to explain how it’s created (I can always make a separate post on that) but I can describe how to use it. The aim is for the device to take two 4 bit inputs (0 – 15), along with a carry from another adder. So the adder needs to be able to output a value between 0 and 31. In binary this can be shown as 5 bits, so we have 2 outputs. This the S output is a 4 bit bus, and the Co output bumps this up to the 5 bits we need to make 31. A truth table can be made for this but it would be 32 lines long, so too much for this post. You could regard it as a personal challenge if you want to attempt it on your own.

So I got onto Altium and made a schematic of this circuit using some of the low voltage 7400 LVC series individual logic gates that I used on the previous adder I made. They come in SOT23-5 packages which are leaded a nice size to solder. Plus they are a size where it’s possible to probe the pins fairly easily. Luckily Altium shows the components as their logic symbols. Below I have shown the first two adders, the third and fourth are basically the same as the second one, which is the idea of the ripple carry adder.

The first two adders of the four found on the board

I also added a few LEDs to show what parts are on and off. This means the user can see the inputs and outputs. These LEDs run off the 5V input voltage, and have 220Ω current limiting resistors in series with them. Also, I have put in some 0.1 inch header pins so it can be attached into a breadboard and maybe even a micro.

The LEDs for the carry bits and outputs
The LEDs for the input bits

As a base of my circuit, I have decided on a double sided 100mm x 100mm board. This is quite big as you can see for the circuit I have made, but gives plenty of space for a soldering iron to get access. As well as this, it gives a nice amount of space for multimeter probes. I also tried to keep the individual logic chips in a similar arrangement as the schematic. This is meant to be used as a learning device, so it’s useful for the chips to line up with the diagram. The header pins for the inputs and outputs are placed on opposite sides of the board to make it more obvious for the user to see it. And the pins have designators written on the board so the user can see what each pin does. The input and output busses are placed in fairly logical places, and grouped together. There is no point having all the A inputs intertwined with the B inputs. The pins for the power and ground are on opposite sides with their own headers, only one needs to be connected for it to work. The LEDs that are directly attached to the pins are placed closer to the logic circuitry, but labeled clearly on the silkscreen. Most of the routing to the LEDs is on the underside of the board, else the top could get confusing. All the designators for components have been made half the normal size due to the small amount of parts used in the project. The below images show the PCB layout I created with the top copper being red, bottom copper being blue, and the silkscreen shown in yellow.

Top Copper

As you might be able to see, I have tried to keep all the power on the bottom side of the board. This leaves lots of space for the logic signals on the top, where the user is more likely to see. As you can see, most of the inputs and outputs of the circuit are also on the bottom side. This is because the way the busses work and input into the adder needs lots of crossing over and would add confusion into the design. This is why labels were used instead.

Bottom Copper

To make it easier to see, I made a larger image of the first and last adder in the series. As you can see, the only real difference in them is that the first has the add/subtract input shown by an LED, whereas the last shows the carry from the previous adder (C0). This is because the A/D bit is attached to all the adders, but the first bit doesn’t have a carry bit input. The carry on that adder is the input for the A/S. It serves the function of inverting the first bit, so that it works like 2’s complement when in subtract mode.

The layout of the first adder in the series
The layout of the last adder in the series

As noted above I used 7400 LVC series logic gates. The SOT23-5 package chips have the suffix of “BVD”. See the datasheets for each of the devices for more information. I have written a simple bill of materials below:

12x SN74LVC1G86DBVT – XOR gate
8x SN74LVC1G08DBVT – AND gate
4x SN74LVC1G32DBVT – OR gate
17x DO-214 LED’s
17x 0805 220Ω resistors
6x 5-pin 0.1″ header pins

The main downside to this type of adder is that is is very slow. Especially when you get to high bit amounts that you are trying to add. This adder will take at least 4 times as long as a single adder to add the two numbers together because the signal has to propage through 4 full adders. This problem is known as propagation delay, each logic chip will take a very short time to compute the output. Although this time is not perceivable by the human eye, if there are 100’s of logic gates in a row, then the delays start to add up and be a problem. If this circuit is to be used in a computer, it could need to make calculations thousands, or maybe millions of times a second, and a carry bit adder is not generally good at that. There are other, faster adders that I will show in a future post.

The Foundry: The First Fire

Now it’s time to test the foundry, or at least the first version of it. This also has a benefit to it. Some others who have made this style of foundry have found this process helps the concrete to fully cure, and dry any leftover water still in the mixture. This process is pretty simple, most suggest using charcoal as the main fuel. We went down the local hardware store and they had a sale on charcoal briquettes. These are small and there are plenty of them, and fit nicely in the foundry. Light the fire in any way you are used to, we used fire lighters and some cheap kindling, also from the hardware store. If you don’t know how to light fires safely, find somebody who does.

First Tests
The foundry having its first fire, drying it out and seeing whether it can survive.

We didn’t use much to start with, this is meant to be a calm fire to help cure the concrete, and test it can deal with at least some hot temperatures. It was also to see how well it burnt with the air hole we put in. Main problems we found were that the air hole did not provide enough oxygen into the system, so the fire was slightly stinted. We tried blowing into the hole a few times, and the fire definitely got bigger, but it also sprayed ash into the air, so be very careful of that. We also noticed something most blogs talk about, lots of heat escapes from the top. With the foundry having such a big opening, very little of the heat is retained, and the fire has to work harder to keep the heat at a set level. A lid is often the best way to battle this.

The aftermath
The foundry after its first test and the ash was scraped out of it.

So what have we learnt from our first fire? We need a lid, and some way to force air into the hole. This will be a topic of further posts, but for now we know our concrete foundry can withstand the heat of a fire, and is now a little bit darker from all the ash. Thanks for reading, and hope to come with another update soon.

One Bit Adder Project

One thing that has always been interesting to me is using logic circuitry in electronics. It’s easy to implement something on a microcontroller in just a few lines of code, but the real challenge comes from making a boolean project using real logic gates. It’s something we all learn about if you have taken a basic computer science class, or even digital electronics. One of the first circuits you ever learn about is the adder. It’s pretty simple, teaches you how to cancel down boolean equations, and only has a few inputs and outputs. I have decided to try and make the circuit using real components, and see if I can get it to work.

full adder layout

The first stage is to know the logic circuit, its widely known and can be found pretty easily all over the web. I’m not going to explain how it’s created (I can always make a separate post on that) but I can describe how to use it. The aim is for the device to take two 1 bit inputs, along with a carry from another adder. So the adder needs to be able to output a value between 0 and 3. In binary this can be shown as 2 bits, so we have 2 outputs. The S output represents bit 1, and the Co output represents bit 2. Below is the truth table I used, if you want a little challenge, try and get the above circuit using boolean algebra.

A B Ci Co S
0 0 0 0 0
0 0 1 0 1
0 1 0 0 1
0 1 1 1 0
1 0 0 0 1
1 0 1 1 0
1 1 0 1 0
1 1 1 1 1

So I got onto Altium and made a schematic of this circuit using some of the low voltage 7400 LVC series individual logic gates. They come in SOT23-5 packages which are leaded and a nice size to solder. Plus they are a size where it’s possible to probe the pins fairly easily. Luckily Altium shows the components as their logic symbols.

1 bit adder 1 schematic

I also added a few LEDs to show what parts are on and off. This means the user can see the inputs and outputs. These LEDs run off the 5V input voltage, and have 220Ω current limiting resistors in series with them. Also, I have put in some 0.1 inch header pins so it can be attached into a breadboard and maybe even a micro.

1 bit adder 1 schematic

As a base of my circuit, I have decided on a double sided 50mm x 50mm board. This is quite big as you can see for the circuit I have made, but gives plenty of space for a soldering iron to get access. As well as this, it gives a nice amount of space for multimeter probes. I also tried to keep the individual logic chips in the same arrangement as the schematic. This is meant to be used as a learning device, so it’s useful for the chips to line up with the diagram. The header pins for the inputs and outputs are placed on opposite sides of the board to make it more obvious for the user to see it. The pins for the power and ground are on the same side on both headers. The LEDs that are directly attached to the pins are kept close to them, and the track is fairly obvious to show where the signal is from. The silkscreen labels which LED designates which input/output. All the designators have been made half the normal size due to the small amount of parts used in the project. The below images show the PCB layout I created with the top copper being red, bottom copper being blue, and the silkscreen shown in yellow.

1 bit adder 1 PCB top

As you might be able to see, I have tried to keep all the power on the bottom side of the board. This leaves lots of space for the logic signals on the top, where the user is more likely to see. As you can see, not all signals are on the top side due to circuit constraints, but signals that do swap over are generally short jump, and straight lines, This makes it more obvious where the tracks go without having to flip the board.

1 bit adder 1 PCB bottom

As noted above I used 7400 LVC series logic gates. The SOT23-5 package chips have the suffix of “BVD”. See the datasheets for each of the devices for more information. I have written a simple bill of materials below:

2x SN74LVC1G86DBVT – XOR gate
2x SN74LVC1G08DBVT – AND gate
1x SN74LVC1G32DBVT – OR gate
5x DO-214 LED’s
5x 0805 220Ω resistors
2x 5-pin 0.1″ header pins

Interfacing a PIC and a 16×2 LCD

So in a recent project I had to implement a 16×2 LCD  on a PIC16F1827, but the system will work on most PIC microcontrollers, with slight changes to the code. For this project I am using MPLAB X v3.40, a free development environment, and a PICKIT 3, which can be bought at a number of stores online.

Setting up the MPLAB project

  1. Start off by loading up MPLAB X, if you don’t have it already, install it from the Microchip website microchip.com/mplab/mplab-x-ide.
  2. Start a new project, by going to File->New Project… or by pressing Ctrl+Shift+Nnew project
  3. The project we want is a standalone project, it should be chosen by default. Next choose the device we want, write in the box PIC16F1827 there should only be one. We want to use the PicKit 3 for the programmer. I am using XC8 as the compiler, this is available from the Microchip to9 stawebsite. Finally choose the name of the project, and where you want to keep it. Then click finish.
  4. It wont look like mush at the moment, but under Projects on the right, there should now be your newly created project, with a drop down, and a set of folders. Something like this: 
  5. To start the project, we need a main.c. So right click on Source Files, go to New->C Main File… then in the Dialog, change the name to main. After pressing okay, it should look like this: 

Connecting the LCD

LCDs have what is known as a parallel connection. This means that we send data 8 bits at a time, rather than serial where it is one at a time. The datasheet for the PIC is found on the microchip website here. The pinout is found on page 4.

PIC pinout

Register Select (RS) pin, this decides which of the two registers that is getting written to. Either the instruction register (what the screen does) or the data register (what is shown on the screen). This is connected to A4 on the PIC.

Read/Write (RW) pin, this decides whether you are writing to or reading from the LCD. This is connected to pin A3.

Enable (E) pin, is to tell the LCD when data needs to be transferred. Pulsing this pin will write or read to the registers the data on the data pins. This is connected to pin  A2.

These pins are defined at the top of the code, to make life easier for us later on.

#define LCD_RS LATAbits.LATA4   //LCD Command/Data Control
#define LCD_RW LATAbits.LATA3   //LCD Read/Write Select
#define LCD_E LATAbits.LATA2    //LCD Enable Line

Data Pins (D0-D7), are the pins that transfer the information between the LCD and the PIC. These are connected to pins B0-B7. So B0 is connected to D0, and so on until B7 is connected to D7.

Vdd and Vss are connected to 5v and GND respectively.

Contrast (Vo) is connected to a 10k pot between the 5v  and  GND.

If the LCD you are using has connections for a backlight, follow the datasheet for instructions, on mine I connect it t0 5v and GND.

The Code

Below is the function I create to send data to the LCD.

#define LCD_CMD 0
#define LCD_TXT 1 

void LCD_DATA (unsigned char data, int type)
{
    __delay_ms(100);   // short delay

    LATB = 0x00;       // reset the register to 0
    LATB = data;       // set B output to the data we want to send
    __delay_ms(1);     // short delay for data to set

    if (type == LCD_CMD)
    {
        LCD_RS = 0;    // command mode
    }
    else
    {
        LCD_RS = 1;    // character/data mode
    }

    LCD_RW = 0;        // start the pulse
    __delay_ms(1);     // small delay
    LCD_E = 1;         // enable LCD data line
    __delay_ms(1);     // small delay
    LCD_E = 0;         // disable LCD data line
    __delay_ms(5);
}

Calling this function in the main, like follows will send data to the LCD. Notice the #define at the top, these are declaring LCD_CMD and LCD_TXT. Basically, when the type is LCD_CMD the LCD is sent into command mode, by setting the RS pin. Equally, sending LCD_TXT will clear the RS pin, putting the LCD in character mode.

The information on the data pins will then get written to the LCD, by clearing RW. To actually tell the LCD that it needs to be sent new instructions the enable pin needs to be pulsed. Once this happens, the screen should be updated with the new information.

#include <stdio.h>
#include <stdlib.h>
#include <xc.h>

#define _XTAL_FREQ 500000

#define LCD_RS LATAbits.LATA4   //LCD Command/Data Control
#define LCD_RW LATAbits.LATA3   //LCD Read/Write Select
#define LCD_E LATAbits.LATA2    //LCD Enable Line

#define LCD_CMD 0
#define LCD_TXT 1 

void LCD_DATA (unsigned char data, int type)
{
    __delay_ms(100);   // short delay

    LATB = 0x00;       // reset the register to 0
    LATB = data;       // set B output to the data we want to send
    __delay_ms(1);     // short delay for data to set

    if (type == LCD_CMD)
    {
        LCD_RS = 0;    // command mode
    }
    else
    {
        LCD_RS = 1;    // character/data mode
    }

    LCD_RW = 0;        // start the pulse
    __delay_ms(1);     // small delay
    LCD_E = 1;         // enable LCD data line
    __delay_ms(1);     // small delay
    LCD_E = 0;         // disable LCD data line
    __delay_ms(5);
}


int main(int argc, char** argv) {
 
    // write "hello world!" on the first line
    LCD_DATA('h', LCD_TXT);
    LCD_DATA('e', LCD_TXT);
    LCD_DATA('l', LCD_TXT);
    LCD_DATA('l', LCD_TXT);
    LCD_DATA('o', LCD_TXT);
    LCD_DATA(' ', LCD_TXT);
    LCD_DATA('w', LCD_TXT);
    LCD_DATA('o', LCD_TXT);
    LCD_DATA('r', LCD_TXT);
    LCD_DATA('l', LCD_TXT);
    LCD_DATA('d', LCD_TXT);
    LCD_DATA('!', LCD_TXT);
 
    while (1)
    {
 
    }
 
 return (EXIT_SUCCESS);
}

Route Planning in C# – Setting up a Project

So after watching this video by Computerphile, I got inspired to make my own PC map solver. In the video they use Python, but I prefer C#, even if it takes a bit longer to set up and make. This Section is basically how I set up the system to import an image, turn it into a Bitmap, and then output the image to a file. Currently it is very rudimentary, and doesn’t do any mapping, but in the coming weeks, it will be improving with different algorithms and systems to integrate it into my university final year project.

This will be written similar to a tutorial, but some prior knowledge of Visual Studio and C# would be beneficial. As well as this, it is always good to read around the subject and watch videos. Experience with systems is what makes you a better engineer! For this tutorial I am using Visual Studio 2015.

  1. Open up Visual Studio, and start a new project by going to File->new->Project.
  2. On the left hand side under Visual C# choose Windows. And pick Windows Forms Application. Change the name to Route Planner (or whatever you want to call it) and pick the location you want to save the project to. Then Click OK.New project
  3. With the nice new form in front of you, drag the bottom left hand corner of the box, until it is about 750 x 450 pixels, this can be changed in the properties tab.
  4. In the properties tab, change the text value to Route Planner. The form should now have a title of Route Planner
  5. On the left hand side of the screens should be the Toolbox tab. In there find a Label. Drag this onto the form, I placed it in the bottom left corner. This will be the label we use to give us feedback on what is going on in the system.
  6. While the Label is still highlighted, go to the Properties tab, and change the name to lbl1. I also changed the text to lbl1, but this isn’t necessary.
  7. As with the label, drag a PictureBox onto the form. Make it as big as you want, it can always be changed later, but this is where the map is going to be shown as an output.
  8. in the top corner of the PictureBox is a small triangle, click on it, and change the size mode to zoom. This means that the image will be zoomed in to fit the box, as some of the images we will be using are small.
  9. While the PictureBox is still highlighted, change the name to pbMap.
  10. The box should now look similar to this:picturebox zoom mode
  11. This is the basic bit done, now to make it do something, we need an event. To start, we will set it up to do everything as soon as the program loads, in a later tutorial it will be triggered by buttons. But for now double click on the form. This should take you to a new page called form1.cs.
  12. There will now be a function in there called Form_Load() anything put in this function will be triggered as soon as the form loads up.The first look at code

The code posted below currently loads in an image, converts it to Bitmap, and then converts back to .png to save it again (under a different name).

final code

So what is going on here:

  • Firstly a new Bitmap variable is created, named startMap.
  • An image is loaded from a set filename is loaded into startMap.
  • For this project I used this image, yes it is very small:

  • The issue with leaving it at this point is that the image, although saved in a Bitmap, it’s not really one. The colours of each individual pixel are indexed in the .png format, meaning we cannot directly manipulate them, in the way we would a Bitmap. In Bitmap images, the colours are in ARGB format, meaning each colour has it’s own value, and can therefore be accessed.
  • To get the image in this format, a new Bitmap variable is created called routeMap, with the same width and height as startMap.
  • Using the Graphics class, the image from startMap is drawn onto routeMap in the new Bitmap format.
  • The pictureBox we created earlier is now used, by making it the same image as routeMap.
  • The label we created is also used, by updating the user that the file has been saved.
  • To prove it is the same image, routeMap is saved a .png file, and can be found in the directory that it is set to.

When run, and a map is named “normal.png” in the correct file directory (you can change this). The window should look something like this: Tutorial1 output

Notice how the image seems blurred, this is due to the picturebox zooming the image to fit the box. The blurring is anti-aliasing, and although slightly annoying demonstrates the image.

 

We are Making a Foundry!

So the new term of university is here, and we have a couple of weeks to settle into our new house. As a house we felt we needed a big project to get us going, to inspire a bit of teamwork in us, and we think we have found it! After seeing this video by Grant Thompson, we have been inspired to make a similar forge. So, over the next couple of weeks, this is what we will be making. As much as this will be a little homemade enterprise, we should be learning about business skills, basic accounting, and some safety stuff along the way; so it wont all be fun! The idea is to achieve, maybe inspire, and to make something that works, but let’s just see how this ends up.