Creating the test bench

This week I finally began to write the code which makes Medicrate operational. In my previous attempt at writing the code for my mark I prototype, I made the mistake of assembling the product fully beforehand. This was a big mistake as it made it extremely difficult to debug the code and wiring as it was all condensed into the control unit (making it very hard to rewire or change any of the electronic components). To ensure that the coding and assembly of the electronic components goes smother this time, I decided it would be a good idea to create a test bench. This would make the whole process a lot easier as all the wiring of the electronic components could be easily changed as it would all be connected using jumper cables and breadboards. This also means that different electronics can be added or removed easily.

To create this test bench, I first cut a piece of acrylic large enough to fit the base of the product on and two breadboards and then secured them in place. Next, I added the stepper motor and rfid sensor into the base of the product so that I could test the dispensing and tray detecting function using the test bench. I then began to add all the different electronic components which would be needed in the product and wired them up accordingly.

Once I had the testbench created, I then began the daunting task of starting the code. I spent the first day ensuring that each component was working and then wrote the basic code to make them work with the Arduino Nano. I then condensed all the separate sketches into one and then spent a bit of time getting it to work. Things were going quite smoothly at this point, so I started to write the menu system in the code. This is where the user can navigate through different options, editing different variables and accessing different functions. This is where I ran into my fist BIG problem. As the display used on Medicrate requires a significant amount of ram to operate, I realised that the Arduino Nano that I was planning to use for the product wasn’t powerful enough.

This made all progress grind to a halt and I spent a but of time exploring different alternative options which would be small enough to fit inside the current control unit and powerful enough to run the graphics on the display. I then settled on the teensy 3.2. A 32-bit development board which has 32x more ram (from 2kb to 64kb) and is more than enough power for any task I throw at it.

Once the new development board arrives I will continue with the code and finish writing all the different functions. If you want to find out more about this and the rest of my design process, then check out my other blog posts.