Corey M. Rice : Fab Academy 2017

Plan for Project Completion

Presentation Date: June 21st       Date of Plan initialization: June 8th 9:00 PM EDT

June 8th (Thursday)

8:18PM: Have created many of the electronics boards for controlling motors and infrared proximity sensor. These boards are modules that will communicate along a serial bus that will carry data and power (at 5v and 12V) for all nodes. All recently created boards remain untested. In theory, a simple test to see if the boards work can be done once code is written for them. The test would be to send data across an FTDI connection, via Arduino’s IDE serial monitor and to see if the boards respond. This worked well with the ‘applications’ week testing of the board...

CAD files exist for designs of the hopper and queue. Early versions of these were done in the Week 2 assignment, but I have long since abandoned use of Autodesk Inventor for CAD work. These should be redone, and have as nice of a parametric integration as possible (for easy scalability).

Goal lists:

Photos of progress

Brought to you in high resolution, via the magic of Flickr...

final project

June 9th Update (Friday)

7:45AM: Fusion 360 is a new software for me. Maybe it is silly to try a new CAD software, but I liked the parametric system in Inventor better than SOLIDWORKS (as I understood them). Perhaps this parametric system will be similarly well designed. I will give myself 30 minutes to figure out if I like this new design software, then I will get to work designing. Watched this video at 2x speed.

8:20AM: Alright… I’m going to try modeling in Fusion 360 for three reasons: seems easy to use, it has parametric design that (I think) can be linked to an outside spreadsheet, and they have a very open/ free software licensing model (so I am not worried about losing the ability to edit these models in the future…

11:45AM: All parts designed. I think they will work, but don’t want this version to be my final product. They look functional, but do not have any sort of aesthetic appeal… I started the prints and then went out to enjoy the start of the weekend. A little ice cream with my girlfriend, and a birthday party with some friends while watching the NBA finals.

June 10th Update (Saturday)

8:30AM: The prints failed. I got up early, and both of the 3D printers that were running my work failed. It seemed that the prints were knocked off the heated beds, and then then the remaining filament balled up around the extruder. So, I cleaned the printers and started them on a second attempt. Frustrated by the delay. I need to see if some of these things make their press-fit connections. If this round of prints fails, I will do small prints that will just let me see if the 3D press-fit pieces are the right size.

June 11th Update (Sunday)

1:00PM: Headache -- slow morning. Lots of coffee, eggs and potatoes. Rather than go into the lab, I began the coding work for the nodes of the project. First, I will want to make sure that I can drive the DC motor and the Stepper motor at all. This should be just a quick implementation of the example code (hopefully). Beyond that basic movement, I need to make these motors run as the result of serial commands, so that is another element that needs to be figured into the code. Furthermore, it would make sense to implement this serial communication as an ‘Interrupt Service Routine’ (ISR) so that the serial communication can happen at any time, rather than require the large waiting periods that hung up my previous work with charliplexed LEDs.

9:00PM: Busy day with lots of distractions, but The code is now mostly written, and gives no compilation errors. All of the ISR content is stored in comments, rather than fully integrated. The next step is to make sure that the motors will have their needed 12V of power. Designing the power/ serial board is next up and I will cut it in the morning.

June 12th Update (Monday)

8:10AM: I came into the lab and made the new power distribution board that will allow me to have 12V and 5V delivered to the serial bus. This board also integrated a 2.1mm Barrel Jack, which will allow me to run the entire device on wall power easily, with a quick connection point. I was, however, surprised when I went to solder on the barrel jack, because it did not fit correctly. The actual part has a post on the bottom, which would have required a hole in the circuit board to fit nicely. The Eagle Library made no reference to this extension of the barrel jack, and consequently did not drill out a hole to accommodate it. Instead, I just used a knife and cut the small post off. This was not a big problem, but I was surprised that the Fab parts library had missed this detail. Having such a nicely curated Eagle library has spoiled me.

8:55AM: Went to check on the 3D print that I had set on Sunday evening. It failed. Another ‘golf ball’ error. This means that my prints have now been successful 1/6 times. I will need to think about how to accommodate this problem as I move forward. Instead of dealing with it right now (as there is no one around to help) I will continue my focus on getting the code and motors to work together.

10:30AM: Good news and bad news. Good news: the power board works well and interfaces with my boards just fine. Bad news: if you don’t hook it all up just right, you can kill things. The Motor driver IC on my DC Motor board actually started glowing and gave off a bit of the magic blue smoke upon being plugged in wrong. So that was peachy.

10:45AM: so, I started to work on the stepper motor code. One of the problems is that I am not sure if my bipolar stepper is connected with the right cable order, although it is soldered in place. So I systematically changed all of the 4 pins until I found an arrangement that worked well. The motor will spin, although it is a bit erratic. I will keep playing around with it to make sense of what is going on. My guess is that the timing is not quite right for the step sequences, but it is hard to say at this point. I am tempted to try and run the unipolar stepper board that I designed, even though it would have the unipolar stepper motor that I have running at a much higher voltage (12V) than it is rated (5V). If it worked well, it may be the simplest way for me to get controlled motion…

10:50AM: The unipolar stepper worked, although it ran very hot. So, weighing my options, I found a 12V unipolar stepper motor on Amazon with the same hookups. The motor is from Adafruit in New York city; but will arrive quickly because of Amazon Prime shipping. This is definitely a cost-benefit decision. The new motor will be smaller and easier to deal with than the one that I had been assuming I would use. It also has a differently shaped shaft, that would not require a set screw. I believe that I can even use the 5V stepper that I have to estimate the footprint of the motor as well, for mounting holes and the ilk. Anyways, back to the lab to mill another DC motor board…

June 13th Update (Tuesday)

7:00AM: Well, the Cavaliers lost the NBA finals… Hopefully, other things go better today.

7:45AM: a little work with the electronics allowed me to get things moving. Also, I think I killed by FABISP programmer. The power LED blinked a few times, in a way that seemed odd and how is not recognized by the computer. Luckily, I bought an AVRISP2 as a backup. I will still need to be more careful when attaching the programmer to a board. In the future, I would recommend 6 pin IDC connectors so that I can’t accidentally kill boards. This time I was lucky to not harm the computer.

10:00AM: Evaluated how the printed parts all fit together and making adjustments. The printers are still a bit squirrely.

2:00PM: Finally got a good version of things on the printers, and it will be a while. The hopper body is estimated to take 9 hours to print. The queue and agitator will only take one hour to print.

6:00PM: The code is working mostly as I would like it to. I can send a single char to the serial bus, and the nodes both ‘hear’ it and can respond appropriately. It is not run by interrupt routines, which would be better. This means that a node cannot receive a new char message until it has finished a task and resumed waiting for incoming characters. I also need to do some testing to see how much I need the stepper and geared motor to turn the correct amounts.

8:45PM: I got the queue and agitator off the printer, and set some updated versions. The hopper body is going well, but is still only about 2/3 done. I can’t believe how long this print is going to take… I feel as though I should change my designs so that I can shorten the amount of time that the print will take. Perhaps that can be a future goal. Use a stepper for the agitator, which is smaller; and should shorten the hopper’s print time.

June 14th Update (Wednesday)

9:00AM: Hustle into the lab before the first round of presentations get started. I am fascinated by what I see. Some of the projects are really good, and definitely change my focus. Neil spoke a lot about how the projects should be a ‘finished product’ and that the feeling you should have is one of ‘almost magic’ with a project. That frankly made me nervous. Up until this point, I had been focused on making things work. I am questioning the scope of the project that I took on… However, there is no time for that. Instead, I need to get my focus back and make progress on the goals.

5:00PM: I have been in the lab all day and got sidetracked and frazzled. A friend needed some help with a project they were working on, and I lost direction with what I wanted to accomplish. I did actually get the system to be able to move a pill through the entire hopper assembly successfully. For that, I was elated. It turns out that the system works better if it is on a slight tilt backwards. I spent time trying to make a new stepper driver board and redesigning the hopper to use two stepper motors to drive the system. The tug-of-war between making something work and making it looked finished seems to have me stuck. I need to recollect myself. Time for a dinner break.

9:00PM: A few hours of being off task, and I think I’ve got it. I need to stick to my original plan, but just add in a housing for level 2 success. I don’t think that I will make it beyond there. There is not enough time, with all of the things I have to do between now and my presentation. Tonight I will work on some code, circuit redesign (for the LCD, new stepper board, and button matrix) and try to explore how to change my 3D models for the hopper.

June 15th Update (Thursday)

The code is still up and running for the stepper motor and the geared motor. I have no calibration for how much/ how long they should run at this point. I am just happy that they are working and driven by simple serial commands. It has become clear that although these boards will work, I would do better if I redesigned nearly all of my electronics. I don’t believe that I have time or components for this right now, but closing the feedback loop for the pill handling system (motor 1, motor 2, IR sensors, etc.) as well as the interface area (LCD, Keypad, buzzer, WiFi, etc.) would make more sense. I could then have my electronics more accurately mimic the physical objects they are operating, and push all of this work a little closer to two long-term goals: (1) adding multiple pill handling systems and (2) making the pill handling systems ‘plug and play.’

After a little time to reflect on what I saw yesterday, in the first round of final presentations, I was very impressed. I was also scared. Everyone’s work seemed so great, and my project feels like it still has a ways to go… Instead of getting down and out about this, instead I must get to work. This afternoon was spent redesigning the 3D printed parts of my device, so that everything will work together more harmoniously, and give a more finished look to the entire project. I also wanted to redesign what motors I am using to drive the agitator and the queue, since they seemed to be hard to control. I switched them both to the 5-12V unipolar stepper motors, and redesigned the driver board for these so that I could make them smaller and use MOSFETS that I have in larger supply.

June 16th Update (Friday)

Canceled trip extension to Columbus: I needed to get more work done.

The two large prints are done. They took 9 hours each but, luckily, I could run them side-by-side. I am pleased with how they came out, and they fit together nicely with the M4 screws as expected. I was also able to completely hide the IR sensor and queue wheel in between the two large parts, which feels like a nice way to make the project appear more polished. Just to give that ‘finished look’ that Neil spoke about in the first round of final presentations. I haven’t tested the pill movement yet in this system, but it seems like it should not be a problem, since the internal workings did not change. One thing that is probably work noting: it was a pain to insert the upper stepper motor. On another redesign, I will break these two large prints into 3 prints, and give myself full bottom access to the upper stepper motor. This will also likely allow me to hide the motor more completely by removing the current rear access window.

I also finished the new stepper driver boards. These are based on the much smaller 1.7A MOSFETs. This should be enough current for each channel, although that is really just a guess. I haven’t designed a test circuit to measure anything. I hope that sometime in the future I can work out how to measure the current draw of my components in-circuit. I heard Neil talk about this once in class and it has some serious appeal, since it would let me recognize a jammed motor. Anyway, the unipolar stepper driver boards were milled and today I soldered all of the parts on. Tonight I will give them the code that worked on the first version, just to see that they are actually functional. Today I also designed a hub that should connect the serial communication of all of my parts. It has a bunch of pigtails running off the board, which should allow me to connect to whatever I make my main board out to be. Right now I am thinking a modified Satshakit, but so far I have not done anything with them at all. I did download the Satshakit Github content, but upon opening the design files, I realized I don’t have some of the parts. I wonder if I can redesign the Satshakit to (1) fit a standard Arduino header form, so I could build it later and swap it in (2) operate the ATmega328 without a crystal (3) basically scrap the Satshakit and just use the 328 in my own board design that would better integrate all of this stuff anyway. I will need to investigate thes ideas later. I am sleepy now…

June 17th Update (Saturday)

Good friend’s Baby’s first Birthday Party in Dayton, OH

Thinking during the slow parts of driving 6+ hours: I will use an Arduino Pro mini to control the device for now. It has a small footprint for accessing an ATmega328. Also, since it is commercially produced, I know it should work. Neil identified someone’s project in the first round of presentations and said that it was fine they had used a Raspberry Pi to connect things, since they had also milled some of their own electronics. I have certainly milled my own electronics – most of my parts are on their third iterations of boards made. So, it seems fine to do this for now. I can make it better/ ‘fabbier’ later if there is time.

Also, In the future I will change the shape of the large prints I made a couple days ago. Instead of 2 big parts, I could do Three, a top that holds the hopper and that stepper. A middle that basically is just the lid and housing for the queue and finally a base that is the bottom of the queue chamber, holds the lowere stepper and has the stand-off area for the cup at the bottom.

June 18th Update (Sunday)

Graduation parties to attend

Although I slept in and had a nice breakfast with my girlfriend, I am glad to get back to work today. First item on the agenda is to rework the main hub so that it will fit an Arduino Pro mini. Luckily I have some Arduino footprint items in my Eagle libraries, downloaded from Element 14. These were originally found so that a student of mine could design his own custom Arduino shield this year. Today I spent some serious time learning how to duplicate and edit parts and their footprints in Eagle CAD. It was more complex than expected, but once I got the workflow down it didn’t seem too bad. Yet another task that is only very difficult for the unguided/uninitiated. I also had to work out how Eagle associated the lbr files with active projects, once I had done my work editing the files themselves. This all took a while, but I eventually got it in time to make it to my student’s graduation party. The cake was so very good.

After the party, I picked up an Arduino Pro mini at the store, milled out the new hub board and soldered it together. Originally, I had wanted to get male and female headers to make a socket where I could plug-in the Pro mini to the hub board. Instead, it is faster and cheaper to just solder in the pins that the off-brand Pro mini already has on it; albeit, a riskier move. This will suffice. I tested the Arduino Pro mini without power but inserted in the hub board, and it programmed nicely. I plugged in the hub board, and no blue smoke. All good signs. From there I was able to reprogram the Arduino and it seemed to be working nicely. It was however getting late, so I left the lab and went to bed.

June 19th Update (Monday)

Today is system actualization day

I intend to bring things together and have them work, so that I can spend tomorrow making the video and slide. A little more last-minute than I wanted it all to be, but at least it is coming together.

I spent part of the morning building the bill of materials and calibrating the two stepper motor routines so that they would turn the correct amount for the agitator and queue respectively. I am happy with how they ended up, given the limitations that exist. I had a very hard time finding a proper spec for the motors that I had. The only data sheet I could find was perhaps a summary page, because it did not actually have that much information. I couldn’t even find a decisive number for how many steps there were to the output shaft rotation. One message board suggested a number, but they had an abysmal decimal value, since the motor is internally geared. This eventually worked out, but mostly by trial and error. There is a little bit of creep in my stepper motor motion, but it is only noticeable over more than 10 steps. I don’t think this should pose a problem for the first prototype that I need for fab academy, but I would certainly want this resolved before this could ever go into production. Maybe I would be better off to ditch the cheap geared steppers and just use a stepper with a higher native torque rating (although it is likely that I don’t need much torque anyway).

Soldering the LCD and Keypad boards

In the lab again. I had redesigned the LCD and Keypad boards from previous versions. This design work was done Sunday morning to make sure they conformed to the serial bus pinout I had decided for this project on the 2x3 headers. I also wanted to try and get the LCD circuit board to lay in the space directly below the LCD in the housing. I even flipped the LCD board design because I had though I got it wrong and that it would poke out into my electronics housing, wasting precious space. Turned out, I shouldn’t have flipped it (or at least I should have kept both files). Oh well. At least I could mill these boards today and get them up and running. The boards milled with a little bit of extra work. The Roland MDX-40A decided that the Z offset wouldn’t be just right and so each board had to have the traces cut twice at the original and lowered heights to make sure that everything was separated. Then I went through the rest of the routines of circuit making without a hitch. I cutout the boards and holes, soldered on the parts and inserted them into the housing. All of this going relatively smoothly made me feel like I am really getting better at this stuff.

Final assembly and power up

Looking at the amount of circuit boards my project takes, it becomes clear that I will need to carefully fit them all in the electronics housing that I have designed. I thought that it would be plenty of space, but it has quickly filled up. So I designed a small standoff and start 12 of them printing. I wont need these, but they should help me hot-glue all of my boards into place. (Also, I remember Neil praising hot glue as an adherent in a long-past lecture.) I desperately wanted to see if everything worked together without any blue smoke that would indicate some bad wiring or circuit design. I carefully plugged in all of the parts and applied power. It worked. All of the parts with LED’s turned on and the Arduino started blinking with that happy ‘hello world’ blink I had left on it. Everything seemed to be happily working together and, at least, not blowing up on me. Maybe my serial connections were all garbage, but I had at least not been frying boards by applying power in bad ways. Now to go home to code.

At home, I start my writing the Arduino sketch that will be able to control the stepper motors nicely. This is quintessential to the machine, because it is what does the primary task of the device. Even if nothing else worked, I would need to move pills around on a schedule and this is the program that would do it. This went rather smoothly, as the steppers were already calibrated and had simple char commands that they needed sent, in order to do their thing. I was glad this went so smoothly. Next up was the LCD, which run by an ATtiny44. This turned out to be a bit more complicated. I have a 20x4 LCD screen, which is different from Neil’s example. I played with it a bit, but it was 11:30PM and I had been working since 8:15AM I needed to stop for sleep, otherwise I would be useless the next day.

June 20th Update (Tuesday)

Wake up and get to work. Programming the LCD diver board. By 10:30 I am waist deep in the LCD’s datasheets. Reading low-level commands and trying to make sense of what is going on and how to drive the screen to do what I want. I am able to get the LCD to turn on and display letters, but they keep rendering to spaces to the left, each time the program cycles. Also, each new iteration leaves an ‘f’ character in the old position. It was not cute. I could also get the screen to present a string, but these were also misaligned from where they should be and rendered with a bunch of junk characters around the actual content. I was frustrated and decided to move on.

I went on to work on the keypad, which I had done most of the coding for previously in the ‘inputs’ week of the class. This promised to be an easy win, which could lift my spirits after the frustrating morning with the LCD. Instead, things got worse. I plugged in my FABISP, and the LED got very bright, and then dim. A faint whiff of ozone, and I knew what had just happened. Somehow I had designed the keypad board wrong (or at least plugged in the programmer wrong) so that the FABISP or the keypad board had been fried. Well, dang. This was the last day before my presentation and, as far as I could tell, I had killed my main chip programming tool. Not a good sign. So, I dug deep into my bag of stuff. At some point early on in the class I had bought an AVRISPii, just in case of this scenario. I could make another FABISP, but not realistically for today. I plugged in the new programmer, and it couldn’t recognize the board. Dang. I plugged it into the LCD, and it worked. Maybe I had killed both my keypad board and the FABISP programmer. Either way, I needed to go back to the lab today.

All the while, I am text messaging classmates, trying to look for any guidance on how to get the LCD to work. I knew there was an Arduino Library to make LCDs work, but had been programming in C, from Neil’s examples this whole time. I had become proud of how I could handle this language that was new to me. I had gotten used to make files, and the commands needed to make all of this work. I was experienced with Arduino before, but the programs in C that avoided libraries were much small and faster for the ATtiny44 chip. It wasn’t until Paul, one of my classmates, suggested that I use the programmer to upload Arduino code to the ATtiny44 that I even realized this was possible. Then I could just use the Arduino Liquid Crystal library to handle everything with the LCD screen. This was much better than what I had started to do, which was dissect that Liquid Crystal library and try to recreate it in C for the ATtiny44. While I had made progress to that end, using the programmer to put Arduino code on the chip was much more expeditious and, after having fried a board, I needed anything that worked.

I went into the lab and made another Kaypad board. I am not sure why the first one had died. Everything checked out for the board, and it seemed like it should have worked. While the board was milling, I made some more desperate moves. I realized that the ATtiny44 did not have enough space to handle the Arduino Library for the LCD and also software serial. So, instead I made a quick change to an Arduino to drive the LCD. The board I had would work, to display messages and for serial communication, but I could not do both within the same Arduino sketch because these libraries added too much overhead and overloaded the memory of the little chip. The Arduino Uno had more than enough resources for the task, and further cemented the idea that I should just try to get this system down to two simplified control boards, each based on a single ATmega328. One for the hopper and one for the control box. Future plans…

The keypad board is milled. I quickly solder on all of the pieces and test it. It works. At least, it can be powered and not fry anything. So I start coding in the lab to try and get the keypad code operational. This time I am working in C again, since it seems that two things are true for the keypad: my previous program should still work for it, and I really only need the keypad to output char codes to the main hub Arduino over serial. This means that it would likely operate faster and better if I stick to the C environment. I can avoid many of the downfalls that just made me abandon ship on the LCD’s ATtiny44 board. I freeze. Sure, it is uncecesarily cold in the lab, but this time it is for another reason. Another whiff of ozone. I immediately realize: it is 4:00PM the day before I need to present this thing and my second board of the day has died.

I frantically unplug the hub from power and the LEDs fade. Like a bloodhound, I start sniffing each of the boards incessantly, trying to identify the source of the blue smoke. Eventually, I pin it down to a stepper driver board. Im not sure, but I hope. I did have one of these boards as a spare. When I made the new ones, I kept the old one. The old one had much larger MOSFETs that were much less likey to fail. If my instincts were correct, this is where the fault had been any way, in the MOSFETs. So a larger available current would be just what I needed anyway to avaoid the same problem in the future. I swapped out the board and nervously plugged it all back in. nothing started smoking, but the motor didn’t move either. Tension rose for about a minute, and then subsided. I remembered that the code on this board was waiting for a different char command to drive the motor. Whew – relief. I reprogrammed the Pro mini as soon as I could, and it worked. The motor moved with the swapped out board. I left the lab. This was too much drama for today. I went home and tried to calm down over some ice cream. Nervous eating.

Back to the coding work. I set up the LCD to operate on its own. While not ideal, the LCD would just display a message that tracked time that remained until the next pill was dispensed, and wait for a char command from the main hub to reset the clock. The Arduino Pro mini was programmed to control the motors and reset the LCD clock as needed. Also, I wrote an initialization routine for the Pro mini, so that it could queue up the first few pills at power up. Although there is working code on the keypad, I did not integrate a need for it on the LCD or Pro mini. I can expand into keypad integration with future iterations of this project. The time is 10:00PM and tonight I need to focus on my presentation tomorrow. I stage my kitchen, take a few pictures and a video. Then I get to work on Filmora editing together a summary video. I am actually pleased with how it comes out, and this comforts me greatly. I may have only make it partially to what I called level 2 success but, at least, I have a working project and a sweet video. The slide was next and made in Microsoft PowerPoint. I compressed the video with handbrake and then uploaded the both of them. I went to bed thereafter, at 3:00AM.

June 21st Update (Wednesday – Presentation)

Had to have my roommate make sure I woke up. It is an hour drive to LCCC from my house. This morning the commute is fueled entirely by coffee and adrenaline. I can’t wait to get connected and get my presentation underway. I long for feedback about the project, and want to hear if it meets the class expectations. I have so many questions…

July 8th Update (global evaluation and project improvements)

The saga continues….

Since the presentation, I have still been busy. This summer I have a few goals, aside from Fab Academy and relaxation. So I took a few days to think about/ work on some of the projects that will improve my home. However, by the 3rd of July I was designing circuits again. One end goal that I had was to make the entire project ‘fab-able’ from the ground up. My presentation version of the project wasn’t far off, but it still wasn’t there. Also, there were a few items that didn’t work just the way that I wanted them to. So, I needed to redesign the electronics. The first order of business was to see what sorts of processors I could use, to determine how much I could consolidate the processing. My intent here was that the less distributed the processing, the better connection I could apply between a local set of inputs and outputs (the keypad and screen or light sensors and motors, etc…). The hope being that coding for inputs and outputs on the same processor would let them have a more reciprocal relationship. To determine which processor was possible, I started with the idea of modifying a satshakit. Many of my peers in the class had success with this. Reportedly, these can just operate as an Arduino Uno, since they have the same ATmega328P as these commercial boards. So, I wrote a mock-up code that would include all of the needed libraries for my control panel (since experience suggests variables hidden in libraries are the most common source of memory overload). The simple code example compiled for an Arduino Uno and, better yet, it took only 27% of the memory. A modified satshakit would work.

So far as I could tell, the only real hardware requirements for getting the ATmega328P running was a 16MHz crystal and two 22pF capacitors. I had three crystals and no capacitors of this size. I designed the newest versions of the board with the 20MHz resonator that is a part of the Fab.lbr in Eagle and the ATmega328P datasheet said could work at 5V operation. [Later, I realized that the Arduino IDE wouldn’t like this and, since timing is a key element to my project, I would need to switch back to the 16MHz crystal and order some capacitors. I may be able to modify the Arduino IDE to accommodate the 20MHz resonator, but could not find any examples of this online, and figured it was best not to tempt that dragon. I didn’t want time flowing faster than reality in my microprocessor.]

The boards were totally new. I started at the satshakit micro, but changed every part except the microcontroller. The entire control panel was able to be driven by one chip. This integrated the 20X4 LCD, keypad, a hardware serial bus and an ESP8266 with proper 3.3v regulation and logic level shifting through MOSFETs. The control panel also got a dedicated power regulation board that housed the buzzer. The hopper also got a redesign, with both stepper motors being controlled by the same ATmega328P chip. Also attached to this hopper chip was a simple indicator LED and a pinout for a load cell breakout. (The HX711 chip I wanted to include was not available on octopart at the time of the design, so a board from Sparkfun will suffice. This breakout board could be swapped out for directly controlling the load cell, if I found that there would be enough precision with a little testing in the distant future.) Finally, on separate boards attached to the hopper’s ATmega328P, are three IR phototransistors and IR LEDs that I could use as a crude encoder and visual check for a pill’s presence or absence in the queue.

I was excited to mill the boards into existence on the Roland MDX-40A, and tried on Wednesday July 5th. For the first time in 4 months, I broke a 1/64th end mill. I then had to resort back to the sub-prime bits I had since stopped using. I also received my global evaluation feedback this day. So, while in the lab waiting for boards to mill, I addressed the feedback from my global evaluator. As time wore on in the lab, it became clear my mill needs a tune up. I broke all three remaining 1/64th bits, even while lowering the feed rates. Terrible luck.

So, on July 7th I went to mill out the newly designed boards at LCCC, and it turned out they have very nice equipment. Their LPKF mill has a bit changer, their soldering irons are delightful and they have the best-equipped soldering stations I have ever seen. The mill turned out boards with less clearance that I am used to around the traces and pads, but it only took a little effort to get used to. I soldered on the ATmega328P with Chris Rohal’s guidance. Everything looked beautiful, and I was hopeful for this new set of boards working on the first try. It didn’t.

When I took the boards home to solder with my far inferior iron (at home, not even my local lab) it was a rough adjustment from Chris’ very nice soldering irons. I ended up separating a few traces from the board, which was a problem I hadn’t had since the very beginning of the Fab Academy course. I should have been in the lab to use that nicer soldering iron. I also didn’t have all of the parts that I needed. I was short two small MOSFETs for the logic level shifters. So, I chose to not even solder on my ESP8266 until I was that other things were working. I soldered on parts most of the parts to the control panel board, and the power board. I wanted to see if these would work at any level. The power board did not. Somehow I had traced together the 12V input and ground. Short circuiting the whole thing. For some reason I had epically screwed this up. I cut a trace on the power board and realized that I just needed a redesign. The control board was a little better. I could power it with the previous iteration of the power board (since the 2X3 connectors were the same). Apart from needing to trim the side of the board so it would fit in the housing, this board would at least take some code from the Arduino ISP programmer. I need to play with it some more to get everything working together. Also, I need to mill out more boards and order the parts that I am missing…

It seems this project will still keep me busy for a while. Once I get a final decision as to whether I graduate, I may take another break to do some of the summertime house projects I have otherwise been neglecting. I need to finish those shelves I did for the ‘make something big’ week and pour a cement composite countertop for my kitchen.