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 ???? https://reprap.org/forum/read.php?147,32542,32542#msg-32542 Mon, 15 Jun 2026 00:16:54 -0400 Phorum 5.2.23 https://reprap.org/forum/read.php?147,32542,46364#msg-46364 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,46364#msg-46364
On self replicating firmware the guys over on the amforth project are currently having a think about the task of cloning running forth systems to blank devices/boards.

Cheers

Andy Kirby (aka47)]]> aka47 Firmware - experimental, borrowed, and future Mon, 24 May 2010 14:49:28 -0400 https://reprap.org/forum/read.php?147,32542,45418#msg-45418 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,45418#msg-45418
[forums.reprap.org]

Cheers

aka47]]> aka47 Firmware - experimental, borrowed, and future Thu, 13 May 2010 12:38:44 -0400 https://reprap.org/forum/read.php?147,32542,45340#msg-45340 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,45340#msg-45340
I have just been having a rummage through the latest release of amforth.

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

168, Diecimila
644, Sanguino

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

All in all the guys over there have made some outstanding changes and they are part of the core distribution. Most excellent.]]> aka47 Firmware - experimental, borrowed, and future Wed, 12 May 2010 10:36:09 -0400 https://reprap.org/forum/read.php?147,32542,42539#msg-42539 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42539#msg-42539 aka47 Firmware - experimental, borrowed, and future Tue, 13 Apr 2010 14:45:56 -0400 https://reprap.org/forum/read.php?147,32542,42497#msg-42497 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42497#msg-42497
This may be just the sort of interpreter that is not seen as to complex for the entry level user.

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

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

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


-julie]]> sheep Firmware - experimental, borrowed, and future Mon, 12 Apr 2010 23:06:29 -0400 https://reprap.org/forum/read.php?147,32542,42463#msg-42463 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42463#msg-42463
I would be looking most carefully at going the embeded RT Linux route. (Forth doable still, but as perhaps gforth)

The ARM is arguably overkill unless some of that greater potential is put to use.]]> aka47 Firmware - experimental, borrowed, and future Mon, 12 Apr 2010 15:09:38 -0400 https://reprap.org/forum/read.php?147,32542,42461#msg-42461 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42461#msg-42461
The Forth closes to our needs (as is) is amforth.

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

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

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

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

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

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

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

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

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

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

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

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

This is my take on the situation for what it is worth, what do you guys think ??]]> aka47 Firmware - experimental, borrowed, and future Mon, 12 Apr 2010 15:06:24 -0400 https://reprap.org/forum/read.php?147,32542,42442#msg-42442 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42442#msg-42442 > of course the next question on this would be is
> there a forth interpreter that could be installed
> on a mega board as is or would it have to be
> started from scratch?

[amforth.sourceforge.net]]]> BeagleFury Firmware - experimental, borrowed, and future Mon, 12 Apr 2010 10:50:39 -0400 https://reprap.org/forum/read.php?147,32542,42392#msg-42392 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42392#msg-42392
on the other hand, from a testing and trouble shooting standpoint. interpreted environments do make doing so easier and forth would be a excelent choice for doing so. It was designed for small form factor and very fast run time.

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

if scratch then probably not worth the effort but that is just my opinion. though i have been considering purchasing a arm board to test some ideas with.]]> RBisping Firmware - experimental, borrowed, and future Sun, 11 Apr 2010 16:18:53 -0400 https://reprap.org/forum/read.php?147,32542,42391#msg-42391 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,42391#msg-42391 RBisping Firmware - experimental, borrowed, and future Sun, 11 Apr 2010 16:11:18 -0400 https://reprap.org/forum/read.php?147,32542,35027#msg-35027 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,35027#msg-35027
I have spent too much time being annoyed with folk that insist I bodge in software what should have been fixed in the hardware. Consequently limiting the software and producing questionable data.

aka47]]> aka47 Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 16:28:12 -0500 https://reprap.org/forum/read.php?147,32542,35011#msg-35011 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,35011#msg-35011
I always look for the simplest solution that achieves the desired result. I would wager that I have the least firmware and software in my system but the results are as good as anybodies. I also try to fix problems in the process at source rather than bodging round them with more software, i.e. I refine my extruder to get good results rather than relying on lots of clever stuff in Skeinforge,

Things like polar and tripod machines will trade some mechanical complexity for software, which can be good thing to bring cost down.]]> nophead Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 14:33:54 -0500 https://reprap.org/forum/read.php?147,32542,35007#msg-35007 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,35007#msg-35007 aka47 Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 14:11:46 -0500 https://reprap.org/forum/read.php?147,32542,35006#msg-35006 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,35006#msg-35006
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.]]> BeagleFury Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 13:56:25 -0500 https://reprap.org/forum/read.php?147,32542,34996#msg-34996 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34996#msg-34996
"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]]> aka47 Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 12:56:31 -0500 https://reprap.org/forum/read.php?147,32542,34982#msg-34982 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34982#msg-34982 nophead Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 11:15:38 -0500 https://reprap.org/forum/read.php?147,32542,34970#msg-34970 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34970#msg-34970
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.]]> aka47 Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 06:57:26 -0500 https://reprap.org/forum/read.php?147,32542,34966#msg-34966 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34966#msg-34966
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.]]> nophead Firmware - experimental, borrowed, and future Thu, 04 Feb 2010 05:24:17 -0500 https://reprap.org/forum/read.php?147,32542,34925#msg-34925 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34925#msg-34925
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]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 19:12:17 -0500 https://reprap.org/forum/read.php?147,32542,34912#msg-34912 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34912#msg-34912 > 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'.]]> BeagleFury Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 16:26:52 -0500 https://reprap.org/forum/read.php?147,32542,34908#msg-34908 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34908#msg-34908
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]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 16:11:57 -0500 https://reprap.org/forum/read.php?147,32542,34890#msg-34890 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34890#msg-34890
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.]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 14:11:55 -0500 https://reprap.org/forum/read.php?147,32542,34886#msg-34886 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34886#msg-34886
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]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 14:01:59 -0500 https://reprap.org/forum/read.php?147,32542,34883#msg-34883 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34883#msg-34883 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 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 13:48:09 -0500 https://reprap.org/forum/read.php?147,32542,34875#msg-34875 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34875#msg-34875
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]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 12:06:11 -0500 https://reprap.org/forum/read.php?147,32542,34868#msg-34868 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34868#msg-34868
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.]]> anton Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 11:27:08 -0500 https://reprap.org/forum/read.php?147,32542,34862#msg-34862 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34862#msg-34862
"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]]> aka47 Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 10:20:27 -0500 https://reprap.org/forum/read.php?147,32542,34831#msg-34831 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34831#msg-34831
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]]> anton Firmware - experimental, borrowed, and future Wed, 03 Feb 2010 06:24:08 -0500 https://reprap.org/forum/read.php?147,32542,34707#msg-34707 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34707#msg-34707
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.]]> aka47 Firmware - experimental, borrowed, and future Mon, 01 Feb 2010 18:48:29 -0500 https://reprap.org/forum/read.php?147,32542,34704#msg-34704 Re: RepRap Software for RepRap Hardware https://reprap.org/forum/read.php?147,32542,34704#msg-34704 Triffid_Hunter Firmware - experimental, borrowed, and future Mon, 01 Feb 2010 18:30:22 -0500