Teacup Firmware replicatorG & Skeinforge

I've decided its time to graduate to a more complicated software package for my setup. I have been somewhat successful using 5D for Arduino and repsnapper. I was able to get everything I needed to work working. now its time for tweaking the gcode output. It seems to me that ReplicatorG has already many of the features i need so i am going to start tailoring my firmware hacks to its requirements. the first road block i have come to is the newly implemented checksum. I have checksum working quite well with the repsnapper code and it defiantly catches the few bad lines sent and requests the resend properly and the DDA waits for the correct line to come. I am wondering if Anyone out there is working with this exact setup and what other changes I need to be aware of . I also decided on downgrading to Skeinforge 31 as 35 and 39 both add a great deal of extras that 5D is not capable of handling. I hope to move up to those after I get 31 dialed in.

So, any suggestions, tips and gotchas to look out for would be helpful.

my current bug is that after about 1600 or so lines my machine goes haywire and does all kinds of bad things. my feeling is it received a noisy command and given no checksum the firmware just tried to process the command. hence the reason I want checksum back in there to handle this things as well as tell me when they happen.

-regards and thanks
trout

[Edit: Changed name to "Teacup Firmware" for the purposes of not confusing folk, after irc discussion. --Sebastien]

Edited 1 time(s). Last edit at 02/22/2011 02:11AM by SebastienBailard.

hey it's great to hear that the checksum/resend stuff is working, I've never really tested that bit

regarding these extras in skeinforge 39, can you describe some of them, and what firmware is supposed to do with them?

---

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

Back to coding as I fried my heater circuits and need to wait for replacement parts from digi-key.
I'm working on the checksum between replicatorG and FiveD as well as i found bug somewhere in the Gcode_parse
Which has to do with comands with over 2 decimal places. I'm not sure anymore which branch I am working off of so I hope I'm not duplicating any effort. This seems to be what was causing my axis to go haywire after 1600 lines or so.
I'm not much of a blogger so I figure I'll just post my findings and thoughts here.
After editing my Gcode to only have commands with one number after the decimal the firm ware will complete the print.
This leads me to believe a value is not being zero'd out at the end of processing a line.
Also on the checksum issue the java code using the exact same formula and the exact same line as the firmware returns different values.
I hope to have both these issues worked out tonight. I'm Outta beer so I might just be productive.

'git status' will tell you which branch you're on. development is on master branch now, the regime we were using before was too messy and confusing

---

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

thanks Triffid,
found that the checksum_calculated value in the struct computes correctly with the (a^b) if it is first initialized to 0
working on that now.

well, Learned alot about PID today. still have a lot to learn. as well as alot to learn about git it seems.
git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: heater.c
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
#
... all the files listed bellow

So I'm not sure what that means but git diff heater.c doesn't do anything for me
and I found a bug in 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

yea. gonna post this in the main thread as well, sorry for the double post but in case no one whats to read my ramblings here, I think this is important enough to put it there

Edited 1 time(s). Last edit at 02/06/2011 06:51PM by Architect.

The values are signed, I was just putting in negative D values

This works too, and is probably closer to the standard PID


Looks like you're running git in an uninitialized or new repository, works better when you git clone to create the folder rather than download and unpack. On github, hit fork and follow the instructions

---

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

Hehehehe, yeah i think i downloded from git and unpacked it. I manage our team foundations repository at work and am always dealing with contentions
I didnt want to make any of those here with everyones work. cool and thanks again. So I'm hoping the home life settles down for ya and you can get back to printing.
If you need anything to get ya back working let me know maybe I can help.

Git is king at managing "contention", don't worry about it. That all gets sorted out when I merge any pull requests you make, and since git is designed from the ground up to be non-linear (just look at the graphs in qgit4 or equiv!) it's easy to manage

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> The values are signed, I was just putting in
> negative D values
I was just thinking this is probably do to the fact that my temp values rise instead of fall in my look up table.
If that's true then it's not a bug persay.
I'm in the middle of designing a modular heater circuit much like the polulo stepper driver
And have it wired that way...
Ramble ramble, Ramble...

> This works too, and is probably closer to the
> standard PID
>
>
> Looks like you're running git in an uninitialized
> or new repository, works better when you git clone
> to create the folder rather than download and
> unpack. On github, hit fork and follow the
> instructions

working on Command Value Resolution tonight.
problem: gcode with command values with more then one decimal place crash the firmware after ~1600 lines of code. why?

an excellent question to which I have no answer. While we track it down, try the input-float branch if your chip has enough space

---

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

If you want others to look into this issue, it's probably a good idea to upload such a crashing G-Code file.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Triffid - was going to play with that soon. just want to get this version a bit more stabilized.
Traumflug, Sorry about the open question like that, not good for a forum post. It happens with every gCode produced from Skienforge or having values with a persision on more then 1 decimal place. here is my findings.
I feel asleep on my computer last night and will test this fix out tonight.

Issue:
after ~1600 gcode commands machine goes haywire for any gCode with precision values greater then 1 decimal place.

Suspicion:
one of the variables is going beyond the int capacity.
question: which variable and why.

findings:
around line 1600 in any given gcode with values at a precision of .001 mm the machine fails.
Logs:
produced at that time.

[java] INFO: Sending: N1560 G1 F1714.98 *112
[java] INFO: received: pos: -1072,-1140,21407,1,1980
[java] INFO: received: dst: -1082,-1150,21592,2,1956
[java] INFO: received: n1560g1f1714*112
[java] INFO: received: ok
...
[java] INFO: Sending: N1561 G1 X-5.38 Y-14.78 Z7.38 E2.43 F1980.0 *64
[java] INFO: received: n1561g1x-430y-1182z-20817e87f1980*64
[java] INFO: received: ok
[java] INFO: Sending: N1562 G1 X-5.23 Y-14.62 E0.07 F1714.98 *26
[java] INFO: received: n1562g1x-418y-1169e2f1714*26
[java] INFO: received: ok
[java] INFO: Sending: N1563 G1 X-5.23 Y-5.38 E2.79 F1980.0 *29
[java] INFO: received: n1563g1x-418y-430e100f1980*29
[java] INFO: received: ok
[java] INFO: Sending: N1564 G1 X-5.38 Y-5.23 E0.06 *72
[java] INFO: received: pos: -1082,-1151,21074,-2,1956
[java] INFO: received: dst: -1082,-1171,-20996,-72,1446
[java] INFO: received: pos: -1082,-1154,14614,-13,1956
[java] INFO: received: dst: -1082,-1171,-20996,-72,1446

Observations:
typical Z calculations seem to be pos: 21407 dst: 21592. This seems a reasonable increase in height on the Z axis as per the log messages and is consistent from the beginning of the print.
The last Z command sent was 7.38. From there the logs read pos: 21074 dst: -20996. I believe this was the issue, shortly after the machine became nonfictional.

Tracing the numbers:

Config settings:
STEPS_PER_MM_Z 2999

Calculation for this number:
Gears: 8T, 29T
Motor: 200 steps/revolution
Drive 1/8 step resolution default driver setting for easy Stepper.
Thread count: 24t per 25.4mm

Gear ratio 29/8 = 3.625
Steps/revolution @ 1/8 stepping: 800
Steps per revolution of z-Axis threaded rod: 2900
Steps per mm = gear ratio * steps/rev. * thread count
Steps per mm = 3.65 * 800 *(24/25.4)
Steps per mm = 2740;

Note: After tuning I set mine to 2999, need to go back and verify that the Z axis is truely accurate to 1/10th of a mm.

Following the numbers:

Gcode: G1 Z7.3
7.3 assigns Z->mantissa = 73 and z->exponent = 1
For the decfloat_to_int function we pass
STEPS_PER_M_Z, 1000
STEPS_PER_M_Z = 2999*1000 (is this for printing meter long jobs??)

Thus the math in my version is
2999*1000*73 / 1000 (again why pass STEPS_PER_M when it is just calculated out?)
= 218,927,000 /1000 / 10
= 21892

That’s fair for decimal to .1

Next G1 Z7.38

7.38 assigns Z->mantissa = 738 and z->exponent = 2
For the decfloat_to_int function we pass
STEPS_PER_M_Z, 1000
STEPS_PER_M_Z = 2999*1000

Thus the math in my version is
2999*1000*738 / 1000
= 2,213,262,000 /1000 / 100 (*think this is a problem)
= 22132 as the dst position.
This seems fine except for this small issue:
the math done in the floatToInt method is assigned to
int32_t r = df->mantissa;
thus, 2.213.262.000 overflows the int32_t value r max of 2,147,483,647 I believe.
Going to test this out by changing the int32_t to uint32_t
but then again, thats going to mess up any negative values coming in.
hmmm, I could reduce the stepper driver to 1/4 steps Don't need 1/8th on the Z axis. but this does not fix the problem just masks it.
ok, after reading this I think I will create a new unsigned int to do all the math then at the end return a signed value based on the incoming signed bit. that will work and I think every thing will be happy.

Any suggestions My brain if fried due to Oracle Application Framework training/ hacking for the last 16 hrs.

Architect; I have pushed a patch which I hope will make E behave. Basically, next_target.target.E was only being reset when G91 (relative) was enabled, but E is always relative, and seen_E was being ignored so after sending a non-zero E word, every subsequent command with no E word would cause E movement. Please test and let us know if that does the trick

---

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

Triffid, haven't got to the point of output through my new hotend, haven't wanted to waste plastic while I have a list of corrections to get through.
I've been following that discussion. For now I have only been running the extruder stepper with no filament.
I have been under the assumption that as the bot travels on the X and Y axis that the extruder pushes filament at a constant rate. Maybe that's wrong so by this patch it is only suppose to put more into the heater when told to? Not consistently as the machine moves. I need to diff my code aginst the current dev release. But as I have a few odd hardware setups I don't think I can merge them.
Enjoy the day,
Trout

Architect Wrote:
-------------------------------------------------------
> I have been under the assumption that as the bot
> travels on the X and Y axis that the extruder
> pushes filament at a constant rate.

No, at the same rate as X/Y movement, so also subject to acceleration, and +/- a bit of speed depending on whether slicer wants to stretch or blob the extrudate

> Maybe that's
> wrong so by this patch it is only suppose to put
> more into the heater when told to?

Exactly - if we're not asked to extrude, we're moving between areas or cooling or something

---

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

Ok so that was the bug causing my machine to die at ~1600 with persission of 1/100 yea! Fixed. next on the list of fixes will be why the lsat command is not completing. I'm too fried tonight to do the investigation but that should be it to beable to complete a print using the thread titled set up.

I'm fried so now onward to get my branched version of the software in line with the Master. time to learn a bit more about git. Joy.
-karl

you're probably looking for git rebase, but be aware that it technically loses history. Basically, git rebase re-applies your branch patches from head of upstream master, or any other branch you specify. If any patches/commits are in both, they're removed from your local branch so it's a good way to cull stuff that's been accepted upstream

---

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

i was just going through the master branch change log. Man you've been busy!
is ther a Diff before doing a rebase? i think my current branch is way off the curent master and it seems so close to being stable i'd rather not disturb it.
I'm reading up on the docs now...

heh if you're way behind master, it may be quicker and easier to start a new branch- who knows how many of your patches have found their way into master via a totally different route? Maybe some changes are redundant, or maybe they're still pertinent but need to be done a different way?

On an unrelated note, if your patches could be useful to others, please post them somewhere- pull request via github is nice

---

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

definatly will do, only real reason i haven't so far is that my electronics are all "Hand Made" so to say, and as such maybe unique from the rest of the users so i didnt want to muddy the waters.
plus, doing code management for work means that my own projects are woefully undermanaged... kida like a machanic and his beat-up geloopy of a car that never runs right. :-)

heh my electronics are hand-made too, seen my blog?

I think that's one of the reasons that this firmware is so easy to adapt to different electronics, it's been created from the ground up to not have too much stuff hard-coded in.

Not sure about whole projects, but good repository management takes some time and effort to become habitual, then pays off for the rest of your life. A hint from one who's tried all sorts of ways

---

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

New Issue.

issue: Pint Job does not complete last position line.

gCode:
...
G90 (absolute positioning - end of end.gcode)
G92 X0 Y0 Z0 (set current as home position)
G92 E0 (reset extrusion position)
G1 X-20.0 Y-13.67 Z9.88 F1589.48
G1 X-20.0 Y-13.67 Z10.0 F600.0
G90 (absolute positioning - end of end.gcode)
M113 S0.0
(EOF)

Logs:
INFO: Sending: N2520 G1 X-20.0 Y-13.67 Z10.0 F600.0 *38
[java] INFO: received: n2520g1x-1600y-1093z29990f600*38
[java] INFO: received: ok
[java] INFO: Sending: N2521 G90 *4
[java] INFO: received: pos: 6,-13,0,1,100
[java] INFO: received: dst: -1086,-1077,29630,2,1800


Observation:
pos vs dst values are the culprit. pos changes in value through the rest of the log but at such a slow pace it is almost unnoticeable.

theory:
the G90 code is affecting the values for the gCode still in the dda Queue (line N2520) before it is actually printed.

will work off this theory tonight. any other suggested ideas are always quite welcome.

Triffid,
Skienforge is producing code as such;
G1 X-13.93 Y-6.51 E0.21
G1 X-14.04 Y-6.46 E0.04
G1 X-14.04 Y-6.15 E0.10
G1 X-14.0 Y-6.05 E0.03
G1 X-13.91 Y-5.96 E0.04

thus every print line lays down an instruction for the extruder. is this what you were expecting to deal with with the new patch for the extruder code?

thats why I figured my machine was behaving correctly.
I haven't applied that patch yet but will as soon as I get this current issue fixed.

Nothing is extruded when changing layer, cooling or moving to another area... Somehow we missed it extruding during these moves until you brought it up

---

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

SO I feel dumb....

I figured that by making the r value an unsigned int, It would have plenty of space to handle any Z axis number put in it. I was wrong.

[java] INFO: received: ok
[java] INFO: Sending: N30637 G1 X61.45 Y43.0 Z14.38 F403.247 *45
[java] INFO: received: n30637g1x4916y3440z175f403*45
[java] INFO: received: ok
[java] INFO: Sending: N30638 G1 X52.39 Y36.41 F3000.0 *113
[java] INFO: received: n30638g1x4191y2912f3000*113
[java] INFO: received: ok
[java] INFO: Sending: N30639 G1 X52.1 Y36.32 F1652.824 *66
[java] INFO: received: n30639g1x4168y2905f1652*66
[java] INFO: received: ok
[java] INFO: Sending: N30640 G1 X47.9 Y36.32 F3000.0 *77
[java] INFO: received: n30640g1x3832y2905f3000*77
[java] INFO: received: ok
[java] INFO: Sending: N30641 G1 X47.61 Y36.41 *13
[java] INFO: received: n30641g1x3808y2912*13
[java] INFO: received: ok
[java] INFO: Sending: N30642 G1 X37.82 Y43.53 *5
[java] INFO: received: pos: 4925,3397,42375,0,3000
[java] INFO: received: dst: 4934,3407,42375,0,3000
[java] INFO: received: q1/0f
[java] INFO: received: n30642g1x3025y3482*5
[java] INFO: received: ok
[java] INFO: Sending: N30643 G1 X37.64 Y43.78 *5
[java] INFO: received: n30643g1x3011y3502*5
[java] INFO: received: ok
[java] INFO: Sending: N30644 G1 X36.34 Y47.77 *13
[java] INFO: received: n30644g1x2907y3821*13
[java] INFO: received: ok
[java] INFO: Sending: N30645 G1 X36.34 Y48.07 *4
[java] INFO: received: pos: 4926,3439,42755,0,305
[java] INFO: received: dst: 4916,3440,175,0,403
[java] INFO: received: q4/3f
[java] INFO: received: pos: 4925,3439,37344,0,305
[java] INFO: received: dst: 4916,3440,175,0,403

at 14.38mm hight the math calculated using the aforementioned processing to a number of 4312562000. which doesn't fit into 4,294,967,295 when it rolls over it become 175...
so once again with a more complex print job the machine goes Haywire.
I have 3 options here then.
1. lower my z axis stepper driver to 1/4 steps.
pros: I don't need 1/8 stepping on the z axis, easy to do.
cons: limiting the hardware when it can be fixed in the software
2. get rid of the Steps_per_m scale value...
pros; I see no need for this whatsoever
cons: as I see no need whatsoever for this then I am missing something and there is a reason it is there. should not mess with what works elsewhere.
3. Get my source code up to date with the current release. After checking, my code differs vastly with the current master.
pros: might fox the problem and I might be able to contribute to the majority.
cons: might not fix the problem and I might contribute to the majority...

I like 3.
forgive me... :-)

[::Architect::]
"yeah, I built that... so what"

we went to steps_per_m because we were seeing huge precision loss in machines with steps_per_mm less than 10 or so. Since you're microstepping on a threaded rod, you should be able to bump Z back to steps_per_mm, just adjust appropriately in gcode_parse where it does the scaling or even punch in your own scaling factors

---

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

hey all, wondering if the inter-step timing stuff is ok, can someone tell me whether lots of small moves sound different to an equivalent longer move?

---

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

I've decided to take on the challenge of merging the latest branch (or what parts I want ) into my branch.

you took care or the z axis stuff for me by doing the math differently. Unfortunately the new TEMP code is a major overhaul for me but I like the idea of multiple heater/therms for when I start working on a heater bed. needless to say I'm gonna be "configuring" this for the next few days.

-I'll Let you know