This is a VERY short post to describe how "I" connected permanently to the underside pins on my Teensy 3.1's
To get
access to the extra pins on the bottom of the teensy, I used a dual row
header, and bent the inside pins at a 90 degree angle, trimmed, and
soldered. That's it. Easy peasy!
This shot shows the Real Time Clock crystal soldered into place.
There's some further discussion on the subject here... There are also breakout boards designed to give you easy access to these pins...
So while I'm waiting for some assistance on my Teacup Firmware implementation, I thought I would poke around a bit in the Marlin fork that Paul Stoffregen started. (Also read here.) Marlin looks like it is a bit more mature than Teacup. It has some of the same people working on it, but it supports LCD panel, as well as SD cards. Teacup was designed to be a minimalist firmware implementation to fit the constraints of many of the Arduino variants. It is written in pure C for the most part, and is better managed from the command line. Marlin is a bit larger, but not significantly so, and is written in C++. I cloned it local, and it did "compile" clean, but didn't "do" anything. The USB serial interface did initialize, in that /dev/ttyACM0 showed up, but there was no communication. A little bit of tinkering with MACROs, and I got the USB serial working. It is now successfully listening for and processing commands...
I've reached out to Nikki V from Freescale, to see if she has got any further in getting functionality working in Marlin.
Further update on my Repscrap 3D printer progress...
Here is the current schematic. Once I realized that I had blundered with the I2C based motor shield, I re-worked the design to directly drive four H-Bridges plus the stepper driver for the Extruder.
To get enough pins on the Teensy 3.1, I had to give up the second endstop on each axis, but I can now directly accept four Quadrature Encoders, and drive four DC motors.
Features included on this build:
Two Flex Timer Hardware controlled Quadrature Decoders (X/Y AXIS)
Two Hardware interrupt based Quadrature Decoders (Both Z AXIS)
Four PID controlled PWM DC motor drivers (X/Y/Z1/Z2)
Notice the "git co teensy3" ? yeah... that "co" is alias for "checkout", and I checked out the teensy3 branch rather than the known-to-be-working teensy3.1 branch.
I spent a week, off and on trying to get that branch to compile and work on my Teensy3.1. It compiled and uploaded fine, but I was not able to see the virtual serial port over USB (/dev/ttyACM0).
DAMN YOU PRIDE!
I'm already feeling stupid for taking so long to complete this project, I didn't want to admit that I was actually having troubles... I finally sent a request yesterday to the Teacup_firmware issues log, indicating what I had done to this point and describing my inability to see the serial port. I've also opened an issue on the Teensy forum to see if anyone can point me in the right direction.
No more errors in compile using Paul's most recent teensyduino 1.21
I've associated it with Arduino IDE v1.0.6, but am actually compiling
with Teacup_Firmware's Makefile using the ARM toolchain supplied with
Teensyduino at the commandline.
As I said, It compiles fine, and the HEX file uploads to the Teensy, but
I do not get /dev/ttyACM0 on Teensy reboot. If I replace the HEX with
another sketch I compiled in the Arduino IDE (any thing) I get
/dev/ttyACM0 to show up.
I know about the need to initialize the virtual serial over USB by
sending a string out from the Teensy. I do not see this happening in
Teacup_Firmware, however I know others have been able to compile and use
it successfully on the Teensy. I'm at a loss as to where to start
looking.
Any guidance would be appreciated.
Finally, I noticed my mistake.
Remember that "git co teensy3" ?
Today I backed up the branch I had been working on, and ran the proper "git co teensy3.1"
Then I modied the make file to point to the correct toolchain as provided by teensyduino, AS WELL AS THE POINTER TO THE CORE FILES. <-- This step is not documented as best as I can find. It's in the make file, but nowhere are you told empirically to modify it. Doh! <facepalm> In the issue log, Dave (drf5n) also noticed that modification was required to allow the teensy3 branch to compile as below:
#if defined (_mk20dx128_h_) || defined ( __MK20DX128__ )
// Teensy 3.0 uses a MK20DX128 32 bit ARM Cortex-M4 48 MHz Test on this for config.h
#include "arduino_teensy3.h"
#endif
I had to also update the define for the teensy3.1 processor MK20DX256 as so:
#if defined (_mk20dx256_h_) || defined ( __MK20DX256__ )
// Teensy 3.1 uses a MK20DX256 32 bit ARM Cortex-M4 48 MHz Test on this for config.h
#include "arduino_teensy3.h"
#endif
Low and behold...make clean && make && make project and I had a fairly clean compile. There were a few warnings that I was prepared for, but it compiled ... and uploaded... AND I had my /dev/ttyACM0 !!!
So at this point, I hurriedly launched Repetier Host, configured the printer port, and pressed "connect"... Mais voila!
It's a miracle!!! There is my teensy 3D printer controller, showing up in Repetier as Teacup! Yay!
Now, the real fun begins... bringing my Quadrature encoders over to Teacup, and modifying my PID loops to use Teacup's dda_clock().
Wish me luck!
My Previous blogs on this project: (little did I know I'd be working on this on and off for a year... and the real work is just beginning)
Here's a video snip of a quick demo showing the tuned X and Y carriages tracing out a simple 1500x1500 square. The purpose of this demo was to simply allow me to tune the PID parameters for each axis.
I'm currently torn between two separate development tracks. The first track is using the Beta6 version of the PID library, cascading Velocity and Position, and defining velocity profiles for each axis. I've had a fair bit of success in this track, and will publish code and results in a few weeks.
However, the main track I'm following currently is to get my DC motor control on the Teensy 3.1, working within Teacup_firmware. For expedience and simplicity, this forces me to emulate a stepper at the moment, passing STEP/DIR commands from Teacup into my motor drive logic. The reason for splitting the tracks is that the cascaded PID control does not function well in small encoder increments. Ramp time in the Velocity PID is calculated from position delta... blah blah blah..
My Teacup inspiration came from Nikki V's awesome blog series in when she builds a Teensy 3.1/RAMPS based 3D printer controller over the course of about a month. I highly suggest you go read through it. Anyway.... I have had some difficulty (my own lack of awareness) in getting Teacup compiled properly on Ubuntu 14.10 for the Teensy. Yesterday, I opened issue #122 and was answered within hours! I'm currently using the newest teensy3 folder from Paul Stoffregen's git repo https://github.com/PaulStoffregen/cores
Dave "drf5n" answered my logged issue, and set me straight. (It also looks like he's working on Marlin... I should ask him about that..)
I backed up and then removed the version of Teacup_firmware I was currently working from, then issued:
git clone https://github.com/Traumflug/Teacup_Firmware.git && cd Teacup_Firmware
After downloading and changing to the directory, I checked out the teensy3 branch:
git co teensy3
Then, again carefully following instructions, updated the correct files in the folder to reflect the Teensy hardware. The makefile also needs to be modified to point to your ARM toolchain and link to the above mentioned Teensy Core library.
However, the main track I'm following currently is to get my DC motor control on the Teensy 3.1, working within Teacup_firmware. For expedience and simplicity, this forces me to emulate a stepper at the moment, passing STEP/DIR commands from Teacup into my motor drive logic. The reason for splitting the tracks is that the cascaded PID control does not function well in small encoder increments. Ramp time in the Velocity PID is calculated from position delta... blah blah blah..