Project: Teacup Firmware

An updated intercom protocol is probably long overdue, even jakepoz said it was too simple, but got us off the ground in terms of gen 3 support.

A couple of suggestions:
the extruder really is a slave controller and can be treated as such, ie only speaks when spoken to.this solves collission issues.

A start byte will make synchronization significantly easier, and won't overload the serial link, I suggest 0x55 (U iirc) for its lovely 1010101010 look (incl. start and stop bytes) this in combination with the checksum will make packet detection trivial.

With 11 bytes per packet and 2 packets per 10ms, we need (2 * 11 * 10 baud/packet * 100 per second) = 22kbaud minimum, so 38400 should do the job with some breathing room

Any preference for byte order on the wire?

Ps; temps are 14.2 fixed point everywhere else, basically a standard 16 bit word with 0.25 degree units.no need to doctor them any further.

---

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

Hello,
I am trying to compile the firmware like written in the README file but there seems to be a problem with the make file. When running make I get this error:

$ make
make: *** Keine Regel vorhanden, um das Target »config.h.dist«, 
  benötigt von »config.h«, zu erstellen.  Schluss.

In English: No roule found to create the target "config.h.dist" which is needed by "config.h".

Any idea what this mean?
I am compiling on a 64Bit Ubuntu 10.04 host.

Edited 1 time(s). Last edit at 02/12/2011 08:08AM by Jacky2k.

Markus, I've created a new branch, intercom-protocol containing my preliminary implementation of your idea. Please have a play and tell me 1) if that's close to what you were thinking and 2) how many changes to make it work.

I haven't changed the surrounding code more than necessary so not much of it gets used, but it's a start.

Lots of the changes in extruder/ are actually because the files are supposed to be hardlinked, but somehow became unlinked. Same updates need to happen to master at some point, but I'm not wrangling it tonight.

---

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

Jacky2k Wrote:
-------------------------------------------------------
> Hello,
> When running make I get this error:
> $ make
> In English: No rule found to create the target
> "config.h.dist" which is needed by "config.h".
>
> Any idea what this mean?

did you move/rename config.h.dist to config.h instead of copying? The makefile checks the dates of both, and complains if config.h.dist is newer. A side effect is that if config.h.dist is missing, it can't do the check and throws the error you're seeing.

You could always remove the rule from the Makefile, but then you're always fighting upstream to keep your Makefile the way you like it. Easier to checkout config.h.dist again.

---

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

OK I got a fresh version, copied the config and it worked. No idea what the problem was.
Now I have a new problem: I am not able to program the firmware to the target, that might be a problem with my bootloader because I was not able to program it with the adruino IDE I did it manually, maybe I did something wrong.
As far as I unserstand I can use "make program-fueses" to set the correct fuses. But the make file does this by using the adruino boot loader, thats an vicious circle
And where can I get a current version of the bootloaders hex file for atmega644 (NOT the P version!). The only one I have is from adruino version 0017.

Edit: Also intresting. In the make file are 3 commands to calculate the fuses:

	avr-objdump -s -j .fuse mendel.o | perl -ne '/\s0000\s([0-9a-f]{2})/ && print "$$1\n"' > lfuse
	avr-objdump -s -j .fuse mendel.o | perl -ne '/\s0000\s..([0-9a-f]{2})/ && print "$$1\n"' > hfuse
	avr-objdump -s -j .fuse mendel.o | perl -ne '/\s0000\s....([0-9a-f]{2})/ && print "$$1\n"' > efuse

All these 3 files are EMPTY after running this commands! I don't think this wanted.

Edited 2 time(s). Last edit at 02/12/2011 08:52AM by Jacky2k.

Triffid_Hunter Wrote:
-------------------------------------------------------
> Markus, I've created a new branch,
> intercom-protocol containing my preliminary
> implementation of your idea. Please have a play
> and tell me 1) if that's close to what you were
> thinking and 2) how many changes to make it work.

Many thanks, I'll play with it this weekend.
After a first look the implementaion looks great. I would've changed something anyway if I had implemented it (e.g asynchron was a bad idea, after learning RS485 is half duplex)

I can tell you more after I've made it work

Quote

In English: No roule found to create the target "config.h.dist" which is needed by "config.h".

Any idea what this mean?

The idea is to require config.h to be younger than config.h.dist. As soon as config.h.dist gets an update via git, you're noticed to review your config.h.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Avrdude will talk to an external programmer just as happily as a bootloader.

Yes, the fuses thing is currently broken because the arduino ide includes them then chokes at programming time, simply edit fuses.h or define the appropriate variable to enable

---

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

The bootloader, even if loaded and running, will refuse to program the fuses. If you look in the code for the bootloader it's explicitly ignored. Makes sense, too, as if the bootloader is running you don't need to set the fuses, and setting the fuses may (probably would) make the bootloader no longer run.

What really kinda peeved me is that the "programmer" sketch for the arduino ALSO has the fuse setting capabilities missing (Wasn't the point of the thing to load a blank arduino chip?)

The only thing I found that was, in theory, able to set fuses was the serial programer right off a serial or parallel port, or usb/ttl cable with enough pins to do the programming. I say in theory because I was never able to get it to work.

---

--
I'm building it with Baling Wire

I have a usb programmer from pololu, works fine for setting fuses - had to sort that out when I got my '328s. Fried my 168 accidentally with a hairline trace between 12v and 5vsb :/

---

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

I think the bootloader is not able to set any fuse! It is a normal program running on the controller. Setting the fuses is only possible over ISP/JTAG.
So is there any good guide to get the bootloader on a atmega644 and setting the fuses? I am still not able to program the atmega with the adruino bootloader.

I think I found a solution for my problem. I downloaded a newer version of the bootloader from here: [code.google.com]
Installed it and the bootloader respons on "make program" but I get this error:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

make: *** [program] Fehler 1

When I use the -F option everything works fine and the firmware is running!
Any idea why avrdude gets the wrong device signature?

I have an other problem:

Quote

* If your heater isn't on a PWM-able pin, set heater_pwm to zero and we'll *
* use bang-bang output. Note that PID will still be used *

So I used:

DEFINE_HEATER(extruder,	PORTA, PINA0, 0)

And get this compiler error:

config.h:291: Fehler: Als Operand für unäres »&« wird L-Wert erfordert

Sorry but I have no idea what this means, the word-by-word translation is:
Error: As operand for unary »&« a L-Value is required.

Any ideas?

Jacky2k Wrote:
-------------------------------------------------------

> avrdude: Device signature = 0x000000
> avrdude: Yikes! Invalid device signature.
> Double check connections and try again,
> or use -F to override
> this check.
>
>
> avrdude done. Thank you.
>
> make: *** Fehler 1
>
> When I use the -F option everything works fine and
> the firmware is running!
> Any idea why avrdude gets the wrong device
> signature?

I had the same trouble. The solution is at the end of this post.

spaztik Wrote:
-------------------------------------------------------
> I still can't get m105 to report a sane temp
> reading. The ADC readings seem correct, 18.75 is
> what m105 used to report at room temp.

> > 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.

I'm not sure what fixed the extruder but I loaded the most recent commit and everything seems to work fine now. Yay With any luck I'll be printing soon.

Edit: Upon closer examination, I guess the commit with the comment "try to make E behave" probably fixed the extruder. Duh.

Edited 1 time(s). Last edit at 02/13/2011 03:17PM by spaztik.

spaztik Wrote:
-------------------------------------------------------
> I had the same trouble. The solution is at the end
> of this post.


Sorry but this is not the solution. I have an atmega644 so it won't make sense to set it to a 168.
GEN3 is not defined in the config.h, it seems like it is gone in one of the last commits.
There is also no definition of TEMP_INTERCOM.

Any other hints?

With this patches to the intercom-protocol branch I get a correct packet back from the extruder controller.
If only extruder/host would do something with it ...

Jacky2k Wrote:
-------------------------------------------------------
> Sorry but this is not the solution. I have an
> atmega644 so it won't make sense to set it to a
> 168.
> GEN3 is not defined in the config.h, it seems like
> it is gone in one of the last commits.
> There is also no definition of TEMP_INTERCOM.
>
> Any other hints?

I meant this part. I should probably have said see number 6.

6. Yikes! error
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.

found in covered in [www.arduino.cc]
Wrong avrdude used changed FiveD Makefile to :

#AVRDUDE = avrdude
#AVRDUDECONF = /etc/avrdude.conf
AVRDUDE = /home//arduino/arduino-0022/hardware/tools/avrdude
AVRDUDECONF = /home//arduino/arduino-0022/hardware/tools/avrdude.conf

Yippee! Got 100% with $ make program

Markus Amsler Wrote:
-------------------------------------------------------
> With this patches to the intercom-protocol branch
> I get a correct packet back from the extruder
> controller.
> If only extruder/host would do something with it
> ...

with that many patches, a pull request via github is much easier, probably for both of us

Jacky2K Wrote:
-------------------------------------------------------
> avrdude: Device signature = 0x000000
> avrdude: Yikes! Invalid device signature.
> When I use the -F option everything works fine and the firmware is running!
> Any idea why avrdude gets the wrong device signature?

yep, the arduino bootloader doesn't use the standard device signature command, they implemented their own one for reasons unknown. That's why the arduino-provided avrdude works because they patched it to match.

I found it much easier to just install optiboot on my chips which uses the standard device signature command, and so works with standard, unmodified avrdude.

Jacky2K Wrote:
-------------------------------------------------------
> I have an other problem:
> DEFINE_HEATER(extruder, PORTA, PINA0, 0)
> And get this compiler error:
> config.h:291: error: lvalue required as unary '&' operand

This is a regression from the way the new DEFINE_TEMP_SENSOR / DEFINE_HEATER stuff is done. Attached patch is ugly, but will get you sorted until we figure out an elegant way to do this that actually works in all cases

Spaztik Wrote:
-------------------------------------------------------
> I guess the commit with the comment "try to make E behave" probably fixed the extruder.

good to hear, not sure why this didn't get picked up earlier! Maybe everyone /expects/ their extruder to keep going regardless of gcode commands when they start printing?

---

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

pushed to master:

fix example heaters, add note to gen3 config clarifying that heaters connected to extruder go in extruder config

pushed to intercom-protocol:

itercom: Enable the RS485 transceiver on the host.
intercom: Send packet only once.
intercom: Init start byte.
intercom: don't store start byte twice.
intercom: Add delay before slave replies. Without it the first byte gets lost.
intercom: Disable rx while doing tx. Avoids local RS485 half-duplex echo.

now, should I rebase intercom-protocol vs master, or try to navigate the merge madness maze?

---

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

This patches should also work on master. Now the extruder heater works here with intercom-protocol.

pushed, thanks.

ps: not sure where you're basing your patches, but config.* don't have ifdef _CONFIG_H in them so the last patch failed

---

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

I was basing them on intercom_protocol. But it look like extruder/config.h.dist does have ifdefs even in master
[github.com] . No idea what's going on.

For me intercom_protocol now works better than master, so you might merge them, before they diverge too much.

I am having much difficulty tuning the PID controller. I think I might know why but I wanted to confirm before I spend more time fiddling with the numbers. I found the following quote from Triffid_Hunter in another thread.

Triffid_Hunter Wrote:
-------------------------------------------------------
> The values are signed, I was just putting in
> negative D values. This works too, and is probably closer to the
> standard PID

So just to be sure, are the D factor values supposed to be negative? If yes, then shouldn't the default value in heater.c be negative too?

I have found that anything above about .08 for the I factor oscillates. Not sure if that will change if I start using negative D factor. I am wondering how large a number can be used for I limit and whether a very high I limit is reasonable?

Does anyone know of any tools to help with PID tuning. I am thinking of a host side talker that graphs the temp and lets you manually send G codes. ReplicatorG has an alright graph but I cannot figure out how to manually send Gcodes. This means anytime I change the PID settings I have to close the graph which makes it difficult to compare one setting to another as all the previous info is lost.

spaztik Wrote:
-------------------------------------------------------
> I am having much difficulty tuning the PID
> controller. I think I might know why but I wanted
> to confirm before I spend more time fiddling with
> the numbers. I found the following quote from
> Triffid_Hunter in another thread.
>
> Triffid_Hunter Wrote:
> --------------------------------------------------
> -----
> > The values are signed, I was just putting in
> > negative D values. This works too, and is
> probably closer to the
> > standard PID
>
> So just to be sure, are the D factor values
> supposed to be negative? If yes, then shouldn't
> the default value in heater.c be negative too?

A negative D causes the heater to cool off a bit if the heat rises really fast, which is good for limiting overdue. That's the theory anyway.

> I have found that anything above about .08 for the
> I factor oscillates. Not sure if that will change
> if I start using negative D factor. I am wondering
> how large a number can be used for I limit and
> whether a very high I limit is reasonable?

A very high I limit just leads to integral wind-up, causing huge overshoot. I find that resultant I factor (the scaled value that debug reports) * I limit should be around 192, or whatever static value can maintain your heater at your highest temperature of interest

I think preventing the integrator from counting until we're near our target temp may be a good idea

> Does anyone know of any tools to help with PID
> tuning. I am thinking of a host side talker that
> graphs the temp and lets you manually send G
> codes. ReplicatorG has an alright graph but I
> cannot figure out how to manually send Gcodes.
> This means anytime I change the PID settings I
> have to close the graph which makes it difficult
> to compare one setting to another as all the
> previous info is lost.


Wikipedia links to a few methods that will get you in the ballpark of good settings. also, pid without a phd really is your friend.

---

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

To maintain I_factor * I_limit = 192, when using very small values for I_factor, I_limit needs to be very large.

Example: I_factor =.1
I_limit = 192 / I_factor -> I_limit = 192 / .1 = 1920

I am wondering what the maximum/reasonable value of I_limit can be. A related question is what should I_limit be set at when you have I_factor set to 0 when tuning.

Triffid_Hunter Wrote:
-------------------------------------------------------
> Wikipedia links to a few methods that will get you
> in the ballpark of good settings. also, pid
> without a phd really is your friend.

I have read PID without PhD and it was very helpful. Without it I probably wouldn't know enough to even ask questions on this subject. I tried the tuning method at the end of PID without PhD and the manual method described on the Wikipedia page but didn't have much luck. Probably because I was entering positive values for D_factor and maybe wasn't setting I_limit correctly.

I_factor is scaled by 1024 in the firmware, so when you provide 0.1, it scales to 102. that's what I meant by the resultant value that debug lists

---

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

My extruder runs fine for a while, then sits and waits to warm up. The extruder itself can continuously vapourise the filament to treacly goo if left on even at 50% PWM (in test code), so I think I just need to increase the PWM output.

I've already increased the hysteresis value to 40 and the residence time to 3s. I also removed the labs() from around the residence time calculation because anything hotter than the target temperature should be considered as being up to heat!

Are there any guidelines on what I should fiddle to increase the PWM in FiveD and by how much?

Vik :v)

spaztik Wrote:
-------------------------------------------------------
> To maintain I_factor * I_limit = 192, when using
> very small values for I_factor, I_limit needs to
> be very large.
>
> Example: I_factor =.1
> I_limit = 192 / I_factor -> I_limit = 192 / .1 =
> 1920
>
> I am wondering what the maximum/reasonable value
> of I_limit can be. A related question is what
> should I_limit be set at when you have I_factor
> set to 0 when tuning.
>
> Triffid_Hunter Wrote:
> --------------------------------------------------
> -----
> > Wikipedia links to a few methods that will get
> you
> > in the ballpark of good settings. also, pid
> > without a phd really is your friend.
>

here are the M codes I send to initialize my PID before a print. they work very well for what I have set up.

M111 s1
M130 s8
M131 s0.5
M132 s24
M133 s0.375

I need to loop back and see why the EEMEM is not being saved on my units. (Must raise the priority of this on my list)

I had to make this simple change in my Heater.c file to get it to behave.
unless all of the D values are negative not just when cooling then the math didn't jive.

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

Have you tried blanking the EMEM first?

Vik :v)