Project: Teacup Firmware

I am trying to understand the code, trying to build it for ARM. I have many questions and I would love to chat in real time with one of you both. Can we chat on IRC RepRap channel? or maybe on gmail chat? (my e-mail is casainho gmail.com).

Thanks.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

basically it /does/ run 4 "independent" timers, but it uses only one hardware timer to implement them all.

It calculates the time at which the next step occurs on any axis, then sets the timer for that timeout. When the timer ticks, it steps all axes that need to step, adds elapsed time to each axes' counter, then finds how long until the next step and plugs that into the timer for the next timeout. On the last step when all step counters reach zero, the dda dies.

Might be some optimisation possibilities in making the counters count down towards zero rather than up now that I think about it.

All those ifs are necessary because the algorithm goes crazy if one axis doesn't step at all during a move. There were many ways to get around this, and that one seemed easiest to me at the time. You should be able to comment them out of the perl script for quick visualisation.

speaking of the perl script, run

./temporal-calc.pl 2>temporal_data && gnuplot temporal-calc.plot && display temporal.png

for a graph of each step plotted against time and distance from target

---

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

posted a new branch, multi_temp, for implementation of support for multiple temperature sensor/heater pairs. do we need support for temp sensors without heater or vice versa?

---

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

Hi

I can't see a need for a temperature sensor without a heater in normal circumstances but you never know. Maybe there will be a time when a seperate temperature input could be handy.

---

Regards

Ian

System should be able to measure sensors without heaters, like for measuring the temperature of Heated Room. On Heated Room. One can use a fan or not to remove the heat from the room.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

sersendf() is working. I am now trying to understand DDA code.

I am sending a screenshot while I was doing debug/verifying program running:



Edited 2 time(s). Last edit at 10/14/2013 09:52AM by Traumflug.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

the DDA is actually quite a tricky piece of code to wrap your head around due to all the funky stuff that goes on there. suffice it to say that it figures out the proper time to step the fastest axis, then works out which axes need to step at every timer tick. When one of the acceleration methods is enabled, it also works out the timeout until the next step. It does all this with a combination integer or fixed-point math.

I highly recommend you ignore all that for now, and wrap your head around the ringbuffers (serial tx/rx buffers and dda queue are both ringbuffers) and gcode parser

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> I highly recommend you ignore all that for now,
> and wrap your head around the ringbuffers (serial
> tx/rx buffers and dda queue are both ringbuffers)
> and gcode parser

I were able to build all the code, but for some reason the communications with software do not work correctly, although I can see the messages sent by firmware to software and vice-versa. The problem may be because I changed some pieces of code, for it build. Who knows if I changed something problematic? -- I will now make diffs from original code to my port, and see what I changed and try to put all equal to original.

And yeah, since I understand, DDA and Interrupt is just needed for stepper motors pulses, before that, communications can be tested and reading temperature, for example.

I am using this LPC1768 dev board, so I do have USB<->Serial done by the LPC1768 and also there is no secondary extruder board, LPC1768 must do everything :-)

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I got comms working, at least I believe so. I need now to start testing and see what is missing, since I didn't wrote any drivers for my board.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

looks like you need to add -DREPRAP_HOST_COMPATIBILITY to your makefile, or use one of the talkers I include.. those errors are your host software not liking this firmware's responses, particularly the constant temperature updates.

ps: this firmware is also designed to run everything from one board (except the gen3 branch) so don't worry about that

---

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

Even better would be to tweak RepRap Host to be more tolerant on answers.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Even better would be to tweak RepRap Host to be
> more tolerant on answers.

No way, I want the board to be perfectly compatible with RepRap software. I prefer to just need to tweak firmware instead of firmware + software. My idea is to make something that "just works" so everyone can access to/use it.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I added an entry for this in RepRap_CAM_Toolchains and Traumflug added to it, but removed mention of the Gen3 compatibility. Is it intended not to be supported at all? I thought the Gen3 branch was supposed to work and be kept up to date. I was really hoping to be able to use it instead of the one by Adrian.

I agree that Gen3 isn't the most compact configuration, but it is widely used. And I'm not going to buy or hack together a different set of electronics just to use firmware that is supposed to be more compatible or smaller.

If I can get the firmware to work (couldn't get it to upload), I might even be able to help keeping the branch up to date. Or what about merging it properly?

Now about me using the firmware:

Would it be possible to have a single config.h file, or at least document all the places to look for. I couldn't find any mention of inverting axes (had to invert one on my mendel), end stops and other particularities. I could try to hack the code my self, but would like some hints or documentation as to what would be appropriate.

Quote

I added an entry for this in RepRap_CAM_Toolchains [...]

Great idea, thanks for that.

Quote

[...]and Traumflug added to it, but removed mention of the Gen3 compatibility.

To the best of my knowledge, FiveD on Arduino doesn't support communication between the main controller and the extruder controller, making it somewhat incompatible with Generation 3 electronics. Regarding the "gen3" branch I had the impression this is a fork meant to run on the extruder controller only, but I might be wrong.

Quote

Is it intended not to be supported at all?

Nobody will hold you back from using the firmware on whatever you think it fit's on. In fact, you'll probably get quite some applause if you manage to make use of it on Generation 3 electronics.

Quote

I was really hoping to be able to use it instead of the one by Adrian.

I haven't such a Gen3 board here, so I have to guess a bit. Is it possible to make a single controller version from Gen3 by just ignoring the ATmega chip on the extruder controller? That means you'd have to hook up the extruder motor directly to the main controller somehow.

Quote

Would it be possible to have a single config.h file, or at least document all the places to look for.

Sure, please go ahead. Currently, all the #defines are spread across a number of .h files, sorted by functionality. Having some installation instruction on the Wiki page would be just great.

Pulling the parts interesting for user configuration (and only that) out into a config.h is probably a bit more work, but something I'd vote for.

Quote

I couldn't find any mention of inverting axes (had to invert one on my mendel), end stops and other particularities.

Me not, too, leading to the impression this isn't supported yet. As a true hacker one makes the hardware fit the software, i.e. swap the leads of one stepper motor coil (pins A & to reverse him

That said, the RepRap community generally agrees such inverting bits are a good idea, so we should have that as well. The related code is in pinout.h, line 60ff, probably swapping

#define  x_step()  _x_step(1);

to

#define  x_step()  _x_step(0);

is sufficient. Please test.

Regarding endstops, I'm pretty sure they're not enabled either, as they're commented out in dda.c line 342, 357 and 372. Please remove the comment markers and look what happens. At a first glance, the remaining pieces are in place.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

regarding gen3, jakepoz says that he has printed objects using gen3 branch, which includes FiveD on Arduino running on the '644 on the motherboard plus a smaller branch for the extruder with a crude yet effective communication protocol between them. I have not tested it yet, just had a read-through to see how jakepoz achieved what he did.

A unified spot for configuration would be great! I have been slowly moving bits and pieces into machine.h, which could probably merge with pinout.h and have most of it done. There will still be bits and pieces scattered around, eg the temerature/heater definitions in temp.c and heater.c in the multi_temp branch which will be merged into main eventually.

As for axis swap and endstops and things, my hardware has no endstops just yet, and as traumflug says simply swapping a couple of stepper wires serves to reverse direction, however firmware support for swapping would probably be helpful in some situations.. another thing to somehow shoehorn into machine.h in a sensible fashion.

perhaps we should merge machine.h and pinout.h and rename it as config.h? I may do some work on the readme too- seems that at this point having information for firmware hackers would be rather useful.

---

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

Me wrote: (pins A & to reverse

Me meant: (pins A & B ) to reverse. Nasty smileys.

Quote

regarding gen3, jakepoz says [...]

I'll try to ask him what exactly he's doing. He obviously hangs out at Github.

Quote

perhaps we should merge machine.h and pinout.h and rename it as config.h?

We could also put only the essential bits into config.h, e.g. STEPS_PER_MM, but not UM_PER_STEP. Also I think the official firmware's idea to distribute a config.h.dist instead of a config.h is a good one.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

yup, separate local settings from repository-managed files is a great idea.

Just pushed an implementation

---

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

Added to wiki: http://objects.reprap.org/wiki/FiveD_on_Arduino

mostly just pasted in the README

add some comments of your own

---

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

Good!!!

My port is working for enable with host software the heater and reading the temperature.

I am still receiving this error from host software. I need to work this error!!

After I need to start testing the stepper motors, but for that I need to wire them to the board.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I would really like to have the gen3 configuration merged in to master. Minimally it is mostly just some ifdefs from the point of view of single board configs, so shouldn't be too awkward. I've actually started doing just that.

elnorm, that's a great idea. Please try to break down the changes into small patches by functionality, because this is the only way to keep master working reliably. I just tried to rebase the gen3 branch to a more recent master and had to give up. Too many unrelated changes in one patch, tons of whitespace changes, personal preferences going into the public repo, you name it.

Myself, I have best success with creating a local branch and piling up and reviewing patches there, until everything is separated by functionality and applying every single patch creates a buildable, working version. Using "git diff" before a commit is a must. If I really feel like whitespace changes are needed, I put this into a separate patch. Then I cherry-pick the patches meant for the public from my local working branch to my local master and push this out (after a pull), keeping local changes local. Back in the working branch, a simple "rebase master" keeps this branch up to date and removes local patches which are already in the public.

In your case, I'd probably fork the master branch instead of the gen3 branch, as master is the one you want to approach.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug, I had an inkling that you were cherry-picking from a local branch or something.. not that familiar with git yet but I think I really must start doing that so master isn't so messy.

that's my bad- haven't done collaboration via repository before, I've been treating it like a private local repo :/

thanks for the insight into your workflow- I'll try to learn that instead of what I've been doing so far

---

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

I get

"In function ‘copy’:
error: ‘SIGNATURE_0’ undeclared (first use in this function)"

(in copier.c)

when trying to compile in the arduino environment. Would use the makefile, but can't seem to be able to program with it.

Ah, copier.c shouldn't be included at all. Will try again.

Could you give the firmware a heartbeat, as in make the debug led (pin 13 in arduino) blink during every round of the main loop. Makes debugging easier to know if the firmware has crashed or not Now I just get a "¹" after resetting.

Edited 1 time(s). Last edit at 10/05/2010 09:59AM by elmom.

Traumflug Wrote:
-------------------------------------------------------
> elnorm, that's a great idea. Please try to break
> down the changes into small patches by
> functionality, because this is the only way to
> keep master working reliably. I just tried to
> rebase the gen3 branch to a more recent master and
> had to give up. Too many unrelated changes in one
> patch, tons of whitespace changes, personal
> preferences going into the public repo, you name
> it.

Yes, it's a mess

>
> Myself, I have best success with creating a local
> branch and piling up and reviewing patches there,
> until everything is separated by functionality and
> applying every single patch creates a buildable,
> working version. Using "git diff" before a commit
> is a must. If I really feel like whitespace
> changes are needed, I put this into a separate
> patch. Then I cherry-pick the patches meant for
> the public from my local working branch to my
> local master and push this out (after a pull),
> keeping local changes local. Back in the working
> branch, a simple "rebase master" keeps this branch
> up to date and removes local patches which are
> already in the public.
>
> In your case, I'd probably fork the master branch
> instead of the gen3 branch, as master is the one
> you want to approach.

I've already upped some simple changes into a public branch (gen3_integration) in my fork on github (http://github.com/elmom/FiveD_on_Arduino). Don't touch master, it's a mess that should be on a branch

I'll propably soon refork and try to follow what you described though.

Quote
Triffid_Hunter
that's my bad

Triffid, I probably didn't mean you when talking about some mess ... actually I'm very happy on how you comment my patches and manage (or non-manage) the project in general.

Quote
elmom
Could you give the firmware a heartbeat, as in make the debug led (pin 13 in arduino) blink during every round of the main loop.

As the main loop doesn't do anything but decoding GCode, the heart beat is in the stepper interrupt. Of course it's so fast you typically can see a dim, constant light only. Higher motor speeds or acceleration ramping in action makes the LED a bit brighter, as this in more computing intensive. Stopping all motors makes the light going off.

There's also some debug code in mendel.c which reports the current position every second. If you didn't turn on debugging in general, comment out the if()'s around it to activate it.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Now my public master branch should include all the atomic and noninvasive improvements that I've made so far. You are welcome to pull them.

> As the main loop doesn't do anything but decoding
> GCode, the heart beat is in the stepper interrupt.
> Of course it's so fast you typically can see a
> dim, constant light only. Higher motor speeds or
> acceleration ramping in action makes the LED a bit
> brighter, as this in more computing intensive.
> Stopping all motors makes the light going off.
>

So is the debug pin defined in arduino.h then? I included a pin definition for that in one of my commits. The debug led pin is board dependent. Someone might even want to use that for something else.