SThe 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 need to be accounted for in the software:
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.
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. I was also wondering whether there was a more direct way of talking to the TinyG via a more flexible input, such as a live webcam image. So far I've been playing with Processing to generate the tool paths from a webcam, and with some serial setup should be able to send it directly to the TinyG.
Following the note above, I attempted to use Processing to generate G-code from a webcam feed. The image to toolpath workflow turned out OK, but the difficulty was in actually getting the G-code onto the TinyG.
I had figured that it would be possible simply by writing to the TinyG's serial port, which was more or less what Coolterm and the ChiliPeppr webapp was doing. To test this, I began by piping my G-code output from Processing straight into my terminal tty port
cat /dev/ttys000, and it came out looking something like so (left).
I should have noticed something to be amiss when this process was causing my terminal window to bug out, with strange errors affecting the way the characters appeared on screen. Nonetheless, it seemed to be putting out the right G-code in the right order so I decided to send it straight into the TinyG. This didn't seem to do much at first but very soon the TinyG's SpDir pin began to flash red incessantly, and the board wouldn't respond to the reset button or any other kind of interaction. This was worrying -- I thought I might've bricked it. Turns out the TinyG is actually extremely susceptible to these problems and there are several forum threads devoted to people who have accidentally crippled their board. The most likely reason seemed to be that by sending the G-code without the appropriate parsing or perhaps throttling the TinyG's limited buffer by sending it all at once caused an error in the firmware binary, basically screwing the whole board up inside out. To fix this, I had to follow TinyG's instructions for totally erasing the board using AVRISP2 and Atmel Studio 7 (now installed on the Arch shop atmelice computer) and reflashing the bootloader hex to it.
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 am now trying 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.