PaulStoffregen
Well-known member
Sorry, I really do not know. I've been pretty busy with the new Teensy boards and audio stuff and library support. Haven't personally looked at 3D printer stuff in quite a while.
3D Printer Software with Teensy 3.1
- Thread starter nikkiv
- Start date
- Status
Sorry, I really do not know. I've been pretty busy with the new Teensy boards and audio stuff and library support. Haven't personally looked at 3D printer stuff in quite a while.
GhostPrototype
Member
Hey, I'm just gonna throw this out here.
I've got a fork of Marlin that's based on a very recent version, maybe a couple of weeks, that's "running" on a Teensy3.5.
For now it's just flashing some leds on step and dir pins but driving a stepper motor doesn't take much more than that.
I also got temperature readings working today and I've made speed lookup tables and thermistor tables to support it all.
Any feedback would be welcome. I'm just seeing how far I can go with this.
I've been pushing the changes to here and you can compare the changes here.
Also Paul, while I don't have any say in it, if Marlin were to implement the support into the official release, would there be any chance of some sort of adaptor board for atmega pinout to go along with RAMPS1.4? Or even an improved version of ramps with a socket for T3.5.
I've got a fork of Marlin that's based on a very recent version, maybe a couple of weeks, that's "running" on a Teensy3.5.
For now it's just flashing some leds on step and dir pins but driving a stepper motor doesn't take much more than that.
I also got temperature readings working today and I've made speed lookup tables and thermistor tables to support it all.
Any feedback would be welcome. I'm just seeing how far I can go with this.
I've been pushing the changes to here and you can compare the changes here.
Also Paul, while I don't have any say in it, if Marlin were to implement the support into the official release, would there be any chance of some sort of adaptor board for atmega pinout to go along with RAMPS1.4? Or even an improved version of ramps with a socket for T3.5.
Shoggoth43
Member
Would you be able to use one of the Teensy/Arduino Shield combos to get the pinouts? I know there's also a Teensy/Arduino pro mini converter board too available from OSH park. Not sure if that would help with the conversion process though.
GhostPrototype
Member
I'm not aware of any suitable shields or adapter boards but I really haven't spent much time search for them either.
You'd still have to make sure there would be appropriate pins going to the right places.
Analog pins for thermistors, SPI in the right place, maybe some level shifting for servos and a 5V rail.
I'm looking at this and there doesn't seem to be many places where 3.3V wouldn't work.
Endstops, thermistors, LED, stepper drivers, maybe heaters too depending on the mosfets, would all be fine with a lower voltage.
You'd still have to make sure there would be appropriate pins going to the right places.
Analog pins for thermistors, SPI in the right place, maybe some level shifting for servos and a 5V rail.
I'm looking at this and there doesn't seem to be many places where 3.3V wouldn't work.
Endstops, thermistors, LED, stepper drivers, maybe heaters too depending on the mosfets, would all be fine with a lower voltage.
Hi GhostPrototype,
As I'm planning to build a new printer right now and i tried to get an overview on all the available controller boards. Knowing and using the Teensys for quite somethime i immediately thought that a 3.5 oder 3.6 would be hardware wise a very good choice.
During this research i also read the discussion on the Marlin github about a new 32bit platform and found your posts there.
I had a look a your changes but can't really help the because i haven't done any 3D printer software.
But I had an idea for a controller board based on the teensy. The style would be similar to the ramps board, but instead of plugging the shield onto arduino, the teensy would plug into the controller board. I have also seen your TMC2130 library which sounds great because the tmc2130 silentstepsticks would be my choice as drivers.
The feature set would look something like this:
- Teensy 3.5 ord 3.6
- 5 or 6 TMC2130 SilentStepSticks with SPI control, backwards compatibility to older StepSticks
- 3 Mosfets for Heaters
- 6 Endstop Inputs
- x Fans
- 3 Thermistor Inputs
- Addon capability for PT100/Thermocouple sensors like the Duet Wifi
- ESP8266 Addon for Wifi connectivity
So feature wise it might be duet wifi copy. With the CoreNG HAL for the reprap firmware it could be possible to run that one to.
I know that the hardware probably isn't the hard work but that would be the thing i could help with.
I think the teensy deserves a place in the 3d printing community too
As I'm planning to build a new printer right now and i tried to get an overview on all the available controller boards. Knowing and using the Teensys for quite somethime i immediately thought that a 3.5 oder 3.6 would be hardware wise a very good choice.
During this research i also read the discussion on the Marlin github about a new 32bit platform and found your posts there.
I had a look a your changes but can't really help the because i haven't done any 3D printer software.
But I had an idea for a controller board based on the teensy. The style would be similar to the ramps board, but instead of plugging the shield onto arduino, the teensy would plug into the controller board. I have also seen your TMC2130 library which sounds great because the tmc2130 silentstepsticks would be my choice as drivers.
The feature set would look something like this:
- Teensy 3.5 ord 3.6
- 5 or 6 TMC2130 SilentStepSticks with SPI control, backwards compatibility to older StepSticks
- 3 Mosfets for Heaters
- 6 Endstop Inputs
- x Fans
- 3 Thermistor Inputs
- Addon capability for PT100/Thermocouple sensors like the Duet Wifi
- ESP8266 Addon for Wifi connectivity
So feature wise it might be duet wifi copy. With the CoreNG HAL for the reprap firmware it could be possible to run that one to.
I know that the hardware probably isn't the hard work but that would be the thing i could help with.
I think the teensy deserves a place in the 3d printing community too
Last edited:
GhostPrototype
Member
Hey
As you might have figured, while I've already got the software working (testbed only thus far) there is no hardware shield or anything to go along with the T35, and that would be a big step for T35 in 3D printers. For now it's mostly a big mess of dupont wires to connect the desired pins to my Ramps1.4 board. Anyway, the official support will (I hope) come when the Marlin HAL gets finished, and my next step will be getting the T35 fork compatible with the HAL by bobc.
I've been thinking about making a board like that as well, but just to get started in making prototype boards myself. So go ahead with designing one for Teensy and let me know how it goes or if you need anything. And you can shuffle the pin definitions any way you like, I have no plans for them for now.
As you might have figured, while I've already got the software working (testbed only thus far) there is no hardware shield or anything to go along with the T35, and that would be a big step for T35 in 3D printers. For now it's mostly a big mess of dupont wires to connect the desired pins to my Ramps1.4 board. Anyway, the official support will (I hope) come when the Marlin HAL gets finished, and my next step will be getting the T35 fork compatible with the HAL by bobc.
I've been thinking about making a board like that as well, but just to get started in making prototype boards myself. So go ahead with designing one for Teensy and let me know how it goes or if you need anything. And you can shuffle the pin definitions any way you like, I have no plans for them for now.
Loglow has been working on making various breakouts.
Creating a Mega board that could be used on normal Mega shields could be interesting.
Creating a Mega board that could be used on normal Mega shields could be interesting.
I did a sketch of my specifications:
Afaik everything should work on 3.3V. The mosfets will need a appropriate gate driver. I think the endstop inputs might be those which are the most in danger of over voltage.
I thought a lot about the power supply options. Heaters and stepper motors profit quite a lot from 24V.
The 5V rail is powering the Teensy, fans and maybe some IO. I thought about using the integrated 3.3V from Teensy for the ESP8266, the gate driver and TMC2130. Without tests i can't be sure if the regulator is up to it.
I have even thought about using a pololu regulator, which could be soldered onto the board.
I really like the concept of the TMC2130s. Config can be made over SPI. Control as usual with STEP and DIR.
The DIAG0 and DIAG1 interfaces look really interesting for protection as well as fault detection.
I have some ideas how to implement them in the hardware.
Overall i would like to keep the part count low. At least for the first prototypes. This would make it easier and cheaper to manufacture.
What do you think about this? Any other features you would like?
Offtopic: Should I switch to Kicad for this? I know I eagle pretty good but as the board might be bigger than the free version, it might be bad.
And should we make a new topic in Projects?
Afaik everything should work on 3.3V. The mosfets will need a appropriate gate driver. I think the endstop inputs might be those which are the most in danger of over voltage.
I thought a lot about the power supply options. Heaters and stepper motors profit quite a lot from 24V.
The 5V rail is powering the Teensy, fans and maybe some IO. I thought about using the integrated 3.3V from Teensy for the ESP8266, the gate driver and TMC2130. Without tests i can't be sure if the regulator is up to it.
I have even thought about using a pololu regulator, which could be soldered onto the board.
I really like the concept of the TMC2130s. Config can be made over SPI. Control as usual with STEP and DIR.
The DIAG0 and DIAG1 interfaces look really interesting for protection as well as fault detection.
I have some ideas how to implement them in the hardware.
Overall i would like to keep the part count low. At least for the first prototypes. This would make it easier and cheaper to manufacture.
What do you think about this? Any other features you would like?
Offtopic: Should I switch to Kicad for this? I know I eagle pretty good but as the board might be bigger than the free version, it might be bad.
And should we make a new topic in Projects?
Last edited:
GhostPrototype
Member
Could you clarify about the gate drivers?
Heaters may not benefit all that much from higher voltage since 40W is still just 40W. You can just use thinner wires because of lower current. But I really like the idea of having the option of 24V.
Please use 12V for fans. There are hardly any 5V fans in the market.
I believe the T35 and T36 were designed in such a way that they can provide enough current for ESP8266. MOSFETS are voltage based and don't use much current and I don't think the stepper drivers will either.
I've been using the DIAG0/1 for over temperature protection and through that, for automatic current adjustment.
Heaters may not benefit all that much from higher voltage since 40W is still just 40W. You can just use thinner wires because of lower current. But I really like the idea of having the option of 24V.
Please use 12V for fans. There are hardly any 5V fans in the market.
I believe the T35 and T36 were designed in such a way that they can provide enough current for ESP8266. MOSFETS are voltage based and don't use much current and I don't think the stepper drivers will either.
I've been using the DIAG0/1 for over temperature protection and through that, for automatic current adjustment.
Power mosfets do need some current from the mcu. A gate driver is something like a buffer which drives the gate according to the pwm from the mcu.
This limits the current from the mcu pin. http://electronicdesign.com/power/power-mosfet-gate-drivers
Yeah, 24V doesn't benefit the heated bed directly but stepper drivers and motors do.
I'm thinking a lot about the different voltage rails.
24V for Stepper and Heaters
12V for Fans
5V for extra accessories which run on it or generate their own 3.3
3.3V for Teensy and ESP8266.
That would be 3 step-down circuits - having a lot of components which i would like to minimize.
So there have to be some tradeoffs to be made or just whack an ATX connector on the board, because everybody has an old atx power supply at home.
With a step-up converter you could even get the 24V. It's really hard to decide on a good solution.
Temperature protection is great! As far as i have read the data sheet i could also give out a stall warning if the printerhead has run into something or detect problems with the extruder steppers. As 5 stepper drive would use another 10pins just for diag i thought about grouping them with OR-gates.
So the X/Y/Z drivers are grouped for each DIAG output and the two extruder drivers are grouped likewise. That would cost only 4 pins.
And i think it would be enough to detect errors inside the group.
This limits the current from the mcu pin. http://electronicdesign.com/power/power-mosfet-gate-drivers
Yeah, 24V doesn't benefit the heated bed directly but stepper drivers and motors do.
I'm thinking a lot about the different voltage rails.
24V for Stepper and Heaters
12V for Fans
5V for extra accessories which run on it or generate their own 3.3
3.3V for Teensy and ESP8266.
That would be 3 step-down circuits - having a lot of components which i would like to minimize.
So there have to be some tradeoffs to be made or just whack an ATX connector on the board, because everybody has an old atx power supply at home.
With a step-up converter you could even get the 24V. It's really hard to decide on a good solution.
Temperature protection is great! As far as i have read the data sheet i could also give out a stall warning if the printerhead has run into something or detect problems with the extruder steppers. As 5 stepper drive would use another 10pins just for diag i thought about grouping them with OR-gates.
So the X/Y/Z drivers are grouped for each DIAG output and the two extruder drivers are grouped likewise. That would cost only 4 pins.
And i think it would be enough to detect errors inside the group.
You should not need a "gate driver", any basic logic buffer should do provided it can provide the needed voltage, the biggest reason for needing external driving with the Teensy is that it provides only 3.3V, which may not be enough to turn on many cheap Mosfets and a good number of fets have RDSon values based on voltages above 10V. A dedicated gate driver is only needed if your switching high amounts of current. You can even use opto's if you want to mess around with different voltages at different potentials.
PaulStoffregen
Well-known member
Mosfet gates are non-linear capacitors.
On top of the voltage threshold issue, something to consider is the time required to charge the gate enough to reach and surpass the threshold voltage. If you don't care how long it takes, then by all means drive the gate from a source that's limited in current. Remember, it's a capacitor, so at the very least a resistor should be used to limit the amount of current if a normal digital output is used.
Because of their non-linear behavior, usually mosfet gates are specified in total charge (in Coulombs) rather than capacitance (in Farads). While that may seem unfamiliar, it's pretty easy since electrical current in Amps is actually Coulombs/second. If you charge with a steady current, it's easy to calculate how long it'll take to deliver that many Coulombs. If your current decreases as you go (a fixed voltage and resistor), you can do lots of math, or just compute the initial current and decrease it by some fudge-factor for a pretty useful estimate of how long it'll take.
Gate driver chips usually provide a *lot* more current than normal digital pins. Specs in the range of 100 mA to 5 amps are common. If your mosfet gate has a large "total gate charge" spec, and you want it to turn on/off quickly, you need a very large current (for just a brief time) to charge/discharge the gate. That's the main reason so many gate driver chips exist.
Usually if a large load is connected, you want the mosfet to switch on/off quickly, to minimize the time spent where power dissipates in the mosfet itself. But there's also such a thing as too fast, mostly because there's always some inductance in the load and wires being switched, and if you change the current in an inductor too quickly, its voltage spikes too much.
Very small mosfets are often marketed as "logic" mosfets, because the 8 to 24 mA from typical logic chips is enough to charge/discharge their gates in some reasonable amount of time. Like everything in all datasheets, and especially the first page listing features, it's all marketing info to get you to buy the part. Ultimately the part is a piece of silicon with a field effect gate that needs a certain number of electrons to influence the charges inside the silicon that form the conducting channel. If you care about how long it's going to take, that total gate charge spec and the amount of current you deliver to the gate are what determines the speed.
On top of the voltage threshold issue, something to consider is the time required to charge the gate enough to reach and surpass the threshold voltage. If you don't care how long it takes, then by all means drive the gate from a source that's limited in current. Remember, it's a capacitor, so at the very least a resistor should be used to limit the amount of current if a normal digital output is used.
Because of their non-linear behavior, usually mosfet gates are specified in total charge (in Coulombs) rather than capacitance (in Farads). While that may seem unfamiliar, it's pretty easy since electrical current in Amps is actually Coulombs/second. If you charge with a steady current, it's easy to calculate how long it'll take to deliver that many Coulombs. If your current decreases as you go (a fixed voltage and resistor), you can do lots of math, or just compute the initial current and decrease it by some fudge-factor for a pretty useful estimate of how long it'll take.
Gate driver chips usually provide a *lot* more current than normal digital pins. Specs in the range of 100 mA to 5 amps are common. If your mosfet gate has a large "total gate charge" spec, and you want it to turn on/off quickly, you need a very large current (for just a brief time) to charge/discharge the gate. That's the main reason so many gate driver chips exist.
Usually if a large load is connected, you want the mosfet to switch on/off quickly, to minimize the time spent where power dissipates in the mosfet itself. But there's also such a thing as too fast, mostly because there's always some inductance in the load and wires being switched, and if you change the current in an inductor too quickly, its voltage spikes too much.
Very small mosfets are often marketed as "logic" mosfets, because the 8 to 24 mA from typical logic chips is enough to charge/discharge their gates in some reasonable amount of time. Like everything in all datasheets, and especially the first page listing features, it's all marketing info to get you to buy the part. Ultimately the part is a piece of silicon with a field effect gate that needs a certain number of electrons to influence the charges inside the silicon that form the conducting channel. If you care about how long it's going to take, that total gate charge spec and the amount of current you deliver to the gate are what determines the speed.
Generally most IC's care more about the RMS current then the spike needed to get things going(provided there is some resistance in series). If you look at the Ramps1.4 schematic they drive the STP55NF06L from the Mega, with only a 10R gate resistor. I wont say that's the wisest choice since it would provide a pretty hefty strain on the mega each time it switches on, about 400mA if the Mega has no internal switch resistance. I would be far more comfortable with 100R(50mA limit) in that regard. Another factor is switching frequency, I believe Marlin switches the ramps fets in the 10's of hertz, which is another reason that the 10R may work(who really knows they have been known to die).
Another useful feature of the buffer/gate driver is it provides protecting to the micro encase the fet decides it just hates life and releases the magic smoke. The low value gate resistor plus driving a dead short to VCC or GND would certainly kill a micro quickly.
Another useful feature of the buffer/gate driver is it provides protecting to the micro encase the fet decides it just hates life and releases the magic smoke. The low value gate resistor plus driving a dead short to VCC or GND would certainly kill a micro quickly.
Any value of using teensy and something like marlin for any of the monoprice 3d printers?
Monoprice seems to be making some good inexpensive printers, looks like it's using an STM32 chip.
http://hackaday.com/2016/06/13/review-monoprice-mp-select-mini-3d-printer/
From the product page:
Compatible Software: With the ability to use both open-source and commercial software, such as Cura, Repetier, or Simplify 3D, the MAKER SELECT 3D Printer is compatible with Windows®, Mac® OS X®, and Linux.
Monoprice seems to be making some good inexpensive printers, looks like it's using an STM32 chip.
http://hackaday.com/2016/06/13/review-monoprice-mp-select-mini-3d-printer/
From the product page:
Compatible Software: With the ability to use both open-source and commercial software, such as Cura, Repetier, or Simplify 3D, the MAKER SELECT 3D Printer is compatible with Windows®, Mac® OS X®, and Linux.
@PaulStoffregen Thank you for the explanation. I know that you should consider and calculate the specs but following more the hacker style I will be using the Duet Wifis mosfet design as it is proven and working. Of course I will be giving the appropriate credit to the devs as well as following the Cern OSHL.
@Donzyboy
I know the RADDS board but having the Teensy on a Due style breakout and then plugging the RADDS in, is to much many connections in between for my taste.
Also my design goal is the use of TMC2130 stepper driver (SilentStepStick) with configuration over SPI, which wouldn't work on the RADDS.
I don't really know if this solution for a 3d printer controller is something people would like, but i does follow the principle of the popular 8-bit based boards like rambo, radds... As the mcu and the stepper drivers aren't on the board,like many other 32bit controllers, the part count should be quite a bit lower and make the board cheaper. The price with Teensy and Drivers maybe won't be competitive but the flexibility (Teensy 3.5 or 3.6, replace burned stepper drivers) and computing power might win some users.
@linuxgeek
In the hackaday review it sound like the electronics is quite good. I don't now if replacing it would be any better, probably not.
@Donzyboy
I know the RADDS board but having the Teensy on a Due style breakout and then plugging the RADDS in, is to much many connections in between for my taste.
Also my design goal is the use of TMC2130 stepper driver (SilentStepStick) with configuration over SPI, which wouldn't work on the RADDS.
I don't really know if this solution for a 3d printer controller is something people would like, but i does follow the principle of the popular 8-bit based boards like rambo, radds... As the mcu and the stepper drivers aren't on the board,like many other 32bit controllers, the part count should be quite a bit lower and make the board cheaper. The price with Teensy and Drivers maybe won't be competitive but the flexibility (Teensy 3.5 or 3.6, replace burned stepper drivers) and computing power might win some users.
@linuxgeek
In the hackaday review it sound like the electronics is quite good. I don't now if replacing it would be any better, probably not.
Are there any DIY projects for creating an SLA 3D printer using firmware that could run on a teensy?
I wonder if it could be worthwhile to use a linear sensor light array that someone got working with teensy:
https://forum.pjrc.com/threads/3937...Read-TSL1410R-Optical-Sensor-using-Teensy-3-x
https://forum.pjrc.com/threads/3905...Read-TSL1402R-Optical-Sensor-using-Teensy-3-x
I wonder if it could be worthwhile to use a linear sensor light array that someone got working with teensy:
https://forum.pjrc.com/threads/3937...Read-TSL1410R-Optical-Sensor-using-Teensy-3-x
https://forum.pjrc.com/threads/3905...Read-TSL1402R-Optical-Sensor-using-Teensy-3-x
Northernboy
New member
I am looking into building a second 3D printer and I am interested in using a Teensy for a controller. Having that been said I am willing to test and assist in building a control board. I also have a CNC milling machine so I can design and make some proto type boards for testing. Where can I download the latest Marlin firmware that has been modified for Teensy?
GhostPrototype
Member
Currently it's a bit of a mess. But only for a while longer.
This is my original Marlin RCBugFix with added support for Teensy3.5 and 3.6. Unfortunately since the last merge with upstream the Teensy has been acting really weird. Also because the official hardware abstraction layer has nudged forward again, this probably won't get fixed and future development will be on the HAL fork.
This is the HAL that I forked from bobc and added the required Teensy changes. Appears to be working but is not up to date with the upstream. I'll be doing a merge this weekend and then I can move forward with a pull request.
This is the official and most current Marlin 32bit effort, but it does not yet contain support Teensies. But as said, I'll be making a PR really soon. This would also be the fork that you would want to follow in the future.
GhostPrototype
Member
New branch getting ready for merging with upstream 32bit HAL effort.
GhostPrototype
Member
Marlin is a firmware, not a slicing software. You're confusing the two.
Tady
Well-known member
@GhostPrototype i have been fiddling around with the firmware you have posted in the first link (teensy 3.5 and 3.6) . I don't have any of those so I modified it for teensy 3.1&3.2.
I got one of the ported firmwares before and the comm was dropping randomly. I have to say that yours works perfectly (tested 2h but no printer just motors spinning in the air)
But I have a big problem. The pulse width of the step signal is too short for my drivers. I found the min_pulse_width but it doesn't work. It seems to be for AVRs.
I'm not a hardcore programmer just a basic hobby type so I'm asking if you can point me to where can I modify the code for say 10us pulses.
Thank you and GREAT WORK!!!!
I got one of the ported firmwares before and the comm was dropping randomly. I have to say that yours works perfectly (tested 2h but no printer just motors spinning in the air)
But I have a big problem. The pulse width of the step signal is too short for my drivers. I found the min_pulse_width but it doesn't work. It seems to be for AVRs.
I'm not a hardcore programmer just a basic hobby type so I'm asking if you can point me to where can I modify the code for say 10us pulses.
Thank you and GREAT WORK!!!!
GhostPrototype
Member
Good to hear it's working. Unfortunately lately I haven't had much time to work on the Teensy Marlin. Although it's also waiting on getting the initial merge into the 32bit upstream. But I'm sure things will pick up now that the new Marlin release got done.
https://github.com/teemuatlut/Marlin/blob/Teensy-HAL-rebased/Marlin/stepper.cpp#L541
Take a look at the Stepper::isr in stepper.cpp. You'll find the delay logic on line 542.
It also very well might be that the logic is flawed and you've found a bug. Maybe in all 32bit HALs or just the Teensy HAL.
Let me know what you find out.
https://github.com/teemuatlut/Marlin/blob/Teensy-HAL-rebased/Marlin/stepper.cpp#L541
Take a look at the Stepper::isr in stepper.cpp. You'll find the delay logic on line 542.
It also very well might be that the logic is flawed and you've found a bug. Maybe in all 32bit HALs or just the Teensy HAL.
Let me know what you find out.
Tady
Well-known member
I spent 8 hours analizing and trying to understand C. I only know how to program in arduino I looked trough the whole code trying to add delayMicroseconds(10); and it didn't work.
To me it seems like everything happens in the babystepping rutine but if i define it the code breaks. I will look at it tomorrow. Thank you for your info)
I will stick to this firmware currentla it is 3 and a half hours in "printing" with 250000baud and it still works. The previous firmware worked for 15-30min)
I looked trough the whole code trying to add delayMicroseconds(10); and it didn't work. To me it seems like everything happens in the babystepping rutine but if i define it the code breaks. I will look at it tomorrow. Thank you for your info
) I will stick to this firmware currentla it is 3 and a half hours in "printing" with 250000baud and it still works. The previous firmware worked for 15-30min
)- Status