Our initial pipette holder design was further modified this week, such that it could properly be mounted to the Ender 3 frame. Then, the full set-up was assembled, with the base, stirring mechanism, pipette tips and beakers, and the coding process was continued. This included ascertaining the exact coordinates of each of the elements. 

This piece was designed to sit on top of the motor and hold the two rods at the side that act as a guide for the slider motor to slide onto.

Then, we designed these pieces to sit on top of the rods and be glued to them at the side, ensuring that the rods are securely held in place at the top and bottom.

Then this piece is screwed onto the cube so that it moves up and down to press the pipette, which will eject and draw up the liquid.

This attachment is made for the pipette tip removal, and it can be screwed directly to the right side of the frame, which will press on the ejecting portion of the pipette.

Combining all the separate pieces, we finalised our pipette holder that could be mounted to the frame.

When we tried programming our Arduino to execute the G-code instructions, we initially tried using a for loop to simplify the code by repeating certain commands. However, we realised that the Arduino would intermittently skip some of these commands when they were embedded within the loop. This skipping disrupted the intended sequence of operations, making the device behave inconsistently. 

When we researched this issue, we found that the skipping likely occurred due to timing and processing limitations of the Arduino when handling loops with G-code commands. Each G-code command would require the Arduino to process and execute it within a specific timeframe, and since our commands consisted of many quick, precise movements, the commands may have been issued too quickly in a loop. Thus, the Arduino’s processor may have struggled to keep up, causing some instructions to be skipped. 

Additonally, in a for loop, there can also be very brief delays or timing conflicts between each iteration that aren’t present when commands are written out sequentially. Moreover, if the loop’s code included any delays, condition checks, or other instructions that varied slightly in execution time, it could disrupt the timing and cause missed steps. 

To solve the issue, we removed the loop and manually wrote out each command individually, essentially “hardcoding” the sequence. Since the code wasn’t excessively long, this approach was manageable and ensured that each command was processed correctly. This was likely because the timing issue is avoided when the instructions are fed to the processor in a simpler, more direct sequence, rather than within a loop. 

Overall, the programme was designed to prompt the user with a menu of options: “Go Home” to reset the system, “Pipette” to initiate pipetting (between 1-5 cycles), and “Bring E0 Up,” a debugging option to raise the pipette to the E0 position for testing and troubleshooting. When option 2 (“Pipette”) is selected, the program prompts the user to specify the number of pipetting cycles (from 1 to 5), and the system then completes the requested number of pipetting actions accordingly.