bahstrike wrote:Zarni I agree- I think as the community expands, more people are going to be looking to add peripherals that they would like to control via common interface (gcode, naturally).
I²C would be a prime candidate to allow commands&data to cross from PC through printer to any number* of slave devices. If so-inclined, SD could capitalize on this idea by just soldering in a jack to the I²C pins and modifying firmware to support a custom gcode command to send data to node ID, and another gcode command to receive data from a node ID. This would allow designers to share or sell all sorts of custom sensors and/or drivers that anyone can just plug-in (as if it were a USB device). Fantastic!
* standard I²C is limited to 128 device addresses. you probably wouldn't connect 128 peripherals to your printer, but designers would have to be cautious not to reuse the same address someone else did- otherwise you couldn't attach both even if they were the only 2 peripherals you wanted to use
there's a good side and a bad side to the idea that you treat printer parts as peripherals and give them addresses...
to start with, so long as you agree an addressing scheme, then you don't really have an issue with things having the same address. (split the 128 addresses up into device classes, (e.g. actuators, limit devices, cooling devices, temperature sensing devices etc))
eventually your imagination takes you to a place where everything is just plugging into a machine.
so when your machine turns on it does a basic systems test and goes to a discovery mode, and you have parts that reply with information.
for example on a standard solidoodle, you'd get replies from xyz and e motors. xyz end stops, perhaps they'd be more clever and have a learned idea of how big the axis etc were...
so when a printer turns on it knows it has 3 axis, 150mm long and a single colour print head.
(like how when my PC turns on it knows it's got a 3 button scroll mouse connected, or if I put a different mouse on (say 5 button) then new functions are opened up)
When you stick an SD card in your panelolu that's 180mm square in two colours, the printer can just tell you that it can't print that.
basically, if you start hanging things off a proper bus and putting addressable devices in like they were peripherals then the possibilities are pretty endless.
In addition, if you were going to use a 1 wire bi-directional bus.
it's make sense that whilst you were throwing away all the conventional printer wisdom that you also threw away the conventional controller boards and made one with a CAN bus.
The reason for this is that this bus rather than being master/slave oriented is multi-master with a way of giving preference to devices based on address that aids conflict resolution.
so (for example) in your car,
You may use stalk controls to increase the stereo volume.
if your car wants to tell you that the brakes are faulty then the brakes win because they are addressed lower.
To put that in a printer setting, control messages from the panelolu, saying that you want to increase/decrease speed would outrank (and be given preference to) messages regarding cooling.
But the trouble is, when you start sticking Uc's into everything you suddenly increase the cost.
As for this being the future of 3d printing.
Personally, I think that the ease brought by embedding chips in everything, and adding loads of user easy. (so just add or takeaway a fan etc) far outweighs the few pence spend on doing it.
However as free as the Rep-Rap movement (that most commercial makers are taking their direction from) goes, Adrian Bowman said that he did not like the idea of adding chips to everything. and given that RepRap (as a brand) is controlled by him, it seems unlikely that any standard could ever be endorsed...