Project: Teacup Firmware

I could be getting confused with the step sizes of the motors I am using for this build with motors I used on other projects. I will check my motors and see what they are.

The methods to calculate the impact in real terms though hold good. The conclusions are a result of the calculations.

At 200 steps the argument for not using micro-stepping becomes more compelling.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Micro-stepping isn't being used to get finer detail but rather to get smoother movement without vibrations. But this means to get high speeds without vibration you end up with really high pulse rate.

Yup you are quite right

Quote
The SY35ST36-1004B is 1.8 degrees-per-step has a double shaft and a holding torque of 14Ncm.

So 200 steps it is.

So @16microsteps we get 3200 steps per revolution.

at 30,000 steps per second this is 9.375 revolutions per second. (562 RPM)

Thinking though of my Z axis which uses M6 lead screws (1 revolution gives a displacement of 1mm) then my axis would be running at 9.375 mm/second.

So on the basis of these figures and the resolutions that result 30K would appear to be a bit slow and the resolution is arguably sub micron and excessive.

No wonder 30K is slow.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Yup I am aware of the argument for micro-stepping. But have never bought into it at the resolutions it is producing. Purely because of the very real observation that you loose speed due to inherent limitations of the driving processor.

Once you have exceeded your required resolution by enough to get acceptably repeatable accuracy and precision then it is time to stop adding to it.

As with all things engineering, the end result is a compromise. A gain in one place is a loss in another.

Vibration can be reduced by using vibration reducing couplings and mountings without adding cost to processing overheads.

You choose which parameters are more important to you as the designer/builder and sacrifice the ones that are not.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

So @16microsteps we get 3200 steps per revolution.

So on the basis of these figures and the resolutions that result 30K would appear to be a bit slow and the resolution is arguably sub micron and excessive.

That, and Teacup currently isn't capable of calculating with more than 4100 STEPS_PER_MM. Luckily, all the microstepping drivers come with jumpers to reduce microstepping, so doing 1/8 or 1/2 microstepping on a threaded rod axis is a snap.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Markus Amsler Wrote:
-------------------------------------------------------
>
> #define HEATER_PIN AIO1 //DIO11
>
> which doesn't work, as DIO11 is the only PWM able
> mosfet on the extruder controller.
> Try
>
> #define HEATER_PIN DIO11
>
> instead and wire your extruder heater to the
> middle mosfet.

Markus,
I was away for a while but I'm back now and still trying to get my gen3 electronics working with teacup. I've pulled the latest from the git repo and rebuilt everything. I'm now using the stock config.h.dist file for the extruder so the above correction is in place. I've also wired the heater to the middle mosfet but I don't see any change.

My thermistor still reports 866.25 degrees and nothing I do changes either the reported value or the toggles on the LED associated with the mosfet.

Any suggestions what I should look at next?

sliptonic Wrote:
-------------------------------------------------------
> My thermistor still reports 866.25 degrees and
> nothing I do changes either the reported value or
> the toggles on the LED associated with the mosfet.
>
>
> Any suggestions what I should look at next?

The attached patches should fix your problem. Heated bed, extruder stepper trim pot pwm also won't work with current master but I'm working on it.

Once I've figured out who to push to github I'll commit them to master.

Markus Amsler Wrote:
-------------------------------------------------------
>
> The attached patches should fix your problem.
> Heated bed, extruder stepper trim pot pwm also
> won't work with current master but I'm working on
> it.

Thanks Markus. I've applied the patches and the mb firmware installed fine. On the extruder, I'm getting the error:

error: initializer element is not constant

The IDE is highlighting this line in config.h.

DEFINE_HEATER(extruder, DIO11)

sliptonic Wrote:
-------------------------------------------------------
> Thanks Markus. I've applied the patches and the
> mb firmware installed fine. On the extruder, I'm
> getting the error:
>
> error: initializer element is not constant
>
> The IDE is highlighting this line in config.h.
>
> DEFINE_HEATER(extruder, DIO11)
Strange. No idea. I tested it with current git + the 3 patches, config.h from config.h.dist and arduino-22. What arduino version are you using?
Could you post the full error output?

Markus Amsler Wrote:
-------------------------------------------------------
> Once I've figured out how to push to github I'll
> commit them to master.

if your remotes are set up correctly (which they should be if you cloned from github) and assuming that github remote is called 'origin' (usually is if you cloned) then

git push origin master

is all you should need to push to upstream master.

Some tips on good management:
ALWAYS keep your patches in a separate branch (master-local perhaps), then before pushing, checkout master and pull so your local master is in sync with upstream master, then cherry-pick your patches into master, then push. This avoids messy looking merge commits as well as errors about non fast-forward updates. If you do accidentally break your local/remote link, you can simply rename your local master as something else then re-checkout remote master, cherry pick and push.

If you want to create a new branch on github, or push to a branch other than master,

git push origin branchnamehere

is all it takes

ps: be aware of your editor doing whitespace changes, lots of your patches fail to apply for me unless I add --ignore-whitespace

> Heated bed, extruder stepper trim pot pwm also
> won't work with current master but I'm working on it.

Any idea what's wrong with the heated bed? extruder.c:195 and extruder.c:95 should grab trimpot value for PWM. Is something going on with the analog subsystem whereby it only reads the first defined analog input?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Markus Amsler Wrote:
-------------------------------------------------------

> Strange. No idea. I tested it with current git +
> the 3 patches, config.h from config.h.dist and
> arduino-22. What arduino version are you using?
> Could you post the full error output?

Hmmm. I guess my Git-fu is weak. Even though I've done a git pull, I found differences in files I never touched and weren't in the patches. I started over and got it to compile (arduino 0018).

It's now reading 18.25c which is certainly an improvement. It connects to repsnapper and repg24 but both apps lock up as soon as I send any gcode. Is 115200 possible with gen3 or should I be running slower?

Also, (and I haven't tested this thoroughly) it appears the thermistor reading doesn't change, even if I warm it up with a heat gun.

Still have not got the mosfet led to turn on either.

Getting closer though..

Triffid_Hunter Wrote:
> Any idea what's wrong with the heated bed?
> extruder.c:195 and extruder.c:95 should grab
> trimpot value for PWM. Is something going on with
> the analog subsystem whereby it only reads the
> first defined analog input?

Heated bed is on a non pwmable pin, which requires some hack to make it work.
Currently the trim pot channel is not in the automatic generated analog_mask.

sliptonic Wrote:
-------------------------------------------------------
> Also, (and I haven't tested this thoroughly) it
> appears the thermistor reading doesn't change,
> even if I warm it up with a heat gun.

Have you tried shortening the contacts, this should change the value.

> Still have not got the mosfet led to turn on
> either.

with M104 S250 or so? works here

---

[yetanothermendel.blogspot.com]

Markus Amsler Wrote:
-------------------------------------------------------
> Heated bed is on a non pwmable pin, which requires
> some hack to make it work.

I thought I fixed that recently, currently nowhere near my arduino so can't test unfortunately. Non-pwm pins should make heater.c:294 evaluate as false and trigger the block starting at heater.c:301

> Currently the trim pot channel is not in the
> automatic generated analog_mask.

try something like DEFINE_TEMP_SENSOR(trimpot, TT_DUMMY, TRIM_POT_CHANNEL) in extruder/config.h and see what happens

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Markus Amsler Wrote:
-------------------------------------------------------

>
> with M104 S250 or so? works here

w00t!

I think we're there or very close. Sourcing func.sh and using the mendel_ commands the thermistor is reading reasonable values and updating as the temp changes!

Setting temperature also works to turn on the heater.

Neither repsnapper or replicatorg works though. Perhaps I'm still clueless about how to use them with teacup. They both hang almost instantly after connecting. RepG control panel gives one accurate reading off the thermistor then hangs.

After either hangs, if I kill it and return to mendel_talk, any commands return garbage. I have to do a mendel_reset again.

FWIW, I think the earlier comment about a wiki page on getting printing with teacup is a great idea.

Thanks folks.

sliptonic Wrote:
-------------------------------------------------------
> Neither repsnapper or replicatorg works though.
> Perhaps I'm still clueless about how to use them
> with teacup. They both hang almost instantly
> after connecting. RepG control panel gives one
> accurate reading off the thermistor then hangs.

this happens always if you haven't correctly exited mendel_talk, eg by pressing ctrl+c (terminate) instead of ctrl+d (end of file).

Having said that, check out Ben Jackson's patched RepG which apparently talks to teacup just fine

> After either hangs, if I kill it and return to
> mendel_talk, any commands return garbage. I have
> to do a mendel_reset again.

try mendel_setup instead of mendel_reset before mendel_talk. if that works, something is probably setting the baud rate incorrectly.


Good to hear that you're making progress

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

More testing.

I am getting consistently low temperatures on my RAMPS/Teacup setup.

I have recalculated the thermistor tables by hand using temperatures and values taken from the manufacturers datasheets for the Thermistor and the ATmega1280. In a spreadsheet cos my arithmetic is terrible.

At a setting of 150 Deg C, RepG and Repsnapper both settle and tell me that the temperature fed back by the controller is correct.

Measuring it with a number of thermometers though I am getting a temperature in the region of 96 Degrees.

I am begining to suspect that there is some gain/attenuation set in the Atmega's ADC section.

Anyone else getting similar with a RAMPS setup ??

BTW I am using 100K thermistors.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I didn't know about Ben's RepG fork. That works great. Thank you.

I think almost everything is working now. The only bug I'm still hitting is that the extruder stepper turns in the same direction whether I send in forward or backward.

I haven't figured out the gcode to test it from the command line so my testing is only through RepG.

Is this possibly an issue with my Teacup config or should I be looking at hardware?

Yup I am testing with the newer version of repg.

There are still some issues with the Extruder motor manual controls. I could'nt get it to turn at 1rpm.

The rest runs better. (am doing comms at 57600 as per architects sugestion)

Initial connection is still a little hit and miss needed to add a timeout of 3000 and 3 retries to machines.xml.

Looking at what is being sent there is a huge float being sent. Small number of Sig digits but a huge long string after the decimal point. The number concerned has probably too many digits for teacup to handle.

I have hooked up a thermometer to the nozzle and a multimeter to the thermistor return and it looks like the controloer and firmware are correct but the thermistor either is'nt the one from the datasheets or the datasheets a FUBAR.

Abandoned the calcs and tables and building a table by hand using multimeter and thermometer.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Something I have noticed is that as I have reduced the number of thermistor lookup values from 20 to 11 the temperature runs a bunch better. More stable, less over shoot.

A bit counter intuitive you wouldn't expect one to influence the other so much.

It looks like the Thermistor interpolation needs a little bit of optimization.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@aka47
I received my Ramps setup on Monday and I am having none of your problems. I did change the jumpers on the board for microstepping . And made changes to config.h to match

X/Y = 1/8
Z = 1/2
E = 1/4

And I am using an Arduino 1280 @115200 with the newest Repg from Ben (15hrs ago at this point)

Also the speeds in config.h were changed to:

/// used for G0 rapid moves and as a cap for all other feedrates
#define MAXIMUM_FEEDRATE_X 4000
#define MAXIMUM_FEEDRATE_Y 4000
#define MAXIMUM_FEEDRATE_Z 75
#define MAXIMUM_FEEDRATE_E 1000

/// used when searching endstops and as default feedrate
#define SEARCH_FEEDRATE_X 500
#define SEARCH_FEEDRATE_Y 500
#define SEARCH_FEEDRATE_Z 10
#define SEARCH_FEEDRATE_E 200

I am using ultimachines thermistor with the thermistor table included with teacup. (same values)

I also changed the reprap.xml to reflect my steps per mm.

With thermistors:

1. Make sure to measure the thermistor bias resistor and feeling that in rather than trusting the value on the actual resistor (eg. 4590 ohms or 4780 ohms or whatever instead of assuming it's 4.7k). This will correct a bit of skew in ANY system. It may not be much at the default temp, but it can compound the issue at higher temps.

2. Your thermistor isn't placed in the centre of your nozzle (that is where you want the plastic to be), so it will never read the exact same value. You need to figure out what that difference will be (varies with every nozzle/heater/thermistor setup). If you feel it necessary, you can always compensate with the temp table.

3. Many (not all) of the default temp tables FAIL to track the thermistor curve well at the higher values (eg: over 150C and gets worse with higher temps). There is a forum thread on thermistors that details the issue. It may be worth generating a table with more data points and then removing a lot of the lower temp ones (where it is more linear, see the thread for more detail, it covers it better than I can here). Note that this depends entirely on the thermistor beta curve and how well the table tracks this curve.

sliptonic Wrote:
-------------------------------------------------------
> I think almost everything is working now. The
> only bug I'm still hitting is that the extruder
> stepper turns in the same direction whether I send
> in forward or backward.
Teacup currently only support relative E positions, perhaps its that. It means after every g1 e.. command e gets reseted to 0. G1 E-10 should turn your extruder backwards.
The other problem may be your e dir connection is faulty, or of course a firmware issue.

Repsnapper works great with the extruder.

So I am inclined to discount hardware problems. Having earlier assumed that this was the issue and tested it to death and eliminated it.

And am leaning towards Teacup v Repg245 compatibility issues. Particularly when I see a float with a large number of post point numbers being sent to teacup. Will post it up here hopefully tomorrow.

The thermistor just might be a crap thermistor yet. (may be one I bought in form Maplin, not exactly the hallmark for quality electronic components that it used to be)

I built the extruder a while ago and it may not be the one from the batch I thought it was.

Am just going the empirical route ie clamped a thermometer to the hotter part of the nozzle and stepped up the temp by 5 degrees at a time until I got the temperature I wanted for the table then measured the voltage that feeds back into the A to D and back calculated the required A to D value.

I agree the resolution at the top end is very poor on the one I have built/glued in, which is not what the tables I had for a bunch of others suggested (and what I coded up). Ah well Sh**t happens.

Got rough values onto second iteration.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

It is interesting though to consider that the python script anticipates there being a parallel (R2) resistor as part of the measuring circuit that isn't there on the RAMPS design.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Below is an output from a mendel_talk session. I don't understand teacup's behavior with regard to G92. As you can see, a G92 on Z axis is only setting the Z but a G92 only on the E is resetting X,Y,and Z as well. I don't understand this.

g0 z10
ok Q3/3 
m114
ok X:1000,Y:1000,Z:8330,E:0,F:6000
g92 z0
ok Q3/3E
m114
ok X:1000,Y:1000,Z:0,E:0,F:6000
g92 e0
ok Q3/3E
m114
ok X:0,Y:0,Z:0,E:0,F:6000

sliptonic Wrote:
-------------------------------------------------------
> Below is an output from a mendel_talk session. I
> don't understand teacup's behavior with regard to
> G92. As you can see, a G92 on Z axis is only
> setting the Z but a G92 only on the E is resetting
> X,Y,and Z as well. I don't understand this.
That's a bug. It doeset know E on g92 so assumes g92 without arguments, which resets all axis.

I hunted through all the code to find the places where E is reset, and added code to allow zeroing E, but for some reason Teacup kept stalling out. I wanted to use absolute mode, where E is reset on every layer.

Quote

As you can see, a G92 on Z axis is only setting the Z but a G92 only on the E is resetting X,Y,and Z as well.

Is this an artifical command or insists some host software on using G92 E0 ? In the later case a fix wouldn't be too hard, in the former case a fix somewhat a bit a waste of program storage space.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Is this an artifical command or insists some host
> software on using G92 E0 ? In the later case a fix
> wouldn't be too hard, in the former case a fix
> somewhat a bit a waste of program storage space.

Skeinforge in absolute dimension mode generates a lot of G92 E0. Although absolute E mode won't work zeroing all axis is a bad idea.

@sliptonic: I pushed the needed extruder changes to git.