RepRap Software for RepRap Hardware

The RepRap project is speeding towards the endgame of being able to self replicate, self extend and even arguably evolve.

Well at least in hardware terms. But has it progressed in software terms towards these goals ????

The hardware at the time of writing is arguably able to reproduce with a minimum if not no additional machine tooling.

What about the software.......

Can I pick a machine and with little more than a simple terminal (or simple terminal emulation) hack on the machines software to improve it, replicate it or extend it ?????

The answer is NO. We can't.

Don't get me wrong everything everyone has contributed (and hopefully will continue to contribute) is most excellent. The project to date has been and will continue to be a phenomenal success. The software continues to add functionality at an astounding rate.

In terms of meeting the projects original goals though, great strides and leaps have been made in replicating hardware and non replicating software whilst movement towards the projects primary aims of complete self replication vis a vis software has been static.

A potential route forward is to keep the Hardware & Electronics as is but port the software to an AVR Forth environment, where the firmware is the Compiler, OS and Application.

Another is to upgrade the electronics to an environment that will host it's own development environment through the addition of an OS ie embedding Linux and development tools.

Are there other ways, or do you disagree entirely ????

Edited 2 time(s). Last edit at 01/11/2010 08:34AM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Can I pick a machine and with little more than a simple terminal (or simple terminal emulation) hack on the machines software to improve it, replicate it or extend it ????? [

Nope. But we seem to be doing ok using bog-standard computers, externalizing the compilation away from the dirt cheap electronics.

A potential route forward is to keep the Hardware & Electronics as is but port the software to an AVR Forth environment, where the firmware is the Compiler, OS and Application.

Yup. You'd lose most if not all of the current developers, I'd guess. Without adding any new hardware functionality.

Another is to upgrade the electronics to an environment that will host it's own development environment through the addition of an OS ie embedding Linux and development tools.

This is more sexy. Because everyone needs more linux machines around. How much would this add to the cost of a machine? Do we get onboard ethernet? Ability to run EMC?

Complete self replication vis a vis software has been static.
It's externalized. I use "cp" on my linux system. Again, we're boosting software complexity without adding any new hardware functionality.

I'm more interested in hardware. We could figure out Pick and Place, for example, and extend the self-replication aspect of hardware assembly:
[dev.forums.reprap.org]

Hullo Sebastien, long time no speak, good to talk with you again.

I think I am not suggesting abandoning what we are currently doing, certainly not. I am asking is it worth adding an additional strand that addresses the area we so far have have not.

Certainly maintaining the progress that we have made and continue to make is very important, as you suggest this is best done by continuing to encourage folk to use what ever technology they feel most comfortable/productive with.

From a microcontroler point of view, there are AVR's, PIC,s and I think work coming along on ARM Cortex devices.

If externalizing the hardware was sufficient then the project wouldn't be what it is. Why should we accept less from the software as the entire thing is the sum of both ??

From a replication point of view, we can at the moment theoretically take a machine with an SD card containing it's own hardware design and print off a new one then add electronics and basic vitamins.

But can we stick a cable between parent and child so that the parent can also reproduce it's software on the child ??? Why should even this basic level of reproduction have to be externalized.

Maybe
> I'm more interested in hardware. We could figure out Pick and Place,
> for example, and extend the self-replication aspect of hardware assembly:

Is an indicator of why there is little or no RepRap software for the RepRap hardware.....

Although in fairness I am interested in that as well.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

an avr can flash another avr. an avr can also read its own firmware afaik, but getting it from an SD card probably makes more sense. as far as I know, it may only take a few kilobytes of code to have a "copy my firmware to another avr device" routine... wanna write it?

It gets a bit arbitrary, what we define to be the computer, and what we define to be the controller. Like going to the used computer shop and getting a $50 pentium with a parallel port.
[objects.reprap.org]

Here are some cheap linux appliances.
[www.ewayco.com]

Looking at
[www.linuxfordevices.com]
They don't seem to get a lot cheaper than $100. Note that that is from a cursory search, and if there is a ...?... $30? linux system that's the same size as an arduino board I think we should switch. I'm just generating noise, because in other threads we're talking about grinding another 10% off the build cost.

---

The SD card stuff is useful, and should be brought back under the RepRap umbrella if it's getting written up elsewhere and isn't on the wiki.

---

I'm serious about that pick and place stuff, though. Gene Hacker has a nice write-up that's not on the wiki:
[dev.forums.reprap.org]

Anyone willing to take up stewardship of it, email Gene, and get it into the wiki?

Well on the Linux subject there is of course uClinux and someone was working on an M3 Cortex controller.

On a machine to machine link there is of course the additional UART's on the Sanguino and the Arduino Mega.

From a personal perspective if I was to be setting fingers to keyboard it would be to write a forth based controller. Viral OS replication is a trivial thing in Forth.
Sure it would have a marginal following (perhaps just the person that wrote it) but it would be able to do all that we have discussed above as well as be it's own development system. Just add hot terminal, or OLPC.

Fortunately this isn't about me and I am interested in everyone else's take on concepts, objectives and the direction for software.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I'd also be interested in a FORTH RepRap. If you want to take it further, you might want to look at the amforth source forge page. I believe this could, with an AVR programmer, could replace the Arduino bootloader with a forth interpreter.

I'm here to create a space for you guys, a dedicated forum/mailing list*, etc. and all that, and to dig up the svn keyholder and connect you with him. And you guys know how to use the wiki. "Log in, click edit."

That said, there's a reason why arduino is so popular.

And I don't see most of the ¿tens of thousands? of RepRap user builders eager to learn forth. In fact, I'd guess they would stay away in droves, and would even pay more money to use a microcontroller with a language they know or they can pick up more quickly or use with other software, (popular) cad scripting, (popular) webservers, etc. Myself included, unfortunately. And I'm an emacs user.

This was an interesting skim, regarding the relative popularity of forth and other languages:
[www.odinjobs.com]

Our target RepRap user is a clever 13 year old girl with a RepRap and a web-browser in a megaslum somewhere. Is she going to learn forth, or is she going to learn something like linux, java, python, etc. ?

---

Again, think in terms of adding hardware functionality that our other users want/need. E.g. cnc router, ethernet, SD card reader, LCD panel, laser scanning module and rotary table, etc.

If you guys want a _hard_ problem, there's always generating toolpaths for 3axis+ subtractive machines, building CAD functionality into blender, designing the post mediawiki RepRap.org solution, etc.

---

I'm a little bit more interested in the linux stuff, but I'd like to see a candidate board (and price). And I have too many commitments to contribute meaningfully to such an endeavor until it's up and running. And you'd want to liaise with linuxcnc.org .

---

*mailing list functionality is coming ... soon. ish.

Hi Sebastian,

Have you programmed in FORTH before? I agree it has an oddness with RPN and all, but after that, it's not too bad. Any 'general purpose interpreter based' protocol is going to have one key advantage over the C Arduino environment... interactive playing with stuff.

I also think FORTH is closer to LOGO than C, and that targeted elementry age kids (both girls and boys). Actually, LOGO seems even more ideal a target language on RepRap firmware, with the emphasis in turtle graphics commands. Instead of a pen (the turtle), you have an extruder (the turtle).

In any case, I pointed the amforth site because I suspect you could probably very quickly adapt that if you really wanted to try FORTH now. I believe someone's going to implement a FORTH system compatible with Arduino -- maybe it will be me ;-). From that point, anyone on the REPRAP team could make use of a FORTH based protocol to the firmware rather than GCODE based protocal simply by uploading the FORTH system instead of the standard RepRap firmware. The FORTH subsystem could even make use of much of the code already in the fork by defining primitives that invoke the various commands found there.

Have you programmed in FORTH before?

Nope. I need to learn python first.

In any case, I pointed the amforth site because I suspect you could probably very quickly adapt that if you really wanted to try FORTH now.

Yup. I need to master 1) python, and 2) figurative sculpture in bronze first.
1b) is to take a look at django which is coded in python, and 1c) is to look into python scripting in inkscape and blender.

I believe someone's going to implement a FORTH system compatible with Arduino -- maybe it will be me ;-).

Cool. I'll make a space for you when you want it. I'm not optimistic about folk dogpiling on that project, and I don't see any added hardware functionality coming out of it, however. ("Not being optimistic" is my way of being gentle here - you can have a forum, but I'm 98% sure it's going to be ... lonely in there..)

Here's a machine controller in PureData to control a plotter:
[ratsdeville.typepad.com]
It's by a friend of mine. If he wants to use PureData to control a RepRap, I'll make a space for him too. I don't see the "Official RepRap Developers" going for that, either.

---

Here's something that 13 year old girl might use: pymite

Quote

PyMite is a flyweight Python interpreter written from scratch to execute on 8-bit and larger microcontrollers with resources as limited as 64 KiB of program memory (flash) and 4 KiB of RAM. PyMite supports a subset of the Python 2.5 syntax and can execute a subset of the Python 2.5 bytecodes. PyMite can also be compiled, tested and executed on a desktop computer.

Considering PyMite is designed to run on embedded 8-bit architectures, one should not expect PyMite to do everything Python can do. However, it's capability may surprise you. Since PyMite is written from scratch, it has a few features that set it apart: stackless from the start and fast, easy, native C function support.

[wiki.python.org]
(via a quick google search for Python on Atmel.)

uh huuu.

I can see this degenerating into a discussion of one language versus another.

The actual development language is very much low priority. (I am sure many will disagree and quite rightly defend what they know whilst eschewing that which they don't)

Primary, is can a user that wanted to just pick up a machine (provided for them) with the firmware (written what ever) loaded and use it as a printer that instead of printing on paper prints in 3d. That is the primary audience for a commodity RepRap. What ever the location and circumstances of the user. This is why Ready-Built at sensible price will always out sell kit, kit will always out sell DIY. Most folk are not focused on RepRap they are focused on what it can do for them. THeir end game is what they can make with the machine and for the majority it won't be another machine. In terms of our journey towards satisfying this requirement we are 50-75 percent of the way there. DIY is plentiful, Commercial Kits are here and we are awaiting a mass manufacturer.

Now having said that there are those who have contributed to bringing it thus far and bought into the bigger concept of self replicating and evolving machinery. The device is the sum of it's parts and part of that is it's firmware and enabling a wider audience to develop it further without having to overcome the obstacle of a tool chain.

A quick observation and diversion the firmware can be adapted/ported to language "x" and still present the same interface to the printing host. ie G-Code or it's succesor. The firmware language is and should be irrelevant to the disinterested user that just wants to print.

There are many ways of achieving this, I mentioned forth because I am currently looking at forth on the AVR for a green house controller project. I want to be able to hack my controler, many years down the line when the tool chain that created it's firmware has gone to the code graveyard in the sky, so forth suits me as an embedded operating system and development environment. It is a no brainer for me and I recognize it potentially leaves a lot of folk cold.

We have inadvertently suggested other routes that could be used. Adding embeded interpreted scripting languages. Logo, Python, Basic, etc. What about embeded JAVA, PERL etc. the List goes on.

The points remain:-

We cannot currently develop (firmware) for the RepRap without a host based tool chain. This is bad and contrary to the original goals for the project (But has been necessary to get us thus far, and we will need to continue a while). Neither can we extend what exists without a tool chain. This is an entry obstacle for the disadvantaged developer.

The firmware cannot be evolved without a tool chain (See last point), nor can it be replicated from machine to machine without external assistance and tooling.

There is room in the project for several competing strands all heading towards the same end goal. Survival of the fittest is what it is all about.



Our machinery can not self assemble as yet, but we are working on this. Should we not recognize that we need to be looking at the software through the same goggles as we do the hardware.

OK I'll get of the soap box now, sorry.

Embedded scripting in language-you-like is as valid a way forward as is a complete port of software to a different language base.

On a final note, the most able page printing interfaces have been programming languages in their own right. PostScript, HPGL, PCL, etc etc etc. Most people have used them and never known. The print's are'nt so much described as programmed pages. We are doing similar with Gcode, but we can't as yet extend our Gcode except through further firmware development.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi aka47,

I agree.. whatever the backend, the channel that communicates to the board, it would be nice to implement a fully general purpose scripting language. The commands supported by that scripting language would allow you to set targets for each control, and to execute specific target paths, etc; you wouldn't actually 'program' the firmware; rather, it provides you with scripting capability to do more complex things than "go here", ok, now go "there". It could be "Repeat this 5 times... go there"; The firmware would still provide a layer of abstraction so you didn't have to worry about PID or bit toggling, or timing loops.

It also allows host programs to also defer timing sensitive operations to the firmware, assuming you can document worse case real time behavior from each primitive script command on the firmware.

GCode does not allow scripting, since it doesn't have IF statements, LOOPs, VARIABLES, etc., so I think we agree that it does not address the type of activity you've mentioned (Image having to manually type in the GCode to make a minimug. I can imagine a forth program could be done in < 300 keystrokes... something you could print out and hand to someone else to manually type in on their stand-alone reprap printer.)

I like FORTH (or FORTH-like) as a target, because the hardware requirements to get a complete scripting environment are very minimal (I created a test VM at ~2K program memory, with 6 byte overhead per forth word definition. This system would allow ~25 user defined functions to be created during a session to make your 'program' of head control, even on a microcontroller with only 512 bytes of RAM. I'll publish it when I get a little more time to work on it, and have finished the work on my RepolaRap hardware; since I have to touch the firmware anyway, I might as well try out my idea there, taking as much as I can from current GCode implementation, but tearing out the serial line parser, and replacing it with a forth-like outer loop interpreter.

FORTH also benefits that if you have a beefier processor, you can take it to the next level and actually create compiled scripts, rather than a token based interpreter (Which is effectively what the scripting test I have created so far is). Your ability to achieve specific real time analysis becomes a lot easier if your scripting language actually gets compiled to machine code, rather than being interpreted.

A 'python' scripting protocol front end could also achieve the desire of letting someone work directly with the firmware in the manner described, but I don't imagine you could fit it in a similar memory footprint.

I think you could have something here.

There is certainly some mileage in creating a Sanguino Forth using just plain Sanguino boards.

Perhaps taking an existing AVR Forth implementation as a start point, even if we only strip it back to bare kernel and then implement on a needs basis. A whole bunch of the higher level forth commands are self defined anyway, so are very easy to re add if needed.

I have an AVR ISP programmer here that is an arduino plus sketch, that I use to burn bootloaders etc onto blank Atmega's.

If we were to go the above route I think a first port of call would be to experiment with having the forth kernel replicate itself to a blank Atmega through ISP, followed by sanguino to sanguino conversation. Perhaps because I don't know of a way of getting the Atmega to boot from something external by other means.

So long as there is a basic kernel with block capabilities the rest can be read/written in from an attached SD card. Code if needed as well as data, should needs exceed the capacity of the internal flash.

With a minimal kernel up it is almost trivial to self program the remainder of the internal flash on the fly anyway.

Moving on to perhaps low level coding of the routines for driving hardware.

From my point of view given other interests this is perhaps worth trying and wouldn't be a waste of effort, even if the development vis a vis reprap didn't get any further.

Certainly a microcontroler that self replicated firmware and was it's own development environment is worth a bunch in and of it's own right.

What do you think ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Certainly a microcontroller that self replicated firmware and was it's own development environment is worth a bunch in and of it's own right.

What do you think ??

I'm orders of magnitude more interested in a beefy chip with lots of memory that engages the hobbyist community the way arduino does. RepRap gets a huge return on invested interest there. There's a reason that stuff is crazy popular.

I also think that there's room under the RepRap umbrella for FORTH geeks and general hackery on the stuff you guys want to work on. Hell, on my todo list is to track down the woman who did up the Bath Salts recipe on Instructables before Instructables took off its mask and corporatized its public space in a standard CDDB-move.

Sebastien

Are you by chance sugesting the Arduino Mega or do you have another processor/controler in mind ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

S an aside, the old Commodore 64 had a very usable Forth o/s available.
Having played with it, I would suggest, going by the rest of the RepRap information available , that Forth not be promoted. With Forth, the documentation is so important for any one to work on it later on, even the original writer needs it.
Forth is about the only langauge that almost needs no encryption or copyright- just leave out the documentation and comments!

Forth would be a great language for the job otherwise though.

LOL I take your point.

It is pretty much the same with any programming job though pick, a language and you need source to be able to work on it, most folk struggle to read machine code (Other than machines that is).

What makes the mark of good open source, source, is detailed and sufficiently commented source code, such that it is it's own documentation.

This is something that is commonly lacking on most source you will ever be troubled to read. Open Source or not.

I think this stems from the fact that the commenting is a summary of what is in the programmers head. The onlooker doesn't have the benefit of that and finds what he/she reads to be like a string vest. It has the shape of a vest if you know where to look, it clearly is a vest, but is full of holes.

C code can be as readable or as obscure as the programmer cares to make it. C is the current language of choice for Sanguino based Rep Rap development. (although you might call C with a bunch of predefined libraries , wiring or some such).

Personally as a C programmer I am a big fan of C. If it could be embedded in, and be as efficient as Forth (size, speed, extensibility, capability) for this app I would rather go that way.

There is even an argument in favor of embedded tokenized basic. Ug shudder...... If you solely look at it from a readability point of view.

<|

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Sebastien

Are you by chance sugesting the Arduino Mega or do you have another processor/controler in mind ??

Necessity hopefully becomes the absentee parent of successfully invented children.

I think it's good to engage one of the hobbyist communities. Sanguino was done up by Zach for RRRF, so we may want to go with that. And c, well, there's a lot of arduino code used by modern motor, sensor, and electronics hackers, than something arguably technically superior like Forth that's nearly completely disengaged from the RepRap community.

---

We might want to start thinking about the next RepRap controller, hardware and software, like a sanguino-esque board with onboard ethernet, or so on.

I'm slightly vexed at Zach for not folding Sanguino into RepRap.org and into this forum when he did it up, wearing his RRRF cap, so I'm thinking about how to bring sanguino back under the RepRap umbrella, where the forum community can hack on it, and into our wiki, where it should have been all along.

---

As a complete derail, I think the community could use a GPL 3,4 axis CNC mill/router controller, put out by the reprap community.

Those are pretty straightfoward to do up initially: control is by bit-banging the parallel port.

This immediately engages the EMC/Mach3 crowd. Especially if the interested folk who do it up make a good set of electronics, (eventually) comparable to the Gecko stepper controllers.

It's compatible with RepRap, and it engages a community. I don't see how Forth really engages a hobbyist community that overlaps with RepRap.

Edited 2 time(s). Last edit at 01/21/2010 06:31AM by SebastienBailard.

Sir Sebastien of Bailard

There is indeed a huge argument in favor of moving towards a standard Arduino Mega and developing next gen electronics around this. Even perhaps to the point of arranging the connection's between the motion driver electronics (the EMC compatible bits you mention) as a pair of pin compatible parallel ports.

The extruder assembly is an interesting issue, Is it better to implement the motor control as if a 4th axis ie EMC style or leave it as is........ In purely CNC terms the 4th axis is as of a spindle control (But these are rarely steppers, as is currently popular)

Your existing code and development direction will of course transplant quite quickly and cleanly to this platform with very little modification being required.

The arduino IDE is still use-able with this too.

A note on CNC, the Gecko boards etc are actually drivers, the host pc is the controller. In our case the Arduino/Sanguino/Mega/Forrests-PIC is the controller. Hence the mention above of an interconnect using cheap connectors that are compatible with the other projects. You can make up a set of drivers using the original separate boards (the designs are still out there) that are drivable from EMC as their interface is step/dir.

As I am back in full time employment I currently have a Gecko fund that is slowly accumulating.

Ethernet is perhaps easier than most folk think these days. It being a question of which module to plug onto the board and use the serial interface (perhaps instead of a plug on RS232 level converter or plug on USB/serial converter). I hate the idea of being stuck with only one choice for host/machine interface. Arguably putting all three on simultaneously though is overkill and waste. So modular looks to be a good option

My initial concerns around the Mega were basically ones of price. In the UK the majority of suppliers are offering these at more than twice the price of the arduino. However I found an importer offering them at around £20+ UKP and traced back the boards to their Japanese source ( [www.dfrobot.com] ) where if my math is correct they look to be about £2+UKP. Much better for the slum scenario than I had originally thought. There are a couple on order from the UK as importing from Japan is expensive and problematic. Hopefully they shouldn't take too long to get here.

On Zach, I don't think Zach has done the project any harm, yes he has shot off at something of a tangent and has other priorities. Don't we all. I would say makerbot etc has brought the project along and made some very useful contributions. Not to mention a great deal of publicity. Zach now has commercial y successful products and change therefore ceases to be beneficial, it now becomes a threat to revenue. If it was'nt Makerbot or Repman that branched off and made a bid for commercial mainstream then it would have been someone else. At least all of Zachs product stayed Open Source even if not under the RepRap banner.

Yup I get cheesed off too with the glory hounding and lack of full recognition that commercial folk are prone to. At the end of the day for me it is not about money (who's presence or lack of, is a perpetual source of annoyance) otherwise I wouldn't still be here.

Getting enough of a stable core to be able to evolve from was always going to be a tough gig. (it is easier to evolve something and arguably impossible to evolve nothing) We have this now and must make the best of it by evolving it further.

There is a very real danger at the moment that RepRap will become eclipsed and seen to be solely as the precursor of Makerbot, Repman or commercial-machine-u-like. That is unless I feel we stick to what we are good at (research and tinkering) and our original goals and continue to evolve towards the primary objective of machinery that is as capable of self replication as we can make it. Both Hardware and Firmware.

Having said all of the above I feel it becomes clear branching is all to the good if we are prepared to cherry pick those branches for what benefits the main stem of the project. (Does a bee care ?? Much less the flower.)

Sorry for the long waffle.

Yup I agree Arduino Mega is good and currently looks to be next best bet for next gen. There are other contenders though....

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I hear you. But if I were developing something like that, I'd do it up at RepRap.org and not fork the community. Perhaps I shouldn't have brought it up, this can get into a rather long contentious derail, and is best discussed elsewhere:
[dev.forums.reprap.org]
I do wish we were hosting the 'official' sanguino mailing list, as we've got ~500 entries to move to one forum which is going to get mailing-listified.

End of derail, unless people want to argue with someone inflexible who doesn't look forward to copying the popular and current extruders off of thingiverse onto reprap when they should have been there all along.

---

So, you're thinking Arduino Mega? What are the other contenders?

---

If you look at the artsy-fartsy people or hardheaded machine builders, they really won't care about forth. They'll be utterly hostile, rather, like a room full of secretaries who just had their keyboards switched to dvorak because it's better.

They're happy editing c on their PCs and flashing compiled code over the same as they edit their cad drawings on PCs.

It means oodles of man hours making something philosophically purer, but it doesn't result in more machines being made, and alienates users.

---

I think there are some good research topics out there. Like a solid EMC-driven electronics set. Or a RepRap servo controller.

I think we are pretty much agreed on most of that.

1. Yes I agree further development is best done at RepRap under the RepRap umbrella 100%. That it hasn't been is awkward and may be there are valuable lessons to learn here. A strong and valid point. I also agree it is best discussed elsewhere as it is arguably off topic.

2. In terms of merging that branch back into the main stream in real terms. For me the discussion can stay where it is. We could kick of new discussion here about where we go to next, drawing on the open source that is common to both routes. Using the Arduino Mega as machine controller. This is arguably the quickest and shortest route to achieve this. (a debate on this is probably again arguably off topic and needs to be elsewhere)

3. The bulk of RepRap contributors will probably carry on the way of 2 for the very reasons you mentioned. I don;t know I do't have crystal balls. <\

4. As you already suggested there is plenty of room under the RepRap umbrella for other parallel threads of research. Each pursued by those most up for it. It is unlikely that folk will donate their time & matériel to something they are not up for. One of these threads is perhaps a forth firmware on the Arduino Mega Machine controller (And I agree is best done under reprap.org). Another is perhaps the host PC as machine controller (again best in same place).

What I am also going to agree on is that if those parallel threads were pursued as a non-popular option to the exclusion of a more popular thread, then of course the project would fail sooner or later for lack of support. Key word exclusion.

What I will disagree with is the idea that pursuing parallel areas of research in any way detracts from the viability of the most popular. It contradicts 4 if nothing else.

If anything I have drifted into keeping a bunch of my work on my own Blog because I was under the impression that some of the parallel/divergent routes I was interested in would not be entirely welcome/fit under reprap.org.

A. Adapting existing CNC hardware to dual purpose, RepStrap/CNC Milling Router.

B. Use of machine tools to make components (ie a lathe). This one may become less contentious as folk turn out lathe designs that can be printed.

C. An articulated arm based RepRap Machine.

D. Dual purpose RepRap machinery (additive & subtractive).

Quite truthfully as well I was a touch chewed off with commercial offshoot's using what had been freely given, failing to give due credit and representing themselves as RepRap. (Again off topic, and best debated else where, I apologies)

while I am in whinge mode,

----- snip here to delete whinge ---------

It would have been great to encourage wider involvement and turn out some more of the group contributed papers that were produced in RepRaps early days.

It does very much feel these days like RepRap has become a design for free agency, in support of those on the make, rather than a project to research and build the ultimate self reproducing machinery.

If people can't contribute original ideas and effort towards the projects stated goals I fail to see why they should contribute at all.

Where the product of the project ......

OK enough whinge, its pi****g me off being pi***d off.

-------------------------------------------

Ultimately I am up for some Arduino Mega application, with EMC style interfacing if that would help (and because my CNC machine that I need to be EMC compatible can make use of it). I will probably experiment with forth and porting the firmware to it (if it is of interest to the project I am more than happy to do it here, but will have a play anyway, and any work contributed towards those going the C route will not preclude this).

And sin of sins will maintain an interest in servo controlled machinery over stepper controlled machinery.

Any other heresy I can think of is probably going to be off topic.

Lathe, lathe, lathe, machine tools, servo motors.... Yipeee.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Sorry for that, lost it. But does it feel good to get it of your chest.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Why must one choose one or the other?

---

CODE !
short addr = fetch( sp[0] );
short value = fetch( sp[1] );
sp += 2;
store( addr, value );
END-CODE

VARIABLE X

CODE G00 ( x y z -- )
// forth uses fixed point math for coordinates; C++ firmware expects floats.
forth_target.x = sp[2] * 0.01f;
forth_target.y = sp[1] * 0.01f;
forth_target.z = sp[0] * 0.01f;
sp += 3;
forth_cartesion_dda.set_target( forth_target );
END-CODE

---

This looks an awful lot like C++, and in fact, looks an awful lot like it uses Dr. Adrian Boyers implementation of DDA. That's because much of it *IS* C++ and it *IS* using his implementation of DDA. I'll send this thru a preprocessor, load it up in sketch, compile it, and upload it to the microcontroller.

My own effort to try and get a quick and dirty forth engine with low enough overhead that I can include it in parallel with the standard firmware, perhaps replacing the existing serial parser, or perhaps adding a prefix that sends the remaining characters on a line to the forth engine instead of the standard parsing code, for example: F ." hello world"

Now I can start up a simple console app to the serial port for the firmware, and start typing:

G00 X100 Y100 Z300
( I watch the head move to the position, when finished, I see "OK " displayed )

( let's see forth do the same thing)
F 100 100 300 G00

What is the advantage? Well, I can now write 'code' and immediately get feedback as to whether it works, for example, implementing my spline algorithm on one axis:

F : NEXTCUBIC ( x px qx rx -- x_t+1 px_t+1 qx_t+1 rx_t+1 )
F >R R@ + ( qx += rx )
F >R R@ + ( px += qx )
F >R R@ + ( x += px )
F R> R> R>
F ;

Note that I'm connecting directly to the board now. I'm not running this thru a preprocessor or a compiler or anything on the host side.. just a simple terminal program. I don't need an IDE to test out simple ideas:

F 0 1 2 3 NEXTCUBIC
( 1 3 5 3 ) OK ( note: this is output from the board, not me typing )

NEXTCUBIC
( 4 8 8 3 ) OK

NEXTCUBIC
( 12 16 11 3 ) OK

NEXTCUBIC
( 28 27 14 3 ) OK

ABORT
( ) OK

: TEST
20 0 DO
XCUBIC@ NEXTCUBIC XCUBIC!
XCUBIC.X Y @ Z @ EXTRUDER @ G00
LOOP ;

0 1 2 3 XCUBIC!
TEST

( head accellerates along X then stops... )

XCUBIC@
( 4389 609 59 3 ) OK

In any case, I hope that illustrates why I would like this.. I want a very quick turnaround time for 'play time development' for simple operations and testing and playing with different ideas on the firmware.

Now, it may actually be that I could have done this same thing by front-ending the current firmware with a forth intepreter running on the host. It does mean that there may be real time problems when I need immediate feedback in one of my script tests:

: TEST
100 0 DO
I @ 0 0 G00 \ advance x position 1 step at a time...
100 USEC-DELAY \ every .1 milliseconds
LOOP
;

Forth can be cryptic, low level, and hard to understand, but is also an ideal environment for this rapid "try it out and see" programming methodology.

Also, as long as you have enough memory, or the overhead is small, this is an "add on", not a replacement for current firmware.

Yup that is one of the benefits.

Umm I have been looking at amforth and it lets you inline machine code. Using a Code statement. Which means that a bunch of the already written stuff could be intercepted as a listing and cut/pasted into forth. If you wanted quick turn around and use of existing code.

I reality though Forth's re use of code as it is a threaded language makes for a more compact code size for a given app. C is great but not as good at code reuse.

I could be wrong but I get the impression Sebastien isn't really focused on the benefits forth brings. More on whether introducing Forth usage as a parallel development strand will drive away existing developers. Can't see it myself as the forth would be parallel. However they were implemented. A developer could choose which way they wanted to go based on what they felt most comfortable or challenged by.

As already indicated there is mileage in pillaging some of the C codebase as machine code.

It would be interesting to see how big amforth actually is on the Mega. amforth suggested figures of 2k in their docs, but I think it may be on the order of 8k somehow. Still rather trivial and as you suggest could be in addition.

I think it is 16 bit too.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

[hackaday.com]

I found this too; at first glance, it looks to also provide the interactive environment I think would be useful for hacking with ideas on an arduino without the overhead of starting up the edit/compile/upload/execute cycle: Bitlash Online

Both of those look cool.

I wonder what the execution times are like and if they support ISR's......

14k is a little steep compared to forth, but there again if implemented on an arduino mega there is plenty of memory.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

In summary then:-

Situation:-

1. Current firmware has no way to replicate the software machine to machine. without the use of a host based development tool-chain.

2. Current firmware cannot be evolved, enhanced, fixed or in any way tweaked without the use of a host based development tool-chain.

3. Forward movement to wards the Projects goals arguably requires that 1 & 2 be tackled and solutions found.

4. Convenience and trial + error development strategies are more readily facilitated where 1 & 2 are tackled and solutions found.


Options:-

N.B. The below takes as a given that compatibility with host/machine print interfacing will be maintained. ie the firmware may be enhanced in some way but will remain able to take print instruction from the host without requiring corresponding modification to the host print softwares.

A. Do nothing and abandon the projects original goals, particularly if this rocks the consensus boat.

B. Implement a part fix by adding machine to machine duplication of firmware (no host intervention) to the existing firmwares capabilities and forget about 2,3 & 4. This route has merits (see comment at A. re connsensus) and arguably has covered the minimum requirment for evolution free, self replication.

C. Implement a hybrid solution, extend existing firmware to include some form of on machine, extend-able preprocessor and or scripting language, perhaps create the capability for machine to machine under this enhanced capability. On device memory and speed of execution may impose restrictions on this route, unless optimizations to the firmware (currently underway) claw back sufficient memory and machine cycles.

D. Implement a purist solution, port the existing firmware at a functional and algorithmic level to an on machine environment that features self definition, extensibility, speed, economical memory usage and actively supports on machine evolution and machine to machine reproduction.


Potentially viable solutions discussed so far by letter with comments :-

A, A perfectly valid view point worthy of consideration. Are the projects original goals still valid/appropriate?? Is the project still on track ?? Do we care ??

B, Perhaps a solution based around the sort of code that features in the AVRISP sketch, but bolted into the firmware to clone it to another of the same processor.

C, Extend existing firmware with front end, pre-processor or a scripting language yet to be clearly identified. Potential candidates Forth, BitLash.

D, Potential candidates, BitLash, amForth, avrforth.


OK I think I have summarized discussion so far, feel free to correct me where wrong. There is I feel more to be explored here.....

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi aka47,

Looks like a pretty good summary. Do you think hardware considerations should be considered? Some microcontrollers (not sure if AVR is one of them) allow a direct examination of flash and on board persistent memory, without any need of firmware/software. One could adapt such a device into a solution for 'B' without any software changes at all.

So far I have purposely dodged the hardware question as much as possible.

The reasoning goes thus:-

* This is a firmware thread

* To prescribe a firmware too tightly in the hardware direction inevitably ends up favoring one architecture or another, this arguably splits the pack more than it is already and makes it less likely we will get any useful direction out of the discussion. It is possible to have a coherent direction and specified interfaces that enable a number of firmware and hardware solutions.

* At some point we may have to but should reasonably put this off as long as possible.

Arguably specifying amForth, BitLash or AVRForth presupposes the hardware will be AVR/Arduino. The ARM Cortex and PIC micro are equably viable and enjoy some degree of support form project members.

Equally specifying a high level language (with low level capabilities) like Forth leaves it open to have firmware in Forth that is portable to many platforms, as in deed does 'C'.

Although specifying C does inevitably tie you into the write/compile/download/run that we are discussing avoiding.

---

Necessity hopefully becomes the absentee parent of successfully invented children.