RepRap Software for RepRap Hardware

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

False. The EMC RepStraps do this on ~$50USD linux boxes (or used netbooks with usb->parallel, maybe) from the used computer store. Linux on chip could work as well, with a candidate chip.

Then, instead of writing code on your laptop, compiling it, and loading it onto a controller, you could ssh in from your laptop into the controller, write the code, compile it, and run it. Or hook up a keyboard and monitor to your controller.

There are several orders of magnitude more linux enthusiasts than forth enthusiasts out there.

Also, define "host".

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

False, due to 1.

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

What is the motivation of the Project, as this is achieved with EMC on linux?

...

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

You will not hurt Adrian's feeling by doing forth on chip. Also, I have not seen a 'consensus' since I joined this project.

... He will meanwhile be working on pick-and-place stuffing of boards, RepRap self=assembly and more compelling to him self-replication of hardware.

Q. What is the merit in using a tight, small language like Forth on a small memory chip, rather than spending more on the chip and using a language that engages the current geek community?

Q. What is the overall vision of this project - once a forth-based microcontroller for RepRap exists, why will the greater community use it?

Q. We currently generate our models via CAD/modeling, or scans, with a generic personal computer. Why is it foolish to compile our controller code on computer and then load it onto 128 newborn Mendels using Ethernet, or an SD card?

Q. Have you tested and evaluated the merits of EMC or Nophead's python stuff?

---

Q. In view of Moore's law, faster and cheaper chips coming out, etc. Why do we want to go in this direction, and what is the benefit in doing so?

Q. Also, even people living in 3rd world megaslums have cell phones, presumably with bluetooth. How do we engage this community?


Q.Is forth or another 'exotic' going to see massive uptake in new RepRap user-developers, based on current trends in the geek community and in computer education?

---

Quote

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

Q. Why do you expect prospective users, familiar with internet browsers, text editors, to desire to do their development (improve it, replicate it or extend it) in a different space from their 'host'?

Major Question: Also, what is this simple terminal running on? Presumably that machine can also host a compiler?

Thinking about this one still further there is perhaps an argument that at the moment we are actually at A and should perhaps work our way to D in steps through B & C.

On programmability, there is always the chicken and egg question, some platforms are incapable of booting from an external source unless they have a bootloader installed. AVR is a particular case in point. AVR's must be programmed all at once or with a bootloader through ISP. Other platforms may use JTAG.

Given that each platform has differences, it could be enough to say that each platform should be able to program a derivative of its own kind and that the method to program the child firmware may be through an interface that at other times has another purpose entirely (When not being used to replicate the firmware the pins used for ISP may actualy be driving an extruder or display or something). ie it doesn't have to be dedicated solely to the task of programming a child, just sufficient to achieve it.

Of course on devices where there are interfaces going spare, why not have a number of pins dedicated to replication and at other times machine to machine communication. There is certainly a case for being able to daisy chain a number of machines together to make multiples objects or copies of objects concurrently. Again without an actual host to drive them.

You could for example have an SD card in one machine, daisy chain on 4 more machines together and make 5 more machines from the designs on the one SD card. (or at least the parts for 5 more).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hurro sebastien

Some interesting and good points, well worth debating.

I ROFL at the observation we often struggle for any kind of consensus, it is very true.

One of the biggest consensus's we currently have is that the machine controller is arduino/avr based and the firmware runs in/on it, not on the host.

I think we need to tackle point 1. Our differing view points I think stem from our individual perspectives of what firmware is and where it resides.

I will break of at this point and put together a drawing that compares and contrasts the very real differences it will help I think.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

SebastienBailard Wrote:

> Q. What is the merit in using a tight, small
> language like Forth on a small memory chip, rather
> than spending more on the chip and using a
> language that engages the current geek community?

Cost. Availability. Easier hardware construction (solder vs SMD). More hardware targets -- possibility of using a (smaller) FGPA devices to implement a forth stack in addition to direct hardware programming (vs. software -- speed 10x 100x that of machine code -- perhaps you've heard of the MuP21, a 100Mip chip from 1994 that runs on a few microwatts of power?). Lots of other "forth on a chip" hardware devices available for possible evaluation or replacement.

And did you just make an implication that using forth would disengage the geek community? If you use forth, you deserve at least two extra stars on your geek badge.

> Q. What is the overall vision of this project -
> once a forth-based microcontroller for RepRap
> exists, why will the greater community use it?

I'm not sure about others, but my vision consists of having a hardware platform that I can more easily try stuff out on. Having to launch a compiler / dev environment and go thru 50 or 60 code iterations just to try variations on a theme seems ridiculous to me. Of course, there appears existing interactive firmware programs that one could leverage or use.

> Q. We currently generate our models via
> CAD/modeling, or scans, with a generic personal
> computer. Why is it foolish to compile our
> controller code on computer and then load it onto
> 128 newborn Mendels using Ethernet, or an SD
> card?

Because there exist other means to generate modeling information without an existing host. Creating a minimug is just a few lines in forth, depending on how much you have already (I.E, the ability to print a disk, and a circle, and it's one line: ": MINIMUG DUP PRINT DISK 100 0 BEGIN NEXT-LAYER DUP CIRCLE LOOP DROP ;"


> Q. Have you tested and evaluated the merits of EMC
> or Nophead's python stuff?

I don't think one must be satisfied with only one or two solutions in an open source community. I believe EMC and Nophead's stuff have lots of merit. One of the big selling points to UNIX included having LOTS of little tools that could be hooked up together in complex forms using a standard notion (pipe.) It would be interesting to see what one could achieve in firmware with a similar approach, perhaps connecting several processors together that communicated using a turing complete protocol (so they can go about trying to solve the halting problem. ;-) )


> Q. In view of Moore's law, faster and cheaper
> chips coming out, etc. Why do we want to go in
> this direction, and what is the benefit in doing
> so?

Because it's fun. Because it adds additional flexability. Because it opens new doors for areas that maybe people haven't thought of before. Etc. Etc.


> Q. Also, even people living in 3rd world megaslums
> have cell phones, presumably with bluetooth. How
> do we engage this community?

Add a bluetooth forth console.


> Q.Is forth or another 'exotic' going to see
> massive uptake in new RepRap user-developers,
> based on current trends in the geek community and
> in computer education?

I wouldn't call forth that exotic. It's not like the turing tarpit languages (now those, I can see as just being mental stimulation without any real benefit! Oops, I probably just offended some Iota and Jot programmer with that claim.... okay, for you guys, you can write 11111000110111000 line to print your minimug.


> Q. Why do you expect prospective users, familiar
> with internet browsers, text editors, to desire
> to do their development (improve it, replicate it
> or extend it) in a different space from their
> 'host'?

Well, you do realize that forth is extensible. So extensible, that usually people don't really write forth in a cross compiler... they write the 10-30 words they need and start writing forth in forth once they have those 30 words working. With extensibility, you could easily provide a very powerful "out of box" algorithmic printing functions for use by humans or drivers, for example:

( turtle graphics type commands )
0.5 MM EXTRUSION-THREAD AT 212 CELCIUS TEMP
35 MM FORWARD PRINT
90 DEGREES TURN RIGHT
35 MM FORWARD PRINT

or

( CSG type primitives )
10 MM RADIUS 5 MM TALL CYLINDER

or

( Complex algorithmic primitives )
40 MM MINIMUG (where minimug is a algorithmic encoding of a mini mug)
40 MM 20 TOOTH-PINION-GEAR

If you had a forth environment, it could be extended to automatically include these and other 'forth' commands. A Forth based reprap could replicate these commands along with the base machine, assuming the target has a flash card on it with a few meg of available space.

Not everything requires a computer generated STL file.

Of course, there could be limitations and complexity hurdles that would discourage taking it too far. I'm interested to see how far that might be though.

> Major Question: Also, what is this simple terminal
> running on? Presumably that machine can also host
> a compiler?

Anything that can transmit ASCII to the serial port of your reprap. Most likely in my world, from a computer. But could also be a MuP21 device which connects to a RF capable TV and a keyboard. Heck, could even be another automated chip that was just sending slave commands from another microcontroller component part in your system (Who says only people get to write forth?).

And did you just make an implication that using forth would disengage the geek community? If you use forth, you deserve at least two extra stars on your geek badge.

That's my point, there's not a lot of badges out there with two stars on them.

Take a hard look at hobby electronics and contemporary, past-3-years pedagogy and practice before deciding what language and technology to use, in order to understand the community you'll be working in and among.

But you guys are welcome. I'm trying to rope in Robo-One for similar reasons, only I think bipedal robots are ... slightly cooler than forth. (I have to get those two stars somehow.)

It could be your mobile phone with a terminal program on it (java app).

It could be a legacy vt100 terminal you found propping up rubbish in a skip or broom cupboard.

It could be ET with a hacked Speak and spell.

It could be makeshift terminal made with an arduino, lcd display and an old PC keyboard.

It could be a modem plugged into a mobile phone, sat phone, phone line or radio device and someone who does have a host or Internet connection has downloaded the code for a water filter to your relief operation.

It could be houston ground control uploading the design for a personal CO2 filter to the printer in your shuttle craft, so you can print one out per person and asve them from a slow death from CO2 poisoning due to Life Support Failure. (Actualy they did this with a plastice bag, tape and a cardboard box)

Consider one of the original goals was to have a RepRap machine that could printout 3d Objects and be run from a car battery. If the machine comes with feedstock and an SD card library of life saver objects why would you waste the electricity on running up a PC.

But I'm sure you get the picture/s

The point is to lower the bar for entry.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The point is to lower the bar for entry.

Then it is hard to go lower than bit bang the parallel port like EMC does. Especially if you use the whitebox PC's power supply to also drive your RepRap.

The point is to lower the bar for entry.

When we code in a language, we externalize a cost to other users who don't grok that language to hack our stuff. Learning is work.

---

Also, we should assume "host" contains a web browser for stls and CAD/modeling program for the user.

In all reality Sebastien.

Exactly how many folk have really contributed directly to the firmware as it currently stands??

Exactly how many in numbers have access to and contribute to the source in the repository for the firmware as it currently stands.

I would guess at an upper bound that does'nt reach much into double figures if at all.

This is such a number because the bar to access is too high.

To work on the current firmware you have to have a host capable of running the tool-chain for the source as it is written and a tool-chain. You must know how to work the OS, install and work the Tool-chain, Programming language and the target environment. How much more expensive (costing it on your terms) do you want it to be.

Comparatively, to work on an embedded firmware that is it's own development environment all you need is a terminal. Both to work on the firmware and as pointed out earlier to use that firmware to describe an object and print it directly if that is what a user wanted to do.

Cheap by comparison working on your own basis for costing.

Quote
"Also, we should assume "host" contains a web browser for stls and CAD/modeling program for the user."

No we should not. we should assume a host is capable of supporting nothing more than a terminal. That should be the lowest point of entry. Everything else is a bonus.

A potentially needy user should be able to drive the machinery, from a Sinclair spectrum, a BBC B, a Vic20, A psion organiser from absolutely anything they can get there hands on and use as a terminal.

We should be giving a kid (trawling the dumps of waste electronics tipped in his/her slum for gold recovery) the potential to recycle as little of that waste as possible to create for themselves a RepStrap.

With correct firmware the minimum entry level would be that low. A host that couldn't even connect to the INTERNET much less load a tool-chain should be able to run the machinery.

If you are in any doubt as to whether extensible firmware is a viable model, take a look at the printer sat next to you at your desk.

It's not a new idea.

Consider a PostScript printer. With a terminal I can write code on a post script printer that describes a page and tell it to print it. Using nothing more than a terminal that can interface to the printer. (If you are in any doubt open up a Post Script print file with a text editor, the language is stack based) If you haven't got a post script printer run up a ghost script session.

Equally I can attach the same printer to a main frame super host with an interconnect to the fastest hub of the worlds Internet. Craft a page using DTP-package-you-like, import photo's apply a corporate color scheme and print a page.

It is the same printer...... It is not defined by the host that prints it is defined by it's ability to print.

In our case also to what degree it can reproduce itself.

The hosting does not and should not determine the peripheral devices capability.

particularly if the projects aim is to make a device that is as capable of self replication as we can get it to be.

That is a not insubstantial point.

Where the the 3d printer is unable to function without being attached to a host then that host is an added cost, an increase in the entry level requirement for use. The more capable that host must be to get the printer to deliver then the higher is the cost. QED

If that self reproducing printer needs that host to reproduce itself then this must be added to the cost also. QED

Here in the western world we take the presence of high specification PC's for granted and project that onto those without. Ignoring the fact that we have made the entry level too high for them because it is trivial to us.

This is what alternative Technology and Appropriate Technology is all about.

We are already using the hardware, the electronics are already done, the firmware is just left to upgrade.

Again there is plenty of room within the project to support a number of routes to the projects goals.

As already pointed out, we are not suggesting that the ability to use clever CAD CAM is withdrawn or that working without clever CAD CAM is something you need to know to be able to use the device. Merely that at the moment clever CAD CAM and toolchains is all that it can work with. And whilst this remains the case self replication is prevented.

You can't take a low end inkjet printer and do with it the things we mentioned above for a Post script printer. The difference is the firmware.

If you believe that the ultimate device is purely host based and that the machine should be as dumb as possible. Using whatever you like as host based controller software (that is software btw, not firmware). Then I think you should vote with your feet and do it. EMC is great and ready to go. The stepper driver boards from RRRF are compatible with a parallel port based EMC interface. A firmware free RepRap lurks just over the horizon. This is a perfectly valid route.

On a final point, if we are talking firmware free we are perhaps in the wrong topic. I guess this particular thread within the topic should be called "RepRap Firmware for RepRap Hardware" it would cause a touch less confusion.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

OK

Piccys as promised, see attached.

Replaced the file, the transparent background made it hard to see what was going on.

Edited 1 time(s). Last edit at 01/26/2010 08:04PM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

A little off topic, but perhaps serves as further justification for enhanced firmware.

The Kartik M. Gada Prize lists these desirable attributes.

* Print at least three different materials, including one that is usefully electrically conductive.
* The ability to print electronic circuit boards.
* Print beds† must be of a material which may be reused with minimal refurbishment for at least 20 print cycles.
* Maintain a total materials and parts cost under $200 and that 90% of the volume of the printer parts be printed. ††
* Demonstrate a build volume of the printer above 300x300x100mm in order to insure that items daily utility can be printed.
* The capacity to print a full set of parts for a complete replica of itself within 10 days unattended save for clearing no more than one printer head jam.
* The ability to print autonomously without a PC attached.
* Uses no more than 60 watts of electrical power.


Of which the last three just jumped out......

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I have been reading these forums for close to a year now. Slowly collecting what parts I need. Learning what is current and what is likely to change.

The following comment piqued my interest as I worked at apple in the 1990s. Specifically with the postscript printers I coded the startup diagnostic page in addition to writing other tests.


Forgive me if I am wrong, but it seems that the suggestion here is for the end user to do the equivalent of building the postscript firmware from the source.


Even with the inclusion of Ghostscript, this argument is weak in relation to the accessibility of the toolchain. I speak from experience as I struggled with installing Ghostscript on Mac OS 7 in the early 1990s due to incompatibles in the library systems of the different operating systems.

At least now most things are built on GCC. Even so there are issues with library revisions, which change faster than the code can be developed.

The other weak point to using the postscript printer analogy is this is a closed system. Even at apple we had no way to build the postscript core. This was licensed and controlled by the vendor. A process that took a team of over 20 people working 40 to 60 hours a week

Do we really expect most users to work to this level of expertise?

Even I with 30 years of experience, writing firmware, have taken a year to even start to understand what is needed.

Are we asking too much too soon?

-julie

Quote
aka47

Consider a PostScript printer. With a terminal I can write code on a post script printer that describes a page and tell it to print it. Using nothing more than a terminal that can interface to the printer. (If you are in any doubt open up a Post Script print file with a text editor, the language is stack based) If you haven't got a post script printer run up a ghost script session.

Equally I can attach the same printer to a main frame super host with an interconnect to the fastest hub of the worlds Internet. Craft a page using DTP-package-you-like, import photo's apply a corporate color scheme and print a page.

It is the same printer...... It is not defined by the host that prints it is defined by it's ability to print.

Julie

The suggestion here certainly is not that everyone must develop the firmware.

There are those that write and develop solutions and those that use them. Sometimes they are the same but mostly the users outnumber the developers by several orders of magnitude.

As pointed out (reference to the wizzy mainframe and software) there is no requirement whatsoever to be able to write postscript code to be a be able to drive a postscript printer. You would use an app that generates the relevant code and instruct the printer to print. The fact that the firmware has that added functionality gives a would be hacker the capability to go further if they wish. (sometimes to the befit of the user community)

The point I am making, which I believe to be strong, is that with better firmware comes better solutions. This part of the forum is about developing just that. Other parts of the forum are for folk that want to just load and use it.

The comparison of a reduced firmware printer (HP Windows based Inkjet, where the host does all the work and the printer is useless without the host, particularly windows) and the firmware enhanced Postscript printer. Illustrates that point.

We are building printers that print with plastic in 3d as opposed to 2d inks on papers. The analogies and lessons learned re printer portability (use ability on other operating systems etc) are directly transferable here.

Apple made very good use of the WYSIWIG functionality of Adobe's postscript. As has Sun, IBM, Microsoft etc etc etc.....

Your average windows, host driven, printer can not match that. Much less operate on their own without a host.

If in acheiving the above we can also provide an extensible development environment that is equaly portable across hosts/equipment and operating systems is this not just as desirable.

Users want an end solution that they can use whenever, where ever and attached to whatever, even stand alone. They quite rightly don't care how it got that way, so long as it works. When it doesn't work they want to tell someone about it in the hope that it will get fixed.

There is clearly an argument therefore that to make a solution as widely available as described, that we must also make the development environment as just as widely applicable. The more accessible it is to developers, where ever in the world and with whatever tools they have to hand the more likely that they will evolve the design to give their fellow users what they need.

A prime objective of this project is to make the machinery as capable of self reproduction as possible, this should not exclude the firmware.

I should be able to hand you a memory device of some sort that is compatible with your machinery and you should be able to create most of another machine without needing a Host PC. You should also be able to make the control electronics yourself (or assemble a controller from commodity parts and a small amount of DIY)and then replicate the firmware to your own controller without needing to know how the firmware works. You should then be able to do what you want with the printer, use it with a host of your choosing (Not my choosing, yours), or hack on it if you want.

If you want to hack into the firmware and modify it for whatever reason you should d equally be able to achieve this with access to little more than a terminal at minimum or perhaps a fully fledged host and tool-chain at best. The choice should be yours as the owner of the machine.

At the moment your option is fully fledged host (on a finite number of OS's) and tool-chain or nothing. Printing from a Host or nothing.

Hope this explain a little better.

Edited 1 time(s). Last edit at 01/30/2010 06:03PM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote
aka47 Wrote:
> At the moment your option is fully fledged host
> (on a finite number of OS's) and tool-chain or
> nothing. Printing from a Host or nothing.

I wrote a long reply to this, which I decided needed to be a separate thread. That addressed some of the technical aspects, but there was no room for some of the social implications I have seen discussed in this thread.

For the most part I agree, that the tool chain is the frustrating part. I became interested in rep-rap a little over a year ago.

Most of my surplus computers, which would make good control boxes are older apple systems. The more recent of which can run BSD.

It took me several months to get the existing Java Host to run on the Mac. With the limitation that it would only run inside the IDE and not as stand alone Java App due to library compatibility.

In practice the current use of rep-rap software systems requires Linux or a hands on mentality. Where makefiles and perl scripts are the whole of the world. That chasing through code version databases are practical things to do.

Personally I find it easier, to download a package like AVR studio and write my own firmware code in assembly. No linker required.

This also seems to appeal to the Arduino enthusist. No linker needed.

What I think, the elephant in the room that we can not see, is that there is no real practical way to create development environments that use older or unpopular hardware platforms.

Much of the work seems to be targeted to keeping up with the state of art as far as the tool chains are used.

This seems to contradict the notion of recycle-re-use, as well as empowering those who do not have access to the normal technical distribution channels.

My impression, was that these projects what encompass the reprap philosophy are bootstrap devices. Something that could be built with older or limited resources.

I have at least 5 older Apple laptops, two of which are capable of running recent, but not the latest versions of Apple's unix.

Technically the older 68k processors can run Linux. Some of these machines collect dust. One can not give them away.

What if, there was a way to implement the reprap firmware on such a machine? These are the equivalent of a simple embedded 32 bit processor. They even have keyboards and screens. Granted this is a fully fledged host, but then so is a postscript printer.

Older linux distributions exist for obsolete 68k and x86 processors, so there is a place to start. Such machines have SCSI ports which can be bit banged or the simple two wire interface known as appletalk which is a socketed protocol.

Apple maintains the legacy pages which show how to access this older hardware. 10s of thousands of developer CDs have been issued which float around as coasters. Library book sales and surplus charity stores. full of How to program OS7x6 which they can not even give away.

The same can be said for older intel x86 laptops. These even have parallel ports which can be bit banged.

We speak of cannibalizing printers for stepper motors and other vitamins, why can a few open source programmers not cannibalize older systems to make something that the impoverished can use? Is this not the benefit of helping others to make due with what they have to become "successfully inventive children?"

Granted this means taking time, to locate older tool chains and library systems. I am being abstract here and not thinking of anyone directly in these forums. Simply put are we designing hardware that can run in the third world or the impoverished neighborhoods of the industrial countries? Or are we designing hardware that will be the next big product that will allow us to make a fortune and make trips to the sunny parts of these said countries and slums, to enjoy our luck?


Am I too much an optimist to think that, those with means could help those in countries or neighborhoods where obsolete equipment is dumped that some of the members of this august collection of intelligent people could spend time creating software for making useful devices out of obsolescence?


-julie

see EMC2 reprap related stuff- as far as I've read, EMC2 runs on linux on an old x86 and bit-bangs the parallel port to talk to the stepper controllers

Julie

The fact we are having these conversations here, in this way, hardly makes you out to be an optimist amongst the disinterested.

The main differences are how we preceive being able to best acheive it. Whatever the vintage of the controling host it is still very much a controling "host".

Where the software (not fimrware) is running on a host it is not firmware. It is control software or even drivers, but not firmware.

Firmware is embeded, drivers and controling software are not.

The machinery must have firmware of some degree or other to function. More able fimrware equals less host dependancy, less able firmware equals more host dependancy. The social argument does'nt change this

The firmware in a host is the bit that folk refer to also as bios, or the bit built into the hard drive that lets the hosts access it through scsi, P-ATA and S-ATA and WD protocols. It is also the bit that resides in the roms in the graphics card (subsystem).

On shipping legacy kit to the far away, there are two routes to this, one is the folk at far away are as sugested collecting what they can out of what has been dumped. The second is that it is transported to them with the disks et all to have a go.

In the first case the chances of any of this kit working are slim to nothing, purely becasue of the way it was transported. But it can be scavenged for parts. (I did a lot of this as a child skip rat, so I could practice electronics, being form a very poor background). Having located a legacy system that might work how are they going to power it ??

In the second case they still need to power it.

If your power source is a junk car alternator, turned from a broken bicycle, that charges a worn out car battery. Would you want to cycle that bike for the extra hours that would be neccesary to run that power hungry legacy kit, even if you could magicaly modify it to run from 12 volts. If you already needed to ride that bike for however many hours it takes to make enough electricity to print the parts for your water filter. Would you realy want to cycle it those extra hours (legacy kit is very power hungry) to run a host that arguably could have been done without but for the wont of a bit more effrot with the firmware that the machine had to have anyway to do anything.......

Alternativly your power might be a jury rigged AC hook up with voltage levels and power cleanlines thet would worry a kettle, never mind IT Kit. When your Power supply browns out (which it does every time someone turns anything on in an adjoining hovel) due to the poor state of supply, how many folk it goes to and the disaster grade wiring and distribution, what happens to current running state of the software in that legacy kit that is adding power drain on top of the machinery. What happens to software on any IT kit when power is interupted.

One host however used for creating printable designs may be doable for a comunity to support. If and only if the machines that the comunity will use to print parts can print without the aid of the host. The comunity host (maybe an OLPC, less power hungry and resistant to interuptions and brown out's, that the kids have been educated to use) would be used to collect, create or modify designs downloadable to several machines that would be of value to the comunity each able to print on a lower power budget.

Inapropriate charity can be very expensive, particularly for the recipient.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Interesting debate, but I feel that it is lacking somewhat due to missing definitions,

What is meant by "self replicating"?
What is meant by "host"?
What is meant by "controller"?
What is meant by "driver"?
What is meant by "Tool chain"?

Depending on how I define those terms, either everything is already in place, or nothing is in place.

Do we want the Reprap to be 100% self-replicating, including producing silicon chips, and the plastics, used to build the Reprap?

Lets take the postscript printer sub-topic as an example, now-a-days hardly anybody buys printers with a post-script interpreter embedded, the primary cause is cost, it is a lot cheaper to have the "host" translate from postscript to some lower level representation, and send that over the wire to the hardware box.

The Reprapper - like it or not - also exists in an environment constrained by costs, maybe even more so than quite a few other projects.

Insisting on doing everything in a closed environment, re-inventing the wheel, increases the cost; both in development time, and in time needed to be spend persuading newcomers to spend their time learning this new set of tools.

I simply do not see why this all has to go into the firmware, executing on the 3-4-5D axis controllers.


There is a ton of good code available for controlling 3-4-5D axis robots out there, using tool-sets those developers know and understand. Why recreate that in some arbitrary language? what would the benefits be compared to the cost?

There is a ton of good code written for IDE's written in all sorts of languages, Java, C/C++, C#, again, why re-invent the wheel?

You can continue the list from above, for almost every part and aspect of the Reprap project, getting the arduino environment up and running took 15 minutes, on my Ubuntu 9.10, 64 bit, even though the arduino tools are compiled for 32 bit environments. This was only possible because somebody already had solved the issue, and published a solution for it on the internet.

And don't forget the option of including OLTPC, as a potential component.

Ok .. enough rambling...

What I suggest is the following:
1) A low level firmware layer, controlling the 3-4-5D axis and reading various sensors.
2) A mid level xxxxware layer, dealing with G-CODE, NEXT, LOGO, Lego Mindstorm, and stuff
3) A high level software layer, dealing with 3D CAD/CAM

The answers to much of those questions are covered by the answer to one of them...

"Do we want the Reprap to be 100% self-replicating, including producing silicon chips, and the plastics, used to build the Reprap?"

The projects primary objective is to get as close to this ideal (but it may not use silicone) as is physically possible. I accept that to fully achieve this we need technology that we have'nt got yet. Some we are currently developing as we go and some we will have to wait for. Ultimately we may not even fully achieve this goal to the stated definition. In the mean time we are so far away from it and there is so much we can do I will worry about the last bits later and do what I can now.

Sometimes you don't know what technology/tools you have'nt got or need until you try and do something that needs them. The trick is to have a go and be sufficiently open minded so as to learn/discover as you go.


The space programs are particular good examples, pursuing apparently unreachable goals, like putting folk on the moon has arguably produced more of value than actually achieving the goal of putting someone on the moon.

If the attitude of NASA/CNSA/ESA/ROSCOSMOS/Who-ever had been that the goal is unreachable/pointless, we can get close enough by flying a commercial airliner through the upper atmosphere. How much technological benefit/advance would we as a race have made. None. Much less actually achieved the goal.

Think of this project as being like SETI@Home using peoples heads & hands to create self replicating machinery and you have the idea.

If you are just along for the ride because you want a cheap 3d printer, leave here, go buy a kit, don't waste your time any more.


BTW if this does'nt help with answers, look back in this thread there is a nice diagram that explains


On Postscript, My printer is post script, It was expensive and it has printed from more OS's over the years than I care to mention, some of which I had to compile from source but are now mainstream. Whatever state of development the OS was. Or whichever I used I could print because the printer did it's own thing and did'nt rely on the host having clever hardware aware software drivers.

The primary reason for the expense of postscript is punitive licensing fees, this is why I contribute as much as I do to opensource and why this project is open source it removes/reduces the commercial bar to entry and advancement.

Commerce is very much a double edged sword, it can be an enabler and promote cost effective advance, it is also used via monopoly to prevent advance and screw every last penny out of those that don't have it. (the "it's worth as much as I can screw someone for" mind set)

If you stumble over postscript as a case in point, substitute another functionally advanced firmware, try PCL, HPGL the principles are what matters. The printers are out there don't take my word for it have a look.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote
aka47
Think of this project as being like SETI@Home using peoples heads & hands to create self replicating machinery and you have the idea.

If you are just along for the ride because you want a cheap 3d printer, leave here, go buy a kit, don't waste your time any more.

Perhaps there is room for a middle ground, having both a 3d printer and make it do novel things in ways I find interesting and pleasing, in the spirit of openness.

In my experience with open source programs, it is almost - if not completely - impossible to control the direction it takes once it is in the wild. It is simply not possible to lead the participants in a direction they do not want to take, they will either leave or create a fork.

To stay in the terminology of your metaphors, I feel that quite a few suggestions made take the NASA approach of getting to the moon rather than taking the ROSCOSMOS approach.

My 0.02€ input, was a suggestion to try an leverage the technology which already exists, and focus on the new stuff that needs to be done, rather than spending time reinventing things. E.g. writing a forth compiler/interpreter for the firmware, and then rewrite the firmware, including libraries for RS232/Ethernet/I2C/CAN etc. in forth.

With all due respect, and if I sound frustrated, that is because I am.

This is a thread to discuss firmware. On an Open Source project whose purpose is to experiment with building self replicating machinery.

Get over it.

Too much typing is being wasted here disusing things that are arguably off topic and re affirming where we are and what we a re doing...... Whilst struggling with folk who are struggling to understand what firmware is, where it lives and what it does. (It is not up for redefinition because you fancy it, it's an engineering thing)

I am all for explaining and helping folk along, after passing over the same ground for the third time though, my patience is pretty much exhausted.

Please if you don't know what firmware is, where it lives and what it does, look at the diagram already posted in this thread or read one of the previous iterations. (I don't expect you to have my experience as an embedded systems developer/engineer, just look at the diagram it tells you all you need to know)

Again for probably the forth time (pun definitely intended) the language of choice is irrelevant. (See previous iterations) Pick one you like I really don't care.

The points remain as to what the project is about, and how the current iteration of firmware (it can be written in mongolian for all I care) falls short of the projects ultimate objective.

If you like it how it is, great don't waste your time typing here, go and fork/get a copy from the repository and be happy.

If you want it to be less capable, ie dumbed down to the point where it could be implemented solely in hardware and become firmware free, great go and discuss this in a non firmware thread.

If you think we can develop it further in line with the projects goals stay and type a while we may accidentally make some progress.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@aka47
Let's agree to disagree, especially in terms of goals and means to achieve these goals. I do admire your faith and strength of conviction (no irony or sarcasm intended, I sincerely mean it)

I intend to introduce the changes to the instruction stream being executed on my reprap mainboard I believe will further my interests, and definitely encourage you to do the same.

Anton.

Thanks non taken, I fully agree. I apologize if sometimes frustration gets the better of me. I would like to stay fairly on topic, and discuss further enhancement to the firmware.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Ok

No more hinting.

Here's a thread within the firmware topic to debate doing away with or reducing the functionality of firmware in favor of host based software and drivers.

[dev.forums.reprap.org]

If this is your thing please use it.

It has been done to death here and is arguably not on the topic I posted.

I'll even drop by and help you achieve it.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Ok

On topic, where were we.....

Ah yes, firmware. and adding functionality.

Other than Firmware replication and on machine development, is there anything else that additionally would be advantageous to a self contained machine that we need to consider ??

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
> Other than Firmware replication and on machine
> development, is there anything else that
> additionally would be advantageous to a self
> contained machine that we need to consider ??

Plug and play extensibility, where the new device you just plugged in contains the code logic needed, which it transmits to the firmware motherboard when you plug it in. E.G, you plug in the new ceramic extruder you just bought to your RepRap; it inserts the firmware it needs to drive itself onto the motherboard controller. The host / programmer can now access that feature via whatever standard interface was used for driving multi-head extruders, even if the firmware logic to drive that head from the motherboard point of view differs drastically from what the original firmware standard used.

The alternative host centric "firmware light" solution to this would be to add a firmware patch on the host side, and update the board firmware.

Both solutions run into problems with competing and incompatible 'patches'.

Actually that is a very good point (or set of points)

Consider Nopheads model of RS485 buss to run the extruder.

This would be a very good start point.

What if you wanted to add a second or third head (maybe they hot swap as the need arises during fabrication) Perhaps interchangeable heads.

The electrical IO is easy because it is power plus RS485 Bus. What about the firmware, much less the software.

In real terms the software should be unaware of what the firm/hard ware is doing, only that it is achieving/has achieved the build objectives.

So following on from your thoughts, when the head swaps the firmware should be either :-

A. Be already able to drive it and swap over seamlessly. (although it may have already have had a run through the available tool-heads at job start and loaded descriptors from them)

B. Be able to download the necessary firmware extensions and then proceed to use it as if already embedded (even though it wasn't really).

I can certainly see a lot of mileage in this. In C++ terms the newer firmware elements might "overload" the existing symbols such that the firmware continues unaware.

In forth terms the dictionary is extended and over writen with new words that replace the old words.

In either case we would need to mark where we were before over-write, such that we could roll-back or reload the previous definitions and resume with the previous tool.

Maybe we ditch the additions and each tool-head loads/extends the definitions in a separate area that is lost as soon as the tool head changes.

Hmmmmm I can certainly see a lot of mileage in the method, how might we do it in practice.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I can add another extruder controller without changing any firmware, other than the address in the second controller, which could be set by a resistor, or links.

My firmware on the main board knows nothing about the extruder except how to reset it and how to forward messages from the host and return replies.

When I add a new command, say to drive a second fan from the extruder, all I do is add a one line Python function to the extruder class in the host and a couple of lines to a case statement in the extruder firmware. It really is that simple, no need for C++ and overloaded functions. The micro I used in my first extruder controller only had 2K of memory which is 1000 instructions, so only a few hundred lines of C.

---

[www.hydraraptor.blogspot.com]

This is because you are running reduced firmware and are reliant on a host.

Both models that this discussion is finding solutions for moving away from.

The Humanitarian prize is pretty specific about the requirement for the machinery to be able to print without a host. I personally feel this is a step in the right direction.

Whilst at this moment in time I am not interested in competing for this award, people who are, are clearly looking at the same needs we are discussing here and can draw some benefit.

Parrallel interests.

There is currently some discussion on reduced firmware EMC2 controlled machinery elsewhere.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

My host simply sends commands, it does not act on information coming back. Those commands could be put on an SD card to make hydraraptor autonomous. To do that I would replace the UDP/IP stack with an SD card reader, a similar amount of firmware.

---

[www.hydraraptor.blogspot.com]

Nophead

"My host simply sends commands, it does not act on information coming back. Those commands could be put on an SD card to make hydraraptor autonomous. To do that I would replace the UDP/IP stack with an SD card reader, a similar amount of firmware."

I could be mistaken but this looks suspiciously like your earlier claims of disinterest were a ploy, and that you are arguing against your earlier arguments and in favor of increased firmware.

Grin

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I don't think he was proposing anything other than replacing the 1000 bytes of program code used to drive serial IO, with 1000 bytes bytes of program code to read flash card memory.

Feel free to correct me if I am wrong, but that doesn't sound like adding firmware intelligence, more like removing an existing component and replacing it with a functionally identical one.