RepRap Software for RepRap Hardware

I was so keen to type I did'nt type what I meant ,read enhanced rather than increased.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Yes exactly, replacing a similar amount of firmware with some different firmware ... but I could have both. What I will probably do is use Ethernet to upload a file to the SD card and then tell the machine to run it and report back status.

I always look for the simplest solution that achieves the desired result. I would wager that I have the least firmware and software in my system but the results are as good as anybodies. I also try to fix problems in the process at source rather than bodging round them with more software, i.e. I refine my extruder to get good results rather than relying on lots of clever stuff in Skeinforge,

Things like polar and tripod machines will trade some mechanical complexity for software, which can be good thing to bring cost down.

---

[www.hydraraptor.blogspot.com]

You won't here me argue against quality hardware.

I have spent too much time being annoyed with folk that insist I bodge in software what should have been fixed in the hardware. Consequently limiting the software and producing questionable data.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Doh, my entire last post got et.

ok, trying again. Years ago I wrote a forth interpreter/compiler for the appleII computer and have had to deal with forth variants in plc programing environments (i.e.parasol) so have some familiarity with it. I see no reason that a end user would be able to tell the difference from a forth based controler and the current one. feed it g-code and out comes a print.

on the other hand, from a testing and trouble shooting standpoint. interpreted environments do make doing so easier and forth would be a excelent choice for doing so. It was designed for small form factor and very fast run time.

of course the next question on this would be is there a forth interpreter that could be installed on a mega board as is or would it have to be started from scratch?

if scratch then probably not worth the effort but that is just my opinion. though i have been considering purchasing a arm board to test some ideas with.

RBisping Wrote:
> of course the next question on this would be is
> there a forth interpreter that could be installed
> on a mega board as is or would it have to be
> started from scratch?

[amforth.sourceforge.net]

I have to concur with BeagleFury

The Forth closes to our needs (as is) is amforth.

Their development direction though is AVR Butterfly wards and there seems to be little interest in adding in the neccesary bits to do Arduino Mega (AVR 1280) or the Memory upgraded 168 let alone the 664 as well.

Looking at the memory needs etc it should all go into an Arduino Mega easily with space left to do plenty more.

Mathias's code/ing looks to be good and he seems to regularly update bits and pieces. I have been following their project for a little while now.

In fairness I think that the lack of interest in the Arduino boards as an AVR/Amforth platform stems from the fact that the project looks to be largly Mathias on his own and his needs are fulfilled more closely by the Butterfly.

He is approachable and has been quick and positive in his replys. So their is perhaps mileage in this.

amforth should be useable pretty much as is with the addition of the relevant hardware definition file/s for the 1280. Mathias indicated that he thought so too.

I have an earlier version of the code and was looking at copying the existing hardware definitions and hacking this before adding it to my to do list. (It is a very long list BTW, so if someone wants to jump in, please do).

Best mileage I feel is to add the config/hadware definition files to Mathias's project so that they become part and parcel of the distribution of amforth (if Mathias is amenable). Any additional RepRap specific code then is added to the RepRap repository. The aim being to arrange it such that the projects remain compatible but distinct and separate.

Amforth can continue to develop and do it's own thing with Rep Rap benefiting indirectly and amforth gets a wider appeal (more commodity platforms available and a tie in to the Arduino Project) without being tied to tightly to RepRap or Arduino.

Standing on the shoulders of giants and all that...

I feel it would be a mistake to take a full fork from amforth to do this and risks ending up with an orphaned, non maintained code base.

There is the potential for a high degree of synergy here. Not to mention a Project or two that is suitable for high school and or degree level, that could benefit all contributors.

This is my take on the situation for what it is worth, what do you guys think ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

On Arm

I would be looking most carefully at going the embeded RT Linux route. (Forth doable still, but as perhaps gforth)

The ARM is arguably overkill unless some of that greater potential is put to use.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Amforth looks really promising.

This may be just the sort of interpreter that is not seen as to complex for the entry level user.

A board like the Butterfly is the best sort term solution to making the electronics easier and more accessible to the average user. Now if someone would make a stable Arduino branch for the Butterfly ...

Would that I had more time to play with amforth. Probably best I continue with the work on the SD card and existing 1.2 motherboard. Must remember to stay focused. Too many interesting branches are happening all at once.

I still think the existing Gen 3 electronics will remain valid for the next 6 to 18 months. After that hopefully there will be progress on Embedded RT Linux on an Arm type platform.


-julie

I agree staying focused with some much going of is difficult, That is probably why my to-do list is so long.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Guys

I have just been having a rummage through the latest release of amforth.

Their latest release 25.4.2010: release 3.8 is now available for download and supports pretty much (with a minor exception) the processors that the arduino and variant run on.

168, Diecimila
644, Sanguino

There is not as yet an explicit 1280 configuration but there is a 640 configuration which is the same as the 1280 but with half the memory. So a copy of the 640 file s and a minor tweak should support the Arduino Mega.

All in all the guys over there have made some outstanding changes and they are part of the core distribution. Most excellent.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

To leave this thread relatively implementing forth free. I have created a thread for discusing inplementing forth in this experimental firmware section.

[forums.reprap.org]

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Amforth now supports the Arduino Mega. I have just completed the first cut of the template files and they are in the Amforth trunk repository.

On self replicating firmware the guys over on the amforth project are currently having a think about the task of cloning running forth systems to blank devices/boards.

Cheers

Andy Kirby (aka47)

---

Necessity hopefully becomes the absentee parent of successfully invented children.