Teacup, Gen 7 v2.0 ARM and OrdBot Hardon

Hi Guys,

New to this forum...

Working on tuning my latest 3d printer which is an OrdBot. I decided that I would use a 32 bit controller and found the really excellent Gen 7 controller by Traumflug.

I am wondering if there is a way to attach a PWM Fan for cooling prints and if anyone has done so already?

Also every once in awhile the printer pauses for what seems like an extended length when resumes. Although that behavior seems worse with some slicers than others.

Last - I noticed that Repetier Host really does not work for me with this firmware. I am currently using Pronterface. Any other UI interfaces recommended?

Thanks for all you guys help!

Edited 1 time(s). Last edit at 03/11/2017 05:39PM by lslewis901.

You could use a seven switch connected to a PWM-able pin on the SPI-header.

RepetierHost also don't work for me. Don't know why. I use Pronterface or Octoprint.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Thanks Wurstnase, Do you know of any wiring example/schematic that you could point me to?

Also I have another question to anyone, I have identified that the printer head movement is pausing in between each set of steps (wherever there is travel without extrusion) in the g-code command list.

Is there some firmware adjustment I can make for this? Or some g-code adjustment? The delay between travel and print steps is about 1-2 seconds by reckoning. Which seems pretty significant.

I also see a delay when the printer extruder and heat bed reach the set temperature. The controller seems to set there for many seconds even after the temperatures are fairly stable before it decides the next movement process can start.

Thanks

Ok, Found a prebuilt board from Sparkfun: Sparkfun Serial Controlled Motor Driver
That uses a DRV8825 to drive up to two DC motors that are rated up to 12 VDC max. That would work for a fan control I think. I just need to get me a LCP1114 and do some breadbording using the teacup firmware.

SevenSwitch: [reprap.org]

Quote
lslewis901
Also I have another question to anyone, I have identified that the printer head movement is pausing in between each set of steps (wherever there is travel without extrusion) in the g-code command list.

Is there some firmware adjustment I can make for this? Or some g-code adjustment? The delay between travel and print steps is about 1-2 seconds by reckoning. Which seems pretty significant.

Can you please send me you G-code file with that problem. Maybe you can figure out 3 to 5 lines of gcode where this happens? Also please attach your board and printer-file.

Quote
lslewis901
I also see a delay when the printer extruder and heat bed reach the set temperature. The controller seems to set there for many seconds even after the temperatures are fairly stable before it decides the next movement process can start.

That is pretty easy. There is a TEMP_RESIDENCY_TIME which you can modify to your expectation. For good tuned PID this can be around 5 to 10 seconds.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
SevenSwitch: [reprap.org]

Quote
lslewis901
Also I have another question to anyone, I have identified that the printer head movement is pausing in between each set of steps (wherever there is travel without extrusion) in the g-code command list.

Is there some firmware adjustment I can make for this? Or some g-code adjustment? The delay between travel and print steps is about 1-2 seconds by reckoning. Which seems pretty significant.

Can you please send me you G-code file with that problem. Maybe you can figure out 3 to 5 lines of gcode where this happens? Also please attach your board and printer-file.

===========
Here are the lines of g-code, on every travel move it pauses for at least 1 second...
G1 X53.527 Y70.207 E59.26733
G1 E57.26733 F2400.00000
G92 E0 ; maybe this is the problem???
G1 X129.737 Y123.850 F7800.000
G1 E2.00000 F2400.00000
G1 X129.577 Y121.865 E2.18107 F1800.000

I see in the gcode_process.c code a queue_wait() for that command.

Quote
lslewis901
I also see a delay when the printer extruder and heat bed reach the set temperature. The controller seems to set there for many seconds even after the temperatures are fairly stable before it decides the next movement process can start.

That is pretty easy. There is a TEMP_RESIDENCY_TIME which you can modify to your expectation. For good tuned PID this can be around 5 to 10 seconds.

Quote
lslewis901
===========
Here are the lines of g-code, on every travel move it pauses for at least 1 second...
G1 X53.527 Y70.207 E59.26733
G1 E57.26733 F2400.00000
G92 E0 ; maybe this is the problem???
G1 X129.737 Y123.850 F7800.000
G1 E2.00000 F2400.00000
G1 X129.577 Y121.865 E2.18107 F1800.000

I see in the gcode_process.c code a queue_wait() for that command.

There should no 1 second wait between any of these moves. The G92 E0 just reset the extruder. This is normal. Nothing special.
The queue_wait() only waits for finishing moves. This is not a delay.

Please upload your firmware-setting. board.XXX.h and printer.XXX.h.
Which version of Teacup are you using? The latest experimental? master? Something between?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
lslewis901
===========
Here are the lines of g-code, on every travel move it pauses for at least 1 second...
G1 X53.527 Y70.207 E59.26733
G1 E57.26733 F2400.00000
G92 E0 ; maybe this is the problem???
G1 X129.737 Y123.850 F7800.000
G1 E2.00000 F2400.00000
G1 X129.577 Y121.865 E2.18107 F1800.000

I see in the gcode_process.c code a queue_wait() for that command.

There should no 1 second wait between any of these moves. The G92 E0 just reset the extruder. This is normal. Nothing special.
The queue_wait() only waits for finishing moves. This is not a delay.

Please upload your firmware-setting. board.XXX.h and printer.XXX.h.
Which version of Teacup are you using? The latest experimental? master? Something between?

Hi, I am using the latest master with one minor mod, see dda_queue.h...

Thanks for your assistance

Your federate for the extruder is way too less. 40 means 40mm per minute. Normal direct drive extruder can achieve 100mm or more per SECOND!

Change this

#define MAXIMUM_FEEDRATE_E       40

To

#define MAXIMUM_FEEDRATE_E       4800

Currently the 2mm move for your extruder will need 1.3 seconds. I guess this will fix your problem.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Your federate for the extruder is way too less. 40 means 40mm per minute. Normal direct drive extruder can achieve 100mm or more per SECOND!

Change this

#define MAXIMUM_FEEDRATE_E       40

To

#define MAXIMUM_FEEDRATE_E       4800

Currently the 2mm move for your extruder will need 1.3 seconds. I guess this will fix your problem.

Makes sense. I appreciate the help since I am new to this firmware I tend to forget about interdependent items like that. I'll give it a test in awhile and report the results.

Thanks Wurstnase

Quote
lslewis901

Quote
Wurstnase
Your federate for the extruder is way too less. 40 means 40mm per minute. Normal direct drive extruder can achieve 100mm or more per SECOND!

Change this

#define MAXIMUM_FEEDRATE_E       40

To

#define MAXIMUM_FEEDRATE_E       4800

Currently the 2mm move for your extruder will need 1.3 seconds. I guess this will fix your problem.

Makes sense. I appreciate the help since I am new to this firmware I tend to forget about interdependent items like that. I'll give it a test in awhile and report the results.

Thanks Wurstnase

=============
Hello Wurtnase,

The printer is so much smoother now. I like how it works.

But - I have another question/problem - the serial connection to the Ubuntu OS is "iffy". Sometimes it works fine - other times it won't recognize the Gen 7 v2 ARM controller board and then I usually have to power off the board. Sometimes it also takes a restart of Ubuntu. I'm running it on a Intel i5 laptop with enough memory. I've not had any serial problems or issues with this same laptop and the other two 3D printers I have. Both of those are Atmel 2560 Mega based controller boards.

Any ideas about if this is a firmware setting again that I've managed to screw up or ???

Thanks

L

Ubuntu has the unfortunate of trying to "automatically" deal with serial devices. It simply sends messages there and looks what happens. The really bad part: these actions are very well hidden, so far I couldn't track that down.

One thing is Modem Manager: See here

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Ubuntu has the unfortunate of trying to "automatically" deal with serial devices. It simply sends messages there and looks what happens. The really bad part: these actions are very well hidden, so far I couldn't track that down.

One thing is Modem Manager: See here

Thanks Tramflug, I was reading about how Ubuntu handles USB ports last night. For some reason I did not however stumble across your article. Although one would have thought I would. In fact I now recall reading through it about 3 or 4 months ago when I was first putting together the Gen 7 board. I guess I made the mistake of testing the USB serial communications with a Windows 7 system first (my work laptop), which worked flawlessly.

I did read something about Pronterface having some issues in Ubuntu as well and so when I started it from the term, I saw one compile error output to the console on startup. So I went and pulled down the latest version onto the Ubuntu system and eliminated that error.

That updated several libraries as well and after that I did get one fairly successful print before the end of the night. I am still setting extrusion flow rates as you can see from the print image. I also found that my cheap Chinese MK10 hotend had a slightly short PTFE tube causing flow issues as well.

But I think I will also need to do the Modem Manager change as well.

I appreciate ALL the help everyone has given me!

In regards to the USB communications issue, I found that Ubuntu was toggling the USB connection between ttyACM0 and ttyACM1. So I wound up making a UDEV rule. While I understand this is not the best approach due to some possible USB port issues - I decided to try it with good luck so far.

My rule was added to the etc\udev\rules.d folder as 90-local.rules.

First you have to find out the particulars about your USB device. Next you need to know what other UDEV rules are already in place. Below are my to rules, 1 to set the permissions and group, the other to set the ttyACM ports to a symbolic link file called ttyUSB1.

What this does in reality is to put all ttyACM ports owned by the MCP2200 device out to the port ttyUSB1. Also note that the other port or ports as the case may be continue to work as well.

I did try to debug the USB issue further but saw nothing significant related to the USB device in the Ubuntu logs or by monitoring the USB device using udevadm monitor. I must note that the laptop I am using also has a couple of other built in devices (camera and mouse) using USB ports, and my rules changes have not affected them at all.

# usb-devices

# T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  8 Spd=12  MxCh= 0
# D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 8 #Cfgs=  1
# P:  Vendor=04d8 ProdID=00df Rev=01.01
# S:  Manufacturer=Microchip Technology Inc.
# S:  Product=MCP2200 USB Serial Port Emulator
# S:  SerialNumber=0001610827
# C:  #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
# I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
# I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
# I:  If#= 2 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="Microchip Technology Inc.", ATTRS{product}=="MCP2200 USB Serial Port Emulator", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ATTRS{serial}=="0001610827", MODE="0666", GROUP="dialout"

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="Microchip Technology Inc.", ATTRS{product}=="MCP2200 USB Serial Port Emulator", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ATTRS{serial}=="0001610827", KERNEL=="ttyACM[0-9]", MODE="0666", GROUP="dialout", SYMLINK+="ttyUSB1" 

I wonder why my controller takes so much time to boot and thought its the controller itself. Now I know it's the modemmanager.
I added

ATTRS{idVendor}=="0483", ENV{ID_MM_DEVICE_IGNORE}="1"

for my Nucleo-board in a /etc/udev/rules.d/77-stm.rules

sudo udevadm trigger

and it works like a charm...

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
lslewis901

# usb-devices

# T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  8 Spd=12  MxCh= 0
# D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 8 #Cfgs=  1
# P:  Vendor=04d8 ProdID=00df Rev=01.01
# S:  Manufacturer=Microchip Technology Inc.
# S:  Product=MCP2200 USB Serial Port Emulator
# S:  SerialNumber=0001610827
# C:  #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
# I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
# I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
# I:  If#= 2 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="Microchip Technology Inc.", ATTRS{product}=="MCP2200 USB Serial Port Emulator", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ATTRS{serial}=="0001610827", MODE="0666", GROUP="dialout"

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="Microchip Technology Inc.", ATTRS{product}=="MCP2200 USB Serial Port Emulator", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ATTRS{serial}=="0001610827", KERNEL=="ttyACM[0-9]", MODE="0666", GROUP="dialout", SYMLINK+="ttyUSB1" 

Thanks, this is a worthy contribution. I just wonder why it needs two rules and why your choice is 'ttyUSB1' instead of, let's say, /dev/3dprinter.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I could need two rules when I accidentally remove the controller from USB before disconnecting the serial connection. The the tty will change.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I did two rules by the method of try and test. First I did rule just for the permissions and group. Then I added the second rule and used the same values but also added the symbolic link. I just never went back and took out the first rule and retested I was also thinking at the time I would have to have two rules, one per tty port assigned. Then I discovered the regex ttyACM[0-9] through Google.

Also I named it as a tty"something" device so that I could potentially see it when looking at all the tty devices using the ls-la /dev/tty* command

Could be called whatever I think.

Hello Everyone,

I have another observation and possible question about the stepper drivers. When I setup the Gen 7 board I initially used the Pololu drv8825 drivers. I then was having some sizing calibration issues and had tried using the A4988s. Later I switch to the TMC2100 drivers.

For the Z axis I am driving two steppers by attaching their cables together at the single driver. Please note that I have set the current the same for the Z axis drivers as the other single stepper motor drivers. About 0.55 VDC at the pot. This worked fine for the drv8825 drivers, but when I switched to either of the other two drivers I had to increase the current to get the Z-axis steppers even working. And they were noisy. The VDC reading for either of the A4988 or TMC2100 was over 1.5 VDC. And of course the stepper drivers got really hot.

So I switched back to the drv8825 for the Z-axis and extruder, and I am using the TMC2100 for the X and Y axis.

My question is does anyone know why the drv8825 seems to handle two steppers wired together for the z-axis just fine, but the other two drivers kind of fail.

Thanks

Edited 3 time(s). Last edit at 04/12/2017 12:38AM by lslewis901.

Quote
lslewis901
I switched to either of the other two drivers I had to increase the current to get the Z-axis steppers even working

You mean you had to change the trimpot voltage? Relation between trimpot voltage and motor current depends on the specific driver type. Some drivers give 1 A at 0.5 V trimpot voltage, others require 0.8 or 1.0 V for the same motor current.

Quote
lslewis901
My question is does anyone know why the drv8825 seems to handle two steppers wired together for the z-axis just fine, but the other two drivers kind of fail.

Apparently these DRV8825 are a good match for your setup. These stepper drivers in the Pololu form factor have to do some assumptions on motor properties. If these assumptions favor a setup like your: good. If they favor a different setup: too bad.

There are also stepper drivers without assumptions. They come with 4 trimpots, all of them have to be adjusted: [www.thingiverse.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks Traumflug,

I was mainly curious because I have done the same thing on my Prusa Clone using a Ramps 1.4 board and with the same stepper motors without any changes required for the Z-axis voltage/current regardless of stepper drivers.