Project: Teacup Firmware

emt,

You will also need to enable VREF to 5V before this will work. I'm not at home right now so I can't paste in exactely what I did, but you have to set a couple of registers to select it when doing the other setup stuff.

Demented

---

[www.urbansurvivalists.com]

Quote

I noticed earlier you indicated it would probably also work with the Mega. If I set this as the board I get a compile error PRR undeclared

I'm not Triffid, but try to answer anyways.

PRR is the "Power Reduction Register", something not exactly the most important feature in our type of usage. Unfortunately, I can't find the datasheet for the "Mega" in the big List (which chip is this exactly?) and I can't test, so I have to guess a bit.

Replace the line containing "PRR" with the following sequence, it makes the code at least compilable:

	#ifdef PRR
	PRR = MASK(PRTWI) | MASK(PRADC);
	#endif
	#ifdef PRR0
	PRR0 = MASK(PRTWI) | MASK(PRADC);
	PRR1 = 0xFF;
	#endif

In case the Arduino IDE doesn't show you the faulty line automatically, you have to edit mendel.c with another text editor, as this file isn't accessible from the IDE.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Many thanks.

That did the trick and it now compiles.

Fortunately mendel.c can be edited from the Arduino IDE.

The chip is ATmega1280.

I have now changed to the thermistor temp.c and I have a new error.

in function 'temp read':
THERMISTOR_PIN undeclared (first use in this function).

OK that I sort of understand so in pinout.h I change
#define HEATER_PIN DIO6 to
#define THERMISTOR_PIN DIO6

I then get.
error:- in function 'temp read': error
DIO6 undeclared (first use in this function).

This I don't understand. I guess the declaration is in the wrong place but I don't know how to correct this.

---

Regards

Ian

Hi,

Nice to see this project is still alive. I'm ready to have another go with the code, I'm currently hunting down bugs on my latest driver design. I'll let you know how it goes.

Quote

The chip is ATmega1280.

Thanks. This confirms the given patch is fine.

No clue on the other one right now, but probably I'll have to find out myself soon.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Just uploaded the patches needed for Reprap Host compatibility to github (and removed them from the Wiki).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

I then get.
error:- in function 'temp read': error
DIO6 undeclared (first use in this function).

Is this DIO6 or DI06? Other than that I can't help you much, because I neither own a heater, nor an Arduino Mega, nor is the thermistor patch small enough to learn in quickly.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Demented Chihuahua Wrote:

> perhaps something like
> this?
>
>
> if (bit_is_set(ADCSRA, ADSC)){
> raw.bytes.low = ADCL;
> raw.bytes.high = ADCH;
> old_low = ADCL;
> old_high = ADCH;
> } else {
> raw.bytes.low = old_low;
> raw.bytes.high = old_high;
> }
>
> in place of this
>
> while (bit_is_set(ADCSRA, ADSC));
> raw.bytes.low = ADCL;
> raw.bytes.high = ADCH;
>
> Demented

Yes, that should do it. Make sure nothing else is using the a/d converter though. Search for ADC in the codebase. Pretty much anything else that refers to ADC* would interfere. I don't think there is anything though. If there is then you'll need to create a new global variable to keep track of which a/d conversion was started last, and do the right thing in both places...

As a side note, this isn't my code. Or not mostly, anyway. It's pretty much cut'n'paste from the standard firmware. I did change the "clamping to 255 max temp reported" bit, since Triffid's code doesn't use a byte to report the temperature. And moved the temp table into the .c file instead of a .h file. And maybe did a couple of other things, but I think that's it.

Provided this code works in the first place, the only thing that you may want to change is the temp table, to adjust for what kind of thermistor you have, what sort of resistor(s) it's paired with, and to compensate for the particular thermistors resistance curve.

From what I understand, the 100K thermistors aren't particularly accurate across thermistors, but each thermistor is very consistent. So by testing your thermistor (in icewater, maybe boiling water too) and generating a custom temperature table, you can get very accurate results. Of course, nozzle temp != extruded plastic temp, so there may be no point, as you'd almost certainly need to fine-tune it to your particular machine anyway. Not that I wold know...

---

--
I'm building it with Baling Wire

Hi jgilmore

I used your version of temp.c for thermistor and got this error on compile.

in function 'temp read':
THERMISTOR_PIN undeclared (first use in this function).

My efforts to solve it by changing pinout.h

#define HEATER_PIN DIO6 to
#define THERMISTOR_PIN DIO6

failed and I then get.
error:- in function 'temp read': error
DIO6 undeclared (first use in this function).

Could you please help me resolve this problem.

---

Regards

Ian

emt,

A couple things to help you out:

1. You have to enable VREF to 5V internal for the ADC to work. Do this in mendel.c where all the other initialization happens:

//Set VREF to 5V.
ADMUX=(1<Edited 1 time(s). Last edit at 07/16/2010 02:47PM by Demented Chihuahua.

[www.urbansurvivalists.com]

you all may want to check out arduino.h, that's where I stuck lots of pin mapping stuff along with some macros that make things really easy. it needs to be altered for chips other than the 168/328 series. ifdef is your friend

if you want commit access to git, let me know. I'm more than happy to pass this into the hands of capable people who have more time for it than I currently do.

---

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

Hi Demented

Many thanks.

I have now got it to compile for the Mega with Thermistor.

I explicitly defined the thermistor pin for the moment as I have not got my head around the AIOnn DIOnn #defines.

I will have to and also tidy everything up as my board uses totally different pins.

---

Regards

Ian

I haven't made a set of analog functions to make good use of my AIOnn defines system since there's nothing using analog inputs on my setup. If you check out arduino.h, you may get some idea. When one of the read/write/etc macros is passed eg DIO3, it adds _PIN, _RPORT etc as necessary, then DIO3_PIN or whatever is defined lower down in the 'pins' section as a real register with which we can do something useful. For analog stuff, all you would need to do is find all the registers necessary for reading any particular pin, then define AIO2_PIN, AIO2_DDR, AIO2_START, AIO2_MASK, AIO2_RESULT or whatever ends up making sense, then create some macros similar to READ/WRITE etc that pass appropriate registers to some real functions.

Analog will probably boost the codesize up beyond what can fit on a '168, the debugging extras already don't fit. should still fit on the '328 and bigger though.

alternatively, you can just hard-code it and let someone else figure it out

---

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

I made a new git repository to separate this project out from my other stuff and also to give a more descriptive name.

[github.com]

I'm pretty new to both git and CVS in general so it may have been quite a messy move- if you notice anything that's wrong or out of place, please point it out and I'll do my best to fix, or just tell me how to fix if you're more experienced than me

---

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

Thanks for cleaning the repo.

The files mendel.pde and .gitignore got removed. Any specific reason for this or should I add them back?

Some good instructions on how to use git in a tidy, collaborative-friendly manner can be found in Wine's Wiki. For me, keeping the local master branch free of local changes works very well, coding is done in another, local-only branch ("work"). This way, conflicts can be solved and test compilations can be done before sending them to the public.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

thanks Traumflug, add them back in. also check that the patches you've submitted are in there, apparently my local copy was dirty when I did the moving

I'm reading wine wiki now

---

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

While having great success with FiveD on Arduino for single moves, I yesterday learned this firmware starts to skip movements here if I issue more than about a dozen lines of GCode. Apparently these movements get recognized by dda_create() correctly, but result in a no-op.

Code is the current version from Git, with XON/XOFF enabled, plus a few #includes to get this compiling. The more lines I send to the controller, the more movements get skipped. After some 30 lines, any movement is skipped, the machine just stops.

Does this work for anybody? If yes, how do you send commands to the controller? Here I'm using a serial terminal emulator, CoolTerm on Mac OS X 10.4.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi!

Yep I did have a similar issue trying with the output from pcb2gcode

Made me go crazy trying to fix the "bug" in my drivers, I did not imagine it could be something with the 5d code...

I'm using a simple python script to send the G-CODE using the serial link, line by line after ok. Worked pretty randomly, sometimes it locked after the first 20 lines or so other times after 100 lines or more.

For now I switched to the dark side, I'm using EMC2, at least until I'm sure my drivers are really bug free.

Cheers!

I might be wrong, but don't you have to wait for an OK back before sending the next line?

The RR host has a line number / retry mechanism.

---

[www.hydraraptor.blogspot.com]

Quote

I might be wrong, but don't you have to wait for an OK back before sending the next line?

As there is no other flow control by default, characters will be dropped as soon as the movement buffer (stores 8 movements) is full. If you use RR host, RR host will do that waiting for you. It's perfectly fine to use another application to send commands, though.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

As far as I know, the firmware waits until there is a space in the queue before saying "ok", so the ringbuffers should only start dropping if the host-side talker is sending stuff while it should be waiting for an ok. If you are using a terminal emulator, it does not know to wait for an ok and may do exactly that.

Another issue may be that the serial receive ringbuffer is filling and something strange is happening when it becomes full. I have barely tested the xon/xoff mechanism so it may be causing a mess when leaned on, or maybe something else is happening.

In the meantime, use a talker rather than a terminal emulator. There are a couple in the repository, check sender.sh for a very simple example and func.sh for some debugging tools. I think mas osx has bash available, may just need to change a few things, eg; the path to the serial device.

---

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

Small update: So far, XON/XOFF works apparently great and the required patch is secured in my local repo.

This doesn't solve skipped movements, though. After many debug builds I managed to find a fully reproducible case with one line sent manually at a time, plenty of pause in between. After dda_create() returns, the "nullmove" flag of the skipped movement is set, despite it's correctly recognized as !nullmove at the functions' beginning. So all the queueing stuff works as expected and the journey continues to find out where this flag is accidentally set.

I hope I can keep you updated.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... i had similar skipped steps with inverted STP-signals - then i'll loose one step in every line

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Got one. The nullmove flag wasn't initialized, so once set, it would never be cleared again for movements re-using the same memory space.

Committed to github, but I fear there's more to do.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hey everyone,

I have taken this project and modified it to run on the standard Gen3 electronics for Mendel. I have a Motherboard 1.2 and Extruder Controller 2.2

Sorry I haven't been monitoring this thread enough, but I had to fix that null move flag bug myself just a few days ago too!

Anyways, the way it works is that I wrote a minimalistic firmware for the extruder controller that just drivers my extruder stepper and the heater/themistor reading. It talks over RS485 using a tiny miny protocol, and all the main logic is on the Motherboard. It all follows the same design principles as the rest of this firmware package

Performance has been great, especially with a 32 move buffer! I am getting parts printing at 32mm/sec that are completely flawless. All this without bothering for SD card prints.

Triffid, if you'd like to chat, maybe I can get my own branch on the github to post my changes into. It's more than a couple small changes because of the multiple boards, but this firmware works so much better for me than the default 5D one that I thought I could share it for other people who have the default electronics.

Send me an email if you can:

jakepoz, glad to see I don't have to expect further road stops. Perhaps it's time for you to get rid of the twin controller?

On my part, FiveD on Arduino works now well, too. The remaining issues were due to changes made for debugging. Everything is on github, including a now working XON/XOFF implementation (disabled by default), so please test and enjoy.

Next thing is to get start-stop-ramping (still on the Wiki page) properly into github.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I'd love to see a post on the blog aggregator about successful prints made with this firmware, and it sounds like I'm definitely not going to be the one making it- I'm between houses at the moment, and my current living arrangements have little to no room for further development of my cartesian bot.

Quick question: when you're a collaborator on github, can you add other collaborators? Or is that particular honor mine alone? Is there a setting somewhere that I can change?

---

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

Traumflug, looks like you've been powering through the firmware! Thanks for all your hard work- the start-stop ramping stuff looks awesome! I think that'll save a lot of prints from poor host-side comms.

Is it possible to blend the moves in the queue together, eg; start at finish speed of previous move and ramp down to speed of next move, or some low speed if it's the last move in the queue? This way, it behaves very much like normal reprap firmware when the queue is being filled properly, but will hugely smooth things out if the queue filling gets rocky for any reason. The math is available in that article, but requires a lot of pushing things around. It took me many hours and a headache to work it out when I wrote dda.c, and I'd have to read it for many hours again to even begin having a crack at it myself.

jakepoz, email sent. Great to hear that it works with stock electronics! Did you use a thermistor or a MAX6675? Would love to know details of what had to change- having this firmware work straight from the repo on stock electronics would be wonderful for attracting more user/developers

---

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

Hi

If any one has this working with a thermistor extruder and thermistor bed I would like to get hold of a copy. I would like to implement this on a mega. My Arduino programming knowledge is such that I should be able to make the required pin changes but not much more at this stage.

---

Regards

Ian

First of all, thanks for the kind words.

Quote
Triffid_Hunter
Is it possible to blend the moves in the queue together [...]?

Clearly, that's what I'd sooner implement today than tomorrow. However, even with tons of googling, I can't find any prior (and open source) art implemented. Crafting an algorithm from scratch isn't exactly trivial, so this will take more time.

For example, each movement initially has to expect a full stop. There's no guarantee a follow-up movement will come in. So you have to rework already queued movements. How about movements already being processed?

Also, each blending unavoidably results in geometric errors[*]. How do you estimate geometrical error vs. ramp steepness vs. number of blended steps?

If anybody has seen an implementation, please tell me.


@emt:

You can simply go ahead and try. Sources can be downloaded at [github.com] . It can be built and uploaded with the plain Arduino IDE and reverting back is a matter of a minute as I'm sure you have the sources of your current firmware around as well.


[*]The same is true for the ignore-acceleration-for-now approach of the official firmware, but they don't talk about that ;-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY