Contributions:

I worked on the testing and validation of TinyG as well as generating G-Code and making the machine accomplish its goals of producing a painting. I also worked on creating the format for the group documentation page and documenting Software team's work.

Software

TinyG - Testing and Validation

The documentation provided for TinyG was quite exhaustive which made the process of setting up and testing the TinyG a lot easier than we had thought. The first step was to connect to the power. We made sure to wire the power input correctly. For our initial tests, we used the power supply available in the arch shop, and set the voltage to 24 volts. The next step was to establish the USB connection and install the FTDI drivers for Mac. We then set up Coolterm and established a simple serial interface with the TinyG. We then wired the motors by finding the coil pairs which was fairly simple. We then proceeded to spin the motors according to the default G-code presets.

A note on G-Code. A standard block might be 'G1 F400 X300', indicating linear interpolation 'G1' which finds the straight path between the current position and the next, an 'F400' feedrate of 400mm/minute, and a movement to 300mm on the X-axis, depending on whether the movement is set to relative or absolute.

The next step was to find the limits of the stepper motor which turned out to be quite challenging. Overdriving the motor draws more current and results in overheating and thermal shutdown. So, this is a crucial step. According to the TinyG documentation, we could use the trimpots (plastic screws near each motor input) nearest to each axis to fine-tune the amount of voltage going into each motor. However, we struggled to find a point at which the trimpots affected the upper limit, while the motor itself refused to run at higher than F380 without stalling, which seemed like a relatively low speed. After some adjustments, this number fell to F250. We're not sure if this was just a connection issue, but a top speed of F600 was achieved after reconnecting one of the motors. This feed rate seemed adequate.

Using the TinyG JSON server and the serial port used by our TinyG board (ls /dev/ttys.*) we were able to connect the TinyG to three motors, and have it running all three axes at once.

Since we had decided to create a painting machine on wheels rather than using a rack and pinion for Y-axis movement, a number of issues needed to be accounted for in the software:

The extensible Y-axis parameters (depending on the paper used, etc.)

The dipping motion of the brush coming on and off the paper: could this be given more nuanced?

Coming back and forth from the ink pot. This would probably require returning the G-code to an absolute position of the ink pot every X number of steps.

Once we had VanGo assembled and knew the position of the ink pot, we were able to work out a simple G-code sequence for the ink to be reloaded each time. On paper our programme looked like this:

In the Processing file or otherwise perhaps using a Python script we should be able to write a simple for loop inserting this G-code sequence into the main G-code at regular intervals.

Other minor concerns:

Cabling - both the power supply and the computer are now off the moving body of the machine so we need long enough cables to give it freedom of movement without dragging its entrails along. We had a few different options for entering G-code. One was Chilipeppr, which had a nice SVG to G-code interface, amongst others, for turning edges into movements. Another was the G-code module on Neil's mods, which is similar to the PCB cutting mod but has an extra module for outputting the job as a .NC file.

Both of these were quite feasible already.

Chilipeppr - Testing and Validation

The first step is to download Chilipeppr. There are a few more steps before we're ready to use this to send G-Code to TinyG. We have to download the Serial Port JSON Server from here and build it. For Mac, the instructions to build are in the README.md file on the Github page. But we have to install Go and Go tools from this page before we can build.

SPJS currently maxes at 25,000 lines. The documentation suggests sending around 25 lines at a time each 1 second (1000 ms) depending on the complexity of the Gcode.

We can now see the serial port to the right bottom corner. We have loaded the sample G-Code from Chilipeppr. The simulation screen shows us the toolpath.

We’re now ready to start converting from SVG to G-Code using Chilipeppr, and planning our toolpaths for the watercoloring machine. I did a few experiments to convert some png files into svg, and drop them into the Chilipeppr window, to check if it converts to gcode, and produces the toolpaths. It seemed to work great! Let's try something simpler that we can do with the paint brush. We're now ready to interface with VanGo and make some paintings.

VanGo's dreams!

We had a tough time getting the wheels to cooperate. There were a couple issues: The wheels lacked traction which we overcame by using rubber bands around the wheels. In addition, the screw that held the wheel and axle together was interfering with the movement. We were able to get the wheels to move briefly. Some other functions we were able to accomplish: Dipping the brush in the ink box: Moving in the X direction: Moving in the y direction: We then generated the Gcode to paint a jellyfish.. We were all excited when we had the Gcode and ready to upload it !!! Just as we input the code, the wheels got stuck again!!! When we nudged the wheels, they moved but the loose power supply cables that weren't packaged properly shorted and ... Our TinyG got fried. We think what happened was that the V+ wire was gradually shifted out of the socket as the robot was scooting around on a shortish power lead. The V+ must have made a bad connection with one of the many loose stepper wires. At first it booted before shutting off, now it doesn't boot at all. The takeaway was: System Integration is as important as designing and fabricating a system, and programming it. (Note to self for final project...)