thanks vik, pushed

---

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

I got the same fuses related error with arduino 22 like many others:

avrdude: ERROR: address 0x820003 out of range at line 780 of C:\DOCUME~1\privat\LOCALS~1\Temp\build741311296464608723.tmp\FiveD_on_Arduino.cpp.hex
avrdude: write to file 'C:\DOCUME~1\privat\LOCALS~1\Temp\build741311296464608723.tmp\FiveD_on_Arduino.cpp.hex' failed

After a little surfing I found the exact same problem at [www.avrfreaks.net]
Looks like the problem is the arduino ide doesn't remove the .fuse section while copying from the obj file to the hex file. It then tries to flash a hex file with the .fuse section still present, which is obviously at an invalid address.
I haven't looked deeper into the arduino ide issue.

Also it looks like something like the attached patch couldn't hurt (untested!!)

If you enable DEBUG, gcode_process.c will not compile because the "M"codes 140 and 141 are duplicated in the DEBUG section (circa line 385). I've moved mine to 150 and 151 respectively.

Vik :v)

moved echo on/off to M240/241 in repository

---

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

Currently there's no working homing code, correct?

I really like nophead style homing. Only home on controller reset/startup. With the reasoning if you have lost steps, something went so wrong you reset the machine anyway. And If you start the machine the first thing you do is usually homing. We would then need some custom G/M code to undo G92. G28 would then home to the last G92.

Also an "home to max" define would be really helpfull. You could then place the z-axis endstop to the top, and do something like G92 Z150 G1 Z0 to set the z zero height in software.

(Besides I need the "home to max" feature anyway for my x-axis. Currently I print mirrored parts, because I placed the x-axis in the wrong orientation into the frame, which results in a left-hand-x-y-system (and no I wonn't touch the x-axis). "home to max", X_INVERT_DIR would do the trick)

We could also simplify the endstop search algorithm, to simply move negativ until we hit it, and if we're in the endstop move positiv until we leave it. This has the advantage you can home without problems even if you're deep in the endstop. That's quite usefull, so you can set the z-endstop way too high an set the z zero height in software like above.

in_endstop = x_min()
do{
  if(in_endstop)
    x_step++
  else
    x_step--
}while(in_endstop == x_min())

Markus Amsler Wrote:
-------------------------------------------------------
> Currently there's no working homing code,
> correct?

Mostly, yes. I wrote something that mostly worked, which you can find here, I'm not at all satisfied with it and am working on something much better. Current progress (and lack thereof, USB port on my laptop died, currently no way to test stuff) is on the "master" branch in the same repository.

> I really like nophead style homing. Only home on
> controller reset/startup. With the reasoning if
> you have lost steps, something went so wrong you
> reset the machine anyway. And If you start the
> machine the first thing you do is usually homing.
> We would then need some custom G/M code to undo
> G92. G28 would then home to the last G92.

I saw a different part of that example - that homing should be done in a foreground loop and respect endstops, while regular movements (G1) should NOT respect endstops. In essence, endstops for that sort of thing should be done in software on the host machine. This makes some sense if you think about false positives on the endstops (caused by a bug crawling in the endstop or by electrical interference, whatever) which could easily cause aborted lines, missed steps etc.

I also saw that the two types of movements are so different that they shouldn't be handled by the same code. Examine for instance the current implementation of G0 - it just "guesses" at the correct speed, and moves the axises in sync. It is quite likely to be wrong. On the mendel it probably would try to step Z so fast that it wouldn't work at all.

> Also an "home to max" define would be really
> helpfull. You could then place the z-axis endstop
> to the top, and do something like G92 Z150 G1 Z0
> to set the z zero height in software.

The solution I implemented was different. If X_MAX_PIN is defined, but X_MIN_PIN is not, it will home in the positive direction on that axis. It's still zero though, and G92 doesn't work right in that version so you can't correct it by feeding it "G92 X4.56" or whatever your X bed length is. Like I said, I'm not happy with that implementation.

> We could also simplify the endstop search
> algorithm, to simply move negativ until we hit it,
> and if we're in the endstop move positiv until we
> leave it. This has the advantage you can home
> without problems even if you're deep in the
> endstop. That's quite usefull, so you can set the
> z-endstop way too high an set the z zero height in
> software like above.

The Algo I've implemented is a bit different:

while(not on endstop)
x_step(max_x_speed)
while(on enstop)
x_step_backwards(x_search_speed)
while(not on endstop)
x_step(x_search_speed)

Which does about the same thing in the end, I suppose.

---

--
I'm building it with Baling Wire

VikOlliver Wrote:
-------------------------------------------------------
> I've found that the following produces the correct results
> (based on the old 1.3 firmware):
>
> for (j = 1; j < NUMTEMPS; j++) {
> if (pgm_read_word(&(temptable[0])) > temp)
> {
> // multiply by 4 because internal temp is
> stored as 14.2 fixed point
> temp = pgm_read_word(&(temptable[1])) * 4
> +
>
> (temp -
> pgm_read_word(&(temptable[0]))) * 4
>
> * (pgm_read_word(&(temptable[1])) -
> pgm_read_word(&(temptable[1])))
>
> / (pgm_read_word(&(temptable[0])) -
> pgm_read_word(&(temptable[0])));
> break;
> }
> }
>
> That cost me a thermistor
>
> Vik :v)

This causes my thermistor reading to change from 18.75 to 296.25 at room temperature. What is this, Kelvin?

I am also having trouble with my y axis. When I move my extruder any distance, then try to move y both the y axis and the extruder move. Also other odd behavior from the extruder as described below.

Example:

g1 y60 f3000 -> y axis moves correctly
g1 e100 f1000 -> e axis moves correctly
g1 y50 f3000 -> y and e axes both move
1000 -> (oops, I mistyped) e axis moves
g92 e0 -> everything returns to normal

Also, I think the steps/mm for my extruder needs to be set to .650 (does any one know if this seems right for a Wades' extruder with .4mm nozzle) but when I set it to this I get these warnings.

dda.c: In function ‘dda_create’:
dda.c:176: warning: division by zero
dda.c:222: warning: division by zero

The odd behavior described above also happens but much slower.

Is there any debug code I can enable or something else I can do to help find the problem?

spaztik Wrote:
-------------------------------------------------------
> I am also having trouble with my y axis. When I
> move my extruder any distance, then try to move y
> both the y axis and the extruder move. Also other
> odd behavior from the extruder as described
> below.
>
> Example:
>
> g1 y60 f3000 -> y axis moves correctly
> g1 e100 f1000 -> e axis moves correctly
> g1 y50 f3000 -> y and e axes both move
> 1000 -> (oops, I mistyped) e axis moves
> g92 e0 -> everything returns to normal

sounds like gcmd.seen_E isn't being reset or something, but it's clearly being reset on lines 350 and 364 of gcode_parse.c.. really not sure what's going on there

> Also, I think the steps/mm for my extruder needs
> to be set to .650 (does any one know if this seems
> right for a Wades' extruder with .4mm nozzle)

from what I've read, you will never get nice prints if you really get almost 2mm of filament per step. If you're sure your calculations are correct, you desperately need microstepping. this post concurs with your numbers if you have no microstepping.

> but
> when I set it to this I get these warnings.
>
> dda.c: In function ‘dda_create’:
> dda.c:176: warning: division by zero
> dda.c:222: warning: division by zero

yep, that's because (uint32_t) 0.65 == 0. I think this is why traumflug was pushing for steps per meter instead of per millimeter.

> Is there any debug code I can enable or something
> else I can do to help find the problem?

sure, #define DEBUG in your config, and read the M250+ commands in the bottom of gcode_process.c, also shell scripts in func.sh that go with them.


Sorry I can't be more helpful at the moment, my living situation doesn't support me doing development in any serious capacity

---

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

spaztik Wrote:
-------------------------------------------------------
> VikOlliver Wrote:
> --------------------------------------------------
> -----
> > I've found that the following produces the
> correct results
> > (based on the old 1.3 firmware):
> >
> > for (j = 1; j < NUMTEMPS; j++) {
> > if (pgm_read_word(&(temptable[0])) >
> temp)
> > {
> > // multiply by 4 because internal temp
> is
> > stored as 14.2 fixed point
> > temp = pgm_read_word(&(temptable[1])) *
> 4
> > +
> >
>
> > (temp -
> > pgm_read_word(&(temptable[0]))) * 4
> >
>
> > * (pgm_read_word(&(temptable[1]))
> -
> > pgm_read_word(&(temptable[1])))
> >
>
> > / (pgm_read_word(&(temptable[0]))
> -
> > pgm_read_word(&(temptable[0])));
> > break;
> > }
> > }
> >
> > That cost me a thermistor
> >
> > Vik :v)
>
> This causes my thermistor reading to change from
> 18.75 to 296.25 at room temperature. What is this,
> Kelvin?
>
> I am also having trouble with my y axis. When I
> move my extruder any distance, then try to move y
> both the y axis and the extruder move. Also other
> odd behavior from the extruder as described
> below.
>
> Example:
>
> g1 y60 f3000 -> y axis moves correctly
> g1 e100 f1000 -> e axis moves correctly
> g1 y50 f3000 -> y and e axes both move
> 1000 -> (oops, I mistyped) e axis moves
> g92 e0 -> everything returns to normal
>
> Also, I think the steps/mm for my extruder needs
> to be set to .650 (does any one know if this seems
> right for a Wades' extruder with .4mm nozzle) but
> when I set it to this I get these warnings.

This doesn't look correct at all. i'm not home right now to look at my config but how did you get .65?
this is How many steps to move 1mm of filament. I have a wades with a easy driver at 1/8th stepping. when i get home tonight I'll post my settings. they are working somewhat for me.

>
> dda.c: In function ‘dda_create’:
> dda.c:176: warning: division by zero
> dda.c:222: warning: division by zero
>
> The odd behavior described above also happens but
> much slower.
>
> Is there any debug code I can enable or something
> else I can do to help find the problem?

Found a typo in x_min. patch attached

Well done. I'd just "fixed" my new X min limit switch and was about to run into that one!

Vik :v)

HOME_TO_MIN is done in a lot of GCODE generators by G1 X-9999 Y-9999 Z-9999 and then resetting to 0,0,0 so I think we need to keep this ability.

Vik :v)

Triffid_Hunter Wrote:
-------------------------------------------------------
> sounds like gcmd.seen_E isn't being reset or
> something, but it's clearly being reset on lines
> 350 and 364 of gcode_parse.c.. really not sure
> what's going on there

Is there anything I can do to see what is going on here? I am thinking of putting sersendf lines immediately before or after the lines you listed above to prove those lines are being executed but I am not sure how useful that will be.

> from what I've read, you will never get nice
> prints if you really get almost 2mm of filament
> per step. If you're sure your calculations are
> correct, you desperately need microstepping.

Well when you put it that way it becomes very clear there is a problem here. I am not at all certain about the .650 number. I got it by using the spreadsheet at the bottom of the Wade's Extruder page on the ReprapWiki. I will need to look closer at this tonight. The more I think of it though, I figure I should have more steps/mm than a pinch wheel extruder because Wades extruder is gear reduced.

Architect, please do post your setting for steps/mm and your extruder orifice diameter if you don't mind. This will be a good starting point and or comparison.

> yep, that's because (uint32_t) 0.65 == 0. I think
> this is why traumflug was pushing for steps per
> meter instead of per millimeter.

Steps/mm must be greater than one, got it. I can always use the extrusion multiplier in repsnapper, as mentioned in the comments of the blog post Triffid linked to earlier, if necessary. I really hope I have this value wrong because I am not sure I have powerful enough motors to use microstepping on my extruder.

> sure, #define DEBUG in your config, and read the
> M250+ commands in the bottom of gcode_process.c,
> also shell scripts in func.sh that go with them.

No can do, I am using the 168 chip. I was hoping you could point me at a few lines of debug code I could remove the "ifdef debug" from. If I comment out some of my pin definitions (ie. z axis, heater, etc) will that cause less code to compile and maybe free up enough memory to enable debug on the rest?

> Sorry I can't be more helpful at the moment, my
> living situation doesn't support me doing
> development in any serious capacity

I don't think I am alone in saying your "not in any serious capacity" development is extremely helpful, and quite frankly awesome. Keep up the great work... or not, really just do whatever you feel like. Thanks for your feed back, and thanks again for this great firmware.

Finally, I was only half joking when I asked if my thermistor reading 296 was in the Kelvin scale. I have isolated this issue to the commit Vik submitted related to thermistor look up table. Can anyone else confirm or deny this? Vik do you have any thoughts on what might be happening here?

spaztik Wrote:
-------------------------------------------------------
> Triffid_Hunter Wrote:
> --------------------------------------------------
> -----
> > sure, #define DEBUG in your config, and read
> the
> > M250+ commands in the bottom of
> gcode_process.c,
> > also shell scripts in func.sh that go with
> them.
>
> No can do, I am using the 168 chip. I was hoping
> you could point me at a few lines of debug code I
> could remove the "ifdef debug" from. If I comment
> out some of my pin definitions (ie. z axis,
> heater, etc) will that cause less code to compile
> and maybe free up enough memory to enable debug on
> the rest?

I also am confined to a 168 chip. I've got some bigger ones sitting around (2 644p's, 3 of the larger pin-compatible ones (328?)) but I've never managed to get any of them to work. Probably something about getting fuses set correctly.

Anyway, what I did was removed PID. I #defined BANG_BANG, and used an #ifdef in temp.c to replace the whole file with a temp_tick() command that basically just compares the temps and turns the heater on and off. This probably isn't ideal in your situation, but would at least make a fine temporary measure for you to debug axis movement before turning PID back on.

It left plenty of space for #define DEBUG and all sorts of other stuff too. I'd like to do something more sophisticated, but haven't yet. Made my heater block the other day though, so maybe soon.

---

--
I'm building it with Baling Wire

Well, if it was me I'd have a look in temp.c, put in a sersend to output the analogue value of the thermistor pin (or maybe use existing debug). Look it up manually in temp.c in the thermistor's temptable and see if it looks to be in the right ballpark.

I'd also check to make sure the resistance does not change when you wriggle the wires. Had that happen to me before more than once

Vik :v)

hi all, for those of you who have become relatively familiar with this firmware, please check out the input-float branch. I have posted a total rewrite of gcode_parse which is both significantly simpler than the old one and probably less buggy. This update buffers a whole line before processing it, and uses floats to receive numerical data. Please test and comment here. I intend to update gcode_process and dda_create to use some floating point, but all calculations beyond dda_create will remain as pure integers.

---

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

VikOlliver Wrote:
-------------------------------------------------------
> Well, if it was me I'd have a look in temp.c, put
> in a sersend to output the analogue value of the
> thermistor pin (or maybe use existing debug).

for those of you who have linux boxen, room for DEBUG and have worked out how to use func.sh,

mendel_readsym adc_result

will spit out the whole buffer in hex

---

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

I got the axes to obey the X_MIN_PIN by changing the dda_step() function in dda.c:375 to read:

if ((current_position.X != dda->endpoint.X) &&
//(x_max() != dda->x_direction) &&
((x_min() == 0 ) || (dda->x_direction != 0))) {

for all 3 axes.

I dunno what x_max() should do because I've never used it

I'm not using temporal acceleration, BTW.

Vik :v)

OK, my first interesting problem.

I enter "G1 X10 F300" and it goes chug, chug to X=10. Yippeee!

I enter "G1 X0" and it chugs back. Good so far. The min endstop works even, which is good too.

I enter "G1 X10 F5000" and - it goes chug, chug to X=10 AT THE SAME SPEED. Suxors

Now, I was expecting it to move a bit faster with F5000. Any ideas wassup? Probably something I missed in the config no doubt.

Vik :v)

firmware definitely obeyed F-words last time I checked, would appreciate others testing this as I can't at the moment!

a git bisect would be great, I think e44954b should be a good place to start but check it first

---

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

I'm not very good with git, I'm afraid. What would I have to type?

Vik :v)

Ah, silly me! The default maximum speeds in the config.h are very, very low. Upped the X maximum rate to 4000mm/min and we're off.

Vik :v)

first you must understand what a git bisect is.. given a known good and a known bad commit, it helps you track down the commit which created an issue by binary search.

basically, it picks a commit about halfway between bad and good, checks it out then tells you to test if the bug is present. if yes, it marks that as bad and repeats, if no it marks it as good and repeats until you have narrowed it down to one commit, or a small sequence which you can't test for some reason.

google knows of some much better guides than I can type into the forum here

fyi; it supports automatic checking, but that won't be much use to you in this situation

---

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

ah heh I forgot about those, yes ALL the defaults are really really slow, for maximum possibility of "ahahaha it lives IT LIVES" + mad cackling out of the box

---

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

Quote

Upped the X maximum rate to 4000mm/min and we're off.

Yes, unlike "official" FiveD, these values are correctly respected ;-) They're so low to be safe for even the slowest machines (think of M6 threaded rods).

Regarding bisecting, this can be done manually as well. If the last known good version is 20 commits back and you're on the master branch, start with

git checkout master~20
make program

Then test for the bug. If the bug isn't there yet, try master~10, then master~5, etc. Each time you experience the bug, go back half the way to the last known good version. You get the idea. Eventually you're down to the single commit introducing the bug, and that's a big help in finding the issue, of course.

If a specific version doesn't work at all, or doesn't even compile, reduce by one. "git bisect" is designed to do that number calculations for you, but learning the required commands is probably more work than just doing the calculations on a sheet of paper.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sorry it took so long to get back to you, my "follow this thread and email" doesn't seem to work and I got my replacement parts in for my heater controller (which I fried in a truly dramatical fashion) so I've spent the last 24 hrs rebuilding a new nozzle/barrel unit (pict attached).
I have a couple of my notes attached here too.

spaztik Wrote:
-------------------------------------------------------
> Triffid_Hunter Wrote:
> --------------------------------------------------
> -----
> > sounds like gcmd.seen_E isn't being reset or
> > something, but it's clearly being reset on
> lines
> > 350 and 364 of gcode_parse.c.. really not sure
> > what's going on there
>
I found an issue where any code with a decimal place > 1 goes haywire after 1600 lines of code. it acts as if the values are not being reset and my axis are thrown way off. I still haven't got around to look at this yet but I just round my gcode to a tenth and don't have the issue anymore. it kinda sounds like what you described.

> Architect, please do post your setting for
> steps/mm and your extruder orifice diameter if you
> don't mind. This will be a good starting point and
> or comparison.
>
extruder val:
#define STEPS_PER_MM_E 36.0
#define MAXIMUM_FEEDRATE_E 2000
#define SEARCH_FEEDRATE_E 1000
#define E_STARTSTOP_STEPS 10
and
#define ACCELERATION_RAMPING

I'm using a stock Wades extruder. my Orifice (::giggle: is .4mm for the new one which I have not finished running test on as I am currently working out the PID tuning on it.
which seqway's into...


> Finally, I was only half joking when I asked if my
> thermistor reading 296 was in the Kelvin scale. I
> have isolated this issue to the commit Vik
> submitted related to thermistor look up table. Can
> anyone else confirm or deny this? Vik do you have
> any thoughts on what might be happening here?

Unfortunately I think I am using a completely different set up then the stock systems. my Thermistor is a 100k with a 4.7k divider Resistor but it is set on the VDD side instead of the 0V so my values rise instead of fall. Nophead's notes on this are very useful. his blog entry is here

onto the homing issue...

VikOliver wrote:
I got the axes to obey the X_MIN_PIN by changing the dda_step() function in dda.c:375 to read:

if ((current_position.X != dda->endpoint.X) &&
//(x_max() != dda->x_direction) &&
((x_min() == 0 ) || (dda->x_direction != 0))) {

for all 3 axes.

I do something similar for all axis but only for MIN as thats is all I have:
if (x_min() != dda->x_direction)
//not at the endstop. if there is a fails signal it should only skip one step. TODO: ?MAX Stop?
x_step();

I think I would put some checking in hear to see if its really at the endstop by saving the last x_min value and checking if its the same therefore I can weed out noise.

The problem with my implementation so far is if you are vary close to the endstop say 1mm and issues a -100 mm command it goes through 99 steps before it completes even though it does not actually step. this only bugs me on the z axis as each step is so much slower.

The nice thing about this is that So far, no matter what happens it stops at the min endstops regardless of what the code says so crazy errors which I have a lot of sometimes doesn't slam my axis.

Ok back to PID tuning.

Edited 1 time(s). Last edit at 02/06/2011 10:36AM by Architect.

trying to follow topic again...

well, Learned alot about PID today. still have a lot to learn.
I found a bug in my version of the Heater.c file
was :
int32_t pid_output_intermed = (
(
(((int32_t) heater_p) * p_factor) +
(((int32_t) heater_i) * i_factor) +
(((int32_t) heater_d) * d_factor)
) / PID_SCALE
Now:
int32_t pid_output_intermed = (
(
(((int32_t) heater_p) * p_factor) +
(((int32_t) heater_i) * i_factor) -
(((int32_t) heater_d) * d_factor)
) / PID_SCALE

gives me +- .25 C

> ((x_min() == 0 ) || (dda->x_direction != 0))) {
> for all 3 axes.
>
> I do something similar for all axis but only for MIN as thats is all I have:
> if (x_min() != dda->x_direction)

These are not equivalent - for me at least.

Vik :v)

VikOlliver Wrote:
-------------------------------------------------------
> I've been building release-candidate, and the
> thermistor table lookup code is way out of kilter
> (unless I've hugely misunderstood it). I've found
> that the following produces the correct results
> (based on the old 1.3 firmware):
>
> for (j = 1; j < NUMTEMPS; j++) {
> if (pgm_read_word(&(temptable[0])) > temp)
> {
> // multiply by 4 because internal temp is
> stored as 14.2 fixed point
> temp = pgm_read_word(&(temptable[1])) * 4
> +
>
> (temp -
> pgm_read_word(&(temptable[0]))) * 4
>
> * (pgm_read_word(&(temptable[1])) -
> pgm_read_word(&(temptable[1])))
>
> / (pgm_read_word(&(temptable[0])) -
> pgm_read_word(&(temptable[0])));
> break;
> }
> }
>
> That cost me a thermistor
>
> Vik :v)


I think I can confirm this change as well. I did the math and then updated my code and it works out well.
I previously had this commented out/ replaced with a kludge to get raw temps from the look up table. I put this in after some calculations and it works well.
Thanks Vic, I didn't want to use the code I had in place.
off to the beer heaven and that dumb game the call FootBall over here on this side of the pond. its really about the commercials really...