Project Status update

[Robert Teeter]

Is it possible to get a project status at this time 11-8-2012.  I may have some input that may help and was just wondering if this is an active project or not.  Most of the links to cubespawn for docs and such do not work.

Bob Teeter

[Data Pathway]

Hi Bob,

I am still plugging away and making slow progress on the 3d printer module

https://docs.google.com/document/d/1oxsmxsyRIiYMfeiawg2I4oFX-9JwC7R0fRF6l9Z3OsE/edit

the 3 axis mill cube was essentially finished, but I'd like to re-work it into a module

the web site is transitioned to Drupal, much polishing needs to be done though...

the big problem is funding (of course) I am moving things slowly forward, but as I am currently laid off, it has been slow going...as I am currently preoccupied with keeping things going day to day. 

;-)

I'm curious what you have in mind...

James

[Samuel Rose]

Hi there!

Which pathway as described in
https://docs.google.com/document/d/1CAqTxHAiApWXbX5uCFgMz3FIzij7E9zJ3BaVlI5zygM/edit
is the most developed? Smoothie? Beagle Bone? Raspberry Pi?

--
--
Sam Rose
Hollymead Capital Partners, LLC
Cel: +1-(517)-974-6451
email: samue...@gmail.com
http://hollymeadcapital.com
http://p2pfoundation.net
http://socialmediaclassroom.com

"The universe is not required to be in perfect harmony with human
ambition." - Carl Sagan

[Leo Dearden]

I've been running an Ultimaker (stock UM electronics), controlled by a headless RPi for the last while. 

It works well, and requires no extra dev (neither hardware nor software) to make it go. Stock firmware. Stock Printrun pronsole.py, screen, ssh, job done.

The UM electronics are basically RAMPS with a slightly different layout and header selection. The only bit that might be importantly different is that they may include a thermocouple driver, but I think that's on a separate board.

I'd advocate Linux board -> Arduino -> drive electronics -> machine, so that you don't have to do RT Linux.

--
Leo

--

RepRapKit.com

[John Griessen]

On 11/08/2012 04:07 PM, Samuel Rose wrote:
> Which pathway as described in
> https://docs.google.com/document/d/1CAqTxHAiApWXbX5uCFgMz3FIzij7E9zJ3BaVlI5zygM/edit
> is the most developed? Smoothie?

I looked at Smoothie, where the developer is porting to a STM32 board that is cheap, but he uses
a Mac and no help cross compiling the code from another platform that I use, debian linux.
So that needs more time and effort still. http://davesblog.com/ is about the STM32 port.

Quicker is just to talk withthe smoothie developers about their NXP based smoothieboard
and how that is going: #smoothieware at irc.freenode.net

[Data Pathway]

well, the electronics side of things on my bench is beagle board-->grbl on arduino--> no motor board at present but I have just hooked it up and don't rule out any other approach - mainly because I cannot cover all the hardware out there - I had 2 R-Pi's on order a while back - but my order got re-queued, then canceled so no pi for me at present...

[James]

Leo,

do you know where one can buy just the UM electronics? I tried a while back - to no avail - and I thought it was RAMPS with slightly higher current per coil drivers - I do have some easyboard 4.3(?)'s lying around and I SHOULD be able to run the same stuff on the beagle as on the RPi.... not a final solution, but it oughta make the carriage move...

Also, I ordered one of these a couple months ago - it came in last week

http://www.qu-bd.com/   (thier dual extruder) -you can set it up as a single , too.

:-)

[John Griessen]

On 11/08/2012 04:52 PM, Data Pathway wrote:
> well, the electronics side of things on my bench is beagle board-->grbl on arduino--> no motor board at present but I have just
> hooked it up and don't rule out any other approach

http://tom-itx.dyndns.org:81/~tom-itx/irc/logs/%23reprap/2012-10-05.html

is log of chatting about smoothie a few days ago.

https://github.com/sorinescu/Smoothie/tree/edge
is where some interesting work is going on, even with a STMF103, a very low cost Cortex M3 chip.

It wuld take the place of arduino in above scheme.

John

[Data Pathway]

I tried to setup the hardware on github using the 

http://garyhodgson.com/reprap/2012/09/githubiverse-a-github-pages-template-for-3d-printing-projects/

Templates - but it did not come together in the first session - seemed like a good way to get the hardware repo going... kind of a micro thingaverse for CubeSpawn, but I have to learn more about GitHub before I can decipher the instructions...

[John Griessen]

On 11/08/2012 06:33 PM, Data Pathway wrote:
> a micro thingaverse for CubeSpawn, but I have to learn more about GitHub before I can decipher the instructions...
>

Basing docs and plans on git serving like github is good. It makes it possible for others to contrib easily,
while not allowing defacing of sites like wikis are prone to.

[Leo Dearden]

As far as I can tell without stripping things down, the UM electronics use the same stepper driver boards as RAMPS: Pololu style. That would imply exactly the same current capacity as RAMPS.

I don't know where you can buy UM electronics by themselves. If I needed to, I'd just use a RAMPS or RAMBo: I believe that they're both slightly superior, by the current carrying capacity and therefore heated bed support, if nothing else.

--
Leo

--

RepRapKit.com

[Data Pathway]

Hi Sam!

As I recall, you have a lot of GIT repo experience - but correct me if I'm wrong...

would you be inclined to discover/research how the hardware template works?

I don't THINK its very difficult - on the one hand...

On the other - I did not get it to work either :-) so that may simply be another ASSumption on my part...

from the other replies, you can gather that I have a beagle+grbl on arduino, although I'm very interested in a smoothie, too since this addresses the entire system from an Ethernet interface to low level logic for less than $150

I'll eventually get around to either asking for more guidance from the group, or winging up a carrier board that'll accomodate the pi+smoothie, beagle+smoothie and perhaps the arduino+grbl solution as well on a single backplane since the backplane will probably manage less than 50 signals irrespective of the configuration for a 4-axis or 3-axis-with-one-dual-drive configuration - the future looks modular!!

hope things are going good

James 

[Robert Teeter]

James - I can recommend a variation of what you are doing that should hold up just as well and end up being a lot cheaper and simpler.  Here are some projects that I have been involved in that when combined will do the same thing.

MakerSlide - now sold at Inventables  https://www.inventables.com/technologies/makerslide
   all the parts that go with MakerSlide - https://www.inventables.com/categories/innovative-materials/components/mechanical/makerslide

ShapeOko - Now sold at Inventables  https://www.inventables.com/technologies/cnc-mill-kits-shapeoko
   Project support site - http://www.shapeoko.com/
   A full kit is about $600.00 for a complete CNC milling machine  - Hobbyist level.  But complete with electronics.

Software is GRBL Arduino - grblshield - NEMA17 motors

Job dispatch software - botqueue  - written by Zach Smith (Hoeken)  Makerbot founder 
   http://www.hoektronics.com/  - info is at the bottom of the page.   https://www.botqueue.com/

This is atleast a start on making this work.

Bob Teeter

[Robert Teeter]

Also I have these items in stock and will be building up the system based upon using these parts.

Bob Teeter

[John Griessen]

On 11/09/2012 01:28 PM, Robert Teeter wrote:
"> should hold up just as well"

Thanks for sharing, but... James is aiming at metal carving milling machine with ability
to drive horsepower into metal cutting. That usually involves
slow to 10's of RPMs, not router speeds and light touch.

[Bruce Wattendorf]

James, 

Email me I have a spare Ultimaker board.

bwatt...@gmail.com

Also I love you project and am thinking about working on a mill. 

Bruce Wattendorf 

[Robert Teeter]

I agree that is what I will be setting up based up the general structure of the different projects.  A heavy duty metal fabrication line.  One of the things that I want it to do is to make some of the aluminum parts for creating the cubes.  Using a heavy duty spindle and motor assembly.

Also look at this site as Bart is doing some interesting work with variations of MakerSlide such as a plasma cutter, a laser cutter, a 3d printer.

http://www.buildlog.net/forum/viewtopic.php?f=16&t=1296

Bob Teeter

[Cube Spawn]

yep I have been on buildlog's forums for 8 or 9 months...

 I initially looked there for the laser, but I think this modular framework can absorb all kinds of open source designs - and I don't expect that I could do it all myself, even if I wanted to.

So lets (all the interested parties) take a common, shared framework (CubeSpawn, hint, hint) and implement different machines in that framework - while trying to develop enough of a standard for inter-operability so that control software can command any design - then we can benefit from each others brilliance, without sacrificing much of anything...:-)

 --I'm not an attention whore BTW - so take credit for anything you add loudly and long, if thats what your into, I'm into the network of manufacturing machines, not the glory of having created them - this project needs lots of participants to make it real, and I don't expect to be anything but a peer in the process, like the rest of you - so lets all coordinate and get some machines together.

by the way - I'd be happy to make parts for anyone thats willing to make an earnest effort at a design - just coordinate with me on the materials and I'll ship you the parts.

-James

[Joshua D. Johnson]

James,

       I've been following your efforts from a distance for a while. Can you comment on if and how a single "cube" might initially be used as both a CNC router/mill and and as 3D printer? I'm writing an article for a british industry e-rag. I like the concept and would like to help with development where possible., most likely on the assembly and testing side.

Best,

JOSH

[Cube Spawn]

Well thats an idea I have toyed with for a loooong time and the answer - (as I'm sure you'll have noted) is that it could easily be done by fabricating interchangeable heads and allowing enough space at the top of the mill to feed filament in and handle it - the downside is that the motion control for a mill focuses on precision and power at the expense of speed (usually - super VMC's being excluded - O'Course) but I have worked out some of the details for a spindle changing cube adjacent to the mill cube - again, making a modular head with a power and signal connector is the same problem as the power and data connections between cubes - and if you can stand the slow printing you'd get with ballscrew drives - there is no reason not to do it - of course a second solution is to transition from the one Cube system to a dedicated, more optimized 3d printer cube - but the clunkier solution would lend it self to starting with one cube and bootstrapping to multiple cubes...

-James

[Samuel Rose]

On Fri, Nov 9, 2012 at 5:43 AM, Data Pathway <data.p...@gmail.com> wrote:
> Hi Sam!
> As I recall, you have a lot of GIT repo experience - but correct me if I'm
> wrong...
>

Indeed, I do

> would you be inclined to discover/research how the hardware template works?
>

Yes.

> I don't THINK its very difficult - on the one hand...
> On the other - I did not get it to work either :-) so that may simply be
> another ASSumption on my part...
>

The mysteries will be revealed, ASSumptions, or not! :)

> from the other replies, you can gather that I have a beagle+grbl on arduino,
> although I'm very interested in a smoothie, too since this addresses the
> entire system from an Ethernet interface to low level logic for less than
> $150
>

If you send me the files you want to see in the repo, and a rough idea
of how you want to list them, chances are really good I can get them
up for you (and show you how to update yourself going forward)

[John Griessen]

On 11/09/2012 04:42 PM, Samuel Rose wrote:
> The mysteries will be revealed, ASSumptions, or not!:)

Thanks Sam.

[James]

as in the other post, these are the files I have at present:

"625" Frame

http://cubespawn.com/old-site/600mm.html

"625" CubeMill Motion

http://cubespawn.com/old-site/625Motion.html

and the goal is to do something like what Gary Hodgeson has done using his template

https://github.com/garyhodgson/githubiverse-template/blob/gh-pages/README.md

http://garyhodgson.com/reprap/2012/09/githubiverse-a-github-pages-template-for-3d-printing-projects/  under "Further Ideas" using the template on github AND indexing the design via the RepRap Developement tracker

also on G+

https://plus.google.com/s/gary%20hodgson%20on%20githubiverse

[John Griessen]

On 11/09/2012 02:38 PM, Cube Spawn wrote:
> I have worked out some of the details for a spindle changing cube adjacent to the mill cube - again, making a modular head with a
> power and signal connector is the same problem as the power and data connections between cubes

On 11/09/2012 04:43 AM, Data Pathway wrote:
> the backplane will probably manage less than 50 signals irrespective of the configuration for a 4-axis or
> 3-axis-with-one-dual-drive configuration - the future looks modular!!

On 11/09/2012 10:44 PM, James wrote:
> Pallet Mover - the pallets I'd like to see are 450mm x 20mm thick octagons
> with a grid of tapped M6x1 holes at 25mm spacing

Are these pallets external to cubes or internal? Do you see passing material/work in progress
from one cube to another through the face they join with, or outside, then down the line, then inside?

How do you see the amount of space taken by a module function vs. its interconnect? 60/40? 70/30? 80/20?

You mentioned 50 signals once. These days, serial data with any number of packet types
would save on connector expense. I can see 80/20 working fine if you prioritize electricity, and
give air and oil hydraulic only a tiny cross sectional area that's optional and extendable by through pipes.

Or are support power and utilities planned to be outside a line of cubes?

[Cube Spawn]

On Mon, Nov 12, 2012 at 6:39 PM, John Griessen <jo...@industromatic.com> wrote:

On 11/09/2012 02:38 PM, Cube Spawn wrote:

I have worked out some of the details for a spindle changing cube adjacent to the mill cube - again, making a modular head with a
power and signal connector is the same problem as the power and data connections between cubes

On 11/09/2012 04:43 AM, Data Pathway wrote:
> the backplane will probably manage less than 50 signals irrespective of the configuration for a 4-axis or
> 3-axis-with-one-dual-drive configuration - the future looks modular!!


On 11/09/2012 10:44 PM, James wrote:
> Pallet Mover - the pallets I'd like to see are 450mm x 20mm thick octagons
> with a grid of tapped M6x1 holes at 25mm spacing

Are these pallets external to cubes or internal?  Do you see passing material/work in progress
 from one cube to another through the face they join with, or outside, then down the line, then inside?

the origional idea was pass through, but after beating my noggin against a huge number (ok, several cases) of corner conditions where a recursive part for a device didn't really have a big enough envelope to be made in the machine that would use it AND the module idea also eats up a little space in each cube.

So, I decides that a single line of pallet movers flanked by two rows of "functional" cubes making a row a maximum of 5 cubes wide x any reasonable number long (probably 5 or 10) - this is analogous to a circulatory system in that no part of an animal is more than 2 cells thick since each side has to make contact with a capillary... so pallet transport row, two functional cubes, another pallet transport "railroad"

 

How do you see the amount of space taken by a module function vs. its interconnect?  

more like 95/05 small latches top and bottom on a latching cube face arranged in logical female/male pairs and orientations to make joining universal in at least one absolute orientation (assumes cubes never rotate with respect to the pallet mover row - electrical/data connector follows the same general rule, but there can only be one instance per face.

as to the modules this will probably evole, but as I mentioned once before - I was thinking of rolling my own simple connectors for the Ultimaker 2 modules (Electrical and Mechanical) as ISA edge connectors mounted at the back edges of the modules and 4 identical milled circuit boards rigidly mounted to the "back" L&R sides of the cube - I should probably sketch up some visuals so we can compare notes and be clear about this... ;-)

 

60/40? 70/30? 80/20?

You mentioned 50 signals once.  These days, serial data with any number of packet types
would save on connector expense.  I can see 80/20 working fine if you prioritize electricity, and
give air and oil hydraulic only a tiny cross sectional area that's optional and extendable by through pipes.

My thinking here is: pneumatic or hydraulic devices will likely have an adjacent accessory cube to supply them with either the oil or air to run whatever it is... so the oil or air interconnects are specific to the pair - especially in these smaller cubes accommodations of this kind will crop up regularly

Or are support power and utilities planned to be outside a line of cubes?

these should be integrated via the inter-cube connectors - this merits a detailed discussion of its own since logic to detect weather a cube is connected to power - possibly a super-capacitor or (ick) battery..

must run, will take this up tomorrow!!

[John Griessen]

On 11/12/2012 07:46 PM, Cube Spawn wrote:
> pneumatic or hydraulic devices will likely have an adjacent accessory cube to supply them with either the oil or air to run
> whatever it is... so the oil or air interconnects are specific to the pair - especially in these smaller cubes accommodations of
> this kind will crop up regularly
>

Adjacent in direction of the line gets you no utilities if there's just 5% dedicated to control signals. Having an accessory cube
gets you no utilities since it still needs utilities from somewhere else.

How about the vertical direction for utilities? Pallet mover row between 2 production lines with human access row outside that
is 5 rows wide (if rows are human navigable scale). Utilities like 120VAC electricity, 48VDC electricity, 5VDC electricity,
80PSI wet air, 80 PSI dry air, 3000PSI hydraulic oil and return are in the vertical direction taking up zero rows of floor space.
Since hydraulics always leak, they get the bottom, air and electricity get the top.

If you're wanting 3D stacking, then the cube frames need to carry all power utilities, or grid paths between them need to
in all directions...and you need to think heat removal then also... so lets not strain our brains so much right away
and leave 3D stacking of cubes in all directions off the discussion menu for a while.

[Cube Spawn]

the only utility I see as universal (in the beginning) is 220 (or 440 rated) 3 phase since 3 phase 220 single phase 240, 120 (and no 208 220 230 240 wye/delta quibbles yet - its too early) are all derivative - then air, water, hydraulic, coolant and whatever are localized solutions 

Your reply clarified the INTENT of your question - more about interconnect space allocation than any other interpretation...

and the 50 signals comment is more relevant to the interconnect between modules within a cube, where the electronics/power module in the top of a cube inter-connects with the motion/pallet holder module in the lower 2/3rds of the cube.

Heat is the main problem in this scenario since between cubes (except in special circumstances) ONLY AC power and Ethernet cross the line - so 5v dc 48v dc etc etc are all converted internally  on board the cube or cube-set in question

With the prevalence of dc/dc based on switching regulators much less heat will be generated than older regulators created...

 and that still leaves us with the very small 5% interconnect - plus I see as unlikely a situation where hydraulic, pneumatic  coolant all cross between several general purpose cubes - I DO see all of that taking place in a set of cubes dedicated to a specialized purpose ( larger injection molder with a cooled mold f'rinstance)

but lest we forget - the next logical Cube size is 1.2 meter - a size more likely to be suited to bigger machines with multiple embedded subsystems of this sort. so - I'm not exactly ducking or ignoring the issue - but I think services would be distributed across more cubes for equivalent function in the 600mm line.and 1.2 meter machines will support more internal resources (small compressor, coolant pump etc.)

keep these observations and queries coming!! ;-)

[kc.ko...@gmail.com]

I'll chime in that through connections for air/air/hydraulic/electrical/electrical/electrical/and data (plus I think water and waste water could also be considered)...

1. These connections are adding to the cost....

2. Yet, they cost very little if just passing through with a simple pair of inline connections....

3. And they use up less than 5% of the space...

(Would you be spacing them across a single plane?)

4. I would say to standardize on WHERE they would be on said plane, and leave a space for them, universally, to keep the "every potential thing to all potential users" versatility...

5. I'd really hate to leave 3D go, as I can TOTALLY see a need for 3D to keep the concept from becoming too limited in scale. I would say we need a 3D adapter cube that would fit in-line with the utilities and provide a "T" for everything to go whichever direction you might need. That way, John's very-reasonable attempt/request to keep focus narrowed, is still reasonably accomodated, whilst still acknowledging those who see the inevitability of 3D as needing an immediate accomodation, with an answer. (Gee I hope that appeal makes sense, it's EARLY!)

6. No worries on heat-removal... "Heat-removal cube"s! Mark I is a fan unit. Mark II is a bigger fan. Mark III is active cooling. Etc...

So! Great precautions John! Solved. :-)

kc


Sent via BlackBerry by AT&T

[Data Pathway]

Wow, a lot of valid minor points made here

On Tue, Nov 13, 2012 at 7:32 AM, <kc.ko...@gmail.com> wrote:

I'll chime in that through connections for air/air/hydraulic/electrical/electrical/electrical/and data (plus I think water and waste water could also be considered)...

1. These connections are adding to the cost....

"cost" - this only applys for as long as the connectors remail commercial, off-the-shelf parts - once a cube is making them, then cost is materials and energy if recycling is broadly established - then at some point: just energy....

 

2. Yet, they cost very little if just passing through with a simple pair of inline connections....

also true, and see above ;-)

 

3. And they use up less than 5% of the space...

   (Would you be spacing them across a single plane?)

not sure - since in my model these connections are somewhat rare and only cross between cubes in sets that absolutely require it - and even in those circumstances there might be a reasonable, logical reason to have connectors at the bottom of a cube (hydraulics) rather than up in the top third with the electronics (hmmmmm, water and coolant lines...)

 

4. I would say to standardize on WHERE they would be on said plane, and leave a space for them, universally, to keep the "every potential thing to all potential users" versatility...

its a thoughtful answer, but I'm not sure what complications will arise - it may end up that conditional standards emerge as in -> if its a pressure line on a pump unit its here, but if its a return line from an "X" it goes here - as I said - those are narrower conditions and may have different solutions within a cooperative 1 SET of cubes versus another... 

 

5. I'd really hate to leave 3D go, as I can TOTALLY see a need for 3D to keep the concept from becoming too limited in scale. I would say we need a 3D adapter cube that would fit in-line with the utilities and provide a "T" for everything to go whichever direction you might need. That way, John's very-reasonable attempt/request to keep focus narrowed, is still reasonably accomodated, whilst still acknowledging those who see the inevitability of 3D as needing an immediate accomodation, with an answer. (Gee I hope that appeal makes sense, it's EARLY!)

well I agree with you BOTH to some degree here: its a complicating problem to solve, and I'll happily skip it at first since I think a vertical extension to the system can be addressed as a somewhat special case: there will always have to be a materials elevator involved when this problem arises - the rest of the system acts like 2D "sheets" of cubes and 3d thinking can be avoided 'till a true need for it arises. - my 2 cents... 

 

6. No worries on heat-removal... "Heat-removal cube"s! Mark I is a fan unit. Mark II is a bigger fan. Mark III is active cooling. Etc...

 

agreed - and here may be another of those cases - cooling water inter connect  for extracting heat from a group of cubes and a radiator assembly a short distance away to pump the heat out of where it is problematic 

[John Griessen]

On 11/13/2012 02:37 AM, Cube Spawn wrote:
> ONLY AC power and Ethernet cross the line - so 5v dc 48v dc etc etc are (not part of interconnect [JG])

Which line? In what direction?

On 11/13/2012 02:37 AM, Cube Spawn wrote:
> keep these observations and queries coming!

Observations, sure. I'd like an answer to the other questions:
Which directions do you see utilities coming and going out of?
Electrical codes will not let you string much power along module to module,
without code review as in Factory Mutual for manufactured items.. so I was hoping
you'd be open to utilities coming in a right angles to a production line of cubes,
from a "row", (like you describe for part handlers to use), that is for utilities,
and is built according to local electrical codes,
plumbing codes, etc... Some of that could be modularized, but still according to codes
existing now -- such as cord and plug connections for various voltages, AC,DC already have some
standards. All that needs defining is a zone along a side of a cube where such is supposed to go.

Why do you imagine only ten cubes in a row? I can see many more easily, and not all cubes.
Some would be smaller slices of cubes, or longer, keeping a square cross section.

On 11/13/2012 07:32 AM, kc.ko...@gmail.com wrote:
> Great precautions John! Solved.:-)

Really? Heat just goes away? As you scale up in all directions?

Let's drop talking about 3D. It's to complex for words without pictures and I can see misunderstandings
starting that kill the value of the discussion via email -- one way with delay.

I'm really wanting to discuss electric ins/outs, ethernet, and I'm getting
a little view of What James is thinking now. an aisle for people, then utilities,then cube-bots,
then a part-handling aisle shared by a mirror set of cube-bots, utilities, aisle for people.

I can see some systems that end up a little long to be one cube being made of several so
people can carry them around, in which case more subsystem connections than usual would go in-line
inside the cube outline, (not in the utilities aisle).

I'm not so hot on the idea of only one AC voltage going into cubes and being in the utilities aisle though,
since many separate power converters means they each lose 20% to waste heat. Central ones in the utility aisle
can have more load handling features like power over ethernet does: you connect power and communication about power handling
at the same time and negotiate how much can be connected. http://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices goes
into a way to deal with up to 100 Watts per cord connection.

Powered USB has some interesting ideas for dual cords-- one data for negotiating power draws allowed, and one for
heavy power draws -- more than will fit on an Ethernet cable or USB cable: http://en.wikipedia.org/wiki/Powered_USB

I was hoping to get a little past the conceptual fuzzy cloud level of thinking...
and on to where on a cube module the utilities go in and out.

[Data Pathway]

I dug out my note books to see what I thought in the beginning and what has evolved from that over this hugely extended developement cycle and not much has changed...

I thought that the power interconnect and ethernet should be adjacent (and integrated - with appropriate electrical isolation) and should be a part of the mechanical latch that connects two cubes.

This is slightly at odds with a later view that has long skinny "latch modules" (really just a rod and two small articulated blocks) mounted in each corner of a cube, giving 4 mount points on one face of a cube - in this view the power/data connector is centered on a pair of bars in the top 3rd of a cube - the latch is mounted on 4 spring guide/detent rods to aid alignment and allow relief during engagement.

with the introduction of removable modules - this would interfere with operation on the side of the cube the module mates with..

Here are 2 initial illustrations: 

https://picasaweb.google.com/103828779781480193226/CubeConceptuals

 I will add more as thier drawn...

[Data Pathway]

On Tue, Nov 13, 2012 at 12:39 PM, John Griessen <jo...@industromatic.com> wrote:

On 11/13/2012 02:37 AM, Cube Spawn wrote:

ONLY AC power and Ethernet cross the line - so 5v dc 48v dc etc etc are  (not part of interconnect [JG])

Which line?  In what direction?

This should be addressed by the post with illustrations - but I will draw an entire block of cubes as I have roughed out in my sketches and attemp to methodically break the logic of each decision out, so that any gaps in the logic can be identified - this should help solidify any design decisions once we are all in agreement on the details.

On 11/13/2012 02:37 AM, Cube Spawn wrote:
> keep these observations and queries coming!

Observations, sure.  I'd like an answer to the other questions:

Which directions do you see utilities coming and going out of?see above

Electrical codes will not let you string much power along module to module,
without code review as in Factory Mutual for manufactured items.. so I was hoping
you'd be open to utilities coming in a right angles to a production line of cubes,
from a "row", (like you describe for part handlers to use), that is for utilities,
and is built according to local electrical codes,
plumbing codes, etc...  Some of that could be modularized, but still according to codes
existing now -- such as cord and plug connections for various voltages, AC,DC already have some
standards.  All that needs defining is a zone along a side of a cube where such is supposed to go.

I think I follow this, but I'd like to clarify via sketches or drawings - I'm always open to anything that'll work - but I'm not comfortable that my mental picture looks like yours from this description

 ;-) 

Why do you imagine only ten cubes in a row?

Semi arbitrary number actually it'd probably be 9 or 11 - an odd number, because the track for the pallet handlers should run in two axes of the array "lengthwise" flanking each row of production cubes and "crosswise" at the ends of each "lengthwise" row to shorten pallet travel times and provide 2 ways to get material to a cube to avoid traffic jams or path conflicts... + current requirements will grow too high with very long stacks of cubes so some length limit will likely crop up...

 

 I can see many more easily, and not all cubes.
Some would be smaller slices of cubes, or longer, keeping a square cross section.

this statement I flatly don't understand, unless your talking about "feed-through" machines like a chop saw that will handle long material or something else... please clarify. - Thanks in advance ;-) 

On 11/13/2012 07:32 AM, kc.ko...@gmail.com wrote:
> Great precautions John! Solved.:-)

Really?  Heat just goes away?  As you scale up in all directions?

Let's drop talking about 3D. It's to complex for words without pictures and I can see misunderstandings
starting that kill the value of the discussion via email -- one way with delay.

I'm really wanting to discuss electric ins/outs, ethernet, and I'm getting
a little view of What James is thinking now.  an aisle for people, then utilities,then cube-bots,
then a part-handling aisle shared by a mirror set of cube-bots, utilities, aisle for people.

And actually, I hope fervently that the "aisle for people" is a feature of the prototype systems but is eliminated from production systems... yes I AM Krazy - pure people-less automation, automated maintenance, troubleshooting, repair, upgrades, installations after some years of the control software evolving.

And I mean evolving in a very pragmatic industrial control software sense - not some magical new AI breakthrough - just a flexible control system that can have canned test procedures added and tweaked until they can flexibly handle a lot of loosely structured problems, allocate resources to address them and get things back-to-normal 

digital homeostasis in other words.

 

I can see some systems that end up a little long to be one cube being made of several so
people can carry them around, in which case more subsystem connections than usual would go in-line inside the cube outline, (not in the utilities aisle).

I hope that  eventually an overhead crane rearranges cubes based on optimized production flows - I further hope people moving multi-part cube machines is a short lived phenonenon!!

I also think this presents an opportunity to re-visit why version control will be so critical to giving the control software the intelligence to red flag mating incompatible cubes, due to the gazillion potential subtle variations that will creep into a distributed, decentralized developement effort like this one. 

 

I'm not so hot on the idea of only one AC voltage going into cubes and being in the utilities aisle though,
since many separate power converters means they each lose 20% to waste heat.  Central ones in the utility aisle can have more load handling features like power over ethernet does:  you connect power and communication about power handling
at the same time and negotiate how much can be connected. http://en.wikipedia.org/wiki/Power_over_Ethernet#Powering_devices  goes into a way to deal with up to 100 Watts per cord connection.

more discussion needed and I'll need to take time to read the articles so I'm up to speed  - I see some general merit in the topic- but can't comment at present - so I need a clearer picture

 

Powered USB has some interesting ideas for dual cords-- one data for negotiating power draws allowed, and one for
heavy power draws -- more than will fit on an Ethernet cable or USB cable:  http://en.wikipedia.org/wiki/Powered_USB

I was hoping to get a little past the conceptual fuzzy cloud level of thinking...
and on to where on a cube module the utilities go in and out.

I think we are there

 

[John Griessen]

On 11/13/2012 04:03 PM, Data Pathway wrote:
>
> Here are 2 initial illustrations:
> https://picasaweb.google.com/103828779781480193226/CubeConceptuals

OK. Thanks. You answered my question in a picture after a thousand words, (not really, but felt like it),
that some utilities come in at 90 degrees from the line of cubes in a production line.

I need that.

Thanks James.

Today I was also needing a doctor visit and brought along trade mags to read, being too busy usually.
Machine Design Oct 2012 has an article on the bots made by the Roomba company that is a must read.

Their software sounds really good and we are maybe lagging way behind in fiddling with mechanical
devices to control and limit possible interactions, where they are producing and marketing a
humanoid robot aimed at small businesses that can be trained without programming by ordinary employees.
Notably it has many concurrently running programs aimed at human safety. Also, it's base programming
allows users to "physically program" tasks without heed for low lying ideas like safety, or
defining the area it works in. It does all that by itself.

See http://machinedesign.com/article/a-robot-for-the-rest-of-us-1016

The people aisles need to accommodate Baxter robots as well as people!

On 11/13/2012 04:54 PM, Data Pathway wrote:
> hope people moving multi-part cube machines is a short lived phenonenon!!

Sure, but please let's get to now instead of the future all the time.

thanks,

John

[John Griessen]

On 11/13/2012 04:03 PM, Data Pathway wrote:

> I thought that the power interconnect and ethernet should be adjacent (and integrated - with appropriate electrical isolation) and
> should be a part of the mechanical latch that connects two cubes.

Seems very complex and assumes in series connection of power. Electric inspectors would not like it for
adding more and more load in series, where normal AC electric distribution is all in parallel
and we go to lengths doing wiring to get that parallelism.

Ethernet is also a parallel connection via hubs -- no daisy chaining, so your cube corners would max out in
space available for ethernet connectors right away.

I see both electrical and ethernet along side and consuming their own aisle along with other
utilities running in trays like 80PSI air, tap water,
DI water, filtered dry air, chip and trimmings removal vacuum, drains, ?.

For the assembly conveying aisle, I can see semi autonomous carts that pull and align themselves on track,
but contain their own rechargeable moving power and whose paths can overlap as they service several cubes,
and the work in progress moves mostly in one direction. Some of their stores of parts added to assemblies
could come from bins on top of cubes (e.g. circuit assembly) that are replenished from the people/Baxter aisle,
and whose flow into an assembly is part of that cube's function, not for the assembly conveying aisle.

See http://machinedesign.com/article/a-robot-for-the-rest-of-us-1016 about Baxter.

[Cube Spawn]

I read the baxter account when the mag showed up!! I usually consume each machinedesign mag as they arrive!! ;-)

actually the power is serial, parallel by virtue of the cross connections between cubes and since each cube will have to have SOME power switching intelligence - since obviously when a cube is relocated, or a module is removed - to avoid arcing, they will have to be capable of disconnecting their internal loads prior to removal - while retaining some degree of "awareness" (battery or supercap powered)

keep in mind this is still an opinion - no hardware using this capability has been built by me ;-) 

As to Ethernet topology can be managed in the osi model at protocol layer 2 so a tree, mesh or series topology can be used, just not off-the-shelf - i won't pretend that I know how this is implemented specifically, but its used by Ethercat and some implementations of industrial Ethernet - so I know its a viable possibility and I'm also aware of the general vulnerabilities that star, tree, ring and serial topologies  exhibit - so I'm open to guidance, but I think the mechanical complexity of physical star topology may rule it out.

[John Griessen]

On 11/14/2012 09:28 AM, Cube Spawn wrote:
> the mechanical complexity of physical star topology may rule it out.

It doesn't stop office workers today. They can do printer installs and VOIP phone installs
just fine.

You must be thinking of click mating cubes and all connections are done. That is
extremely complex and fragile to dirt, etc. I think click connecting should wait for a future generation
of cubes-never-touched-by-humans, not these first ones. Software like runs Baxter, and
use of existing standards as in POE, powered USB will get more bang per buck and have this idea flourish today.

Stringing power in series through a chain of cubes will run into trouble,
esp. for milling machines 3D heater printers and laser cutters that are first on the list.

[John Griessen]

On 11/13/2012 04:54 PM, Data Pathway wrote:

> I can see many more easily, and not all cubes.
> Some would be smaller slices of cubes, or longer, keeping a square cross section.
>
>
> this statement I flatly don't understand, unless your talking about "feed-through" machines like a chop saw that will handle long
> material or something else... please clarify.

I can see more than ten modules easily in a production line. I can see making a single module out of cube components
such that it is not a cube shape, and the several pieces together are not a cube shape, but rectangular solid.



Which brings up more questions:-)

I'd like to see a connection method that works with just one corner latched and as few as two sides/edges flush
touching. That corner could be the reference datum point for parts to be handed to it from part/assemble carts.

Only demanding to have one corner on each face that connects to the next cube would let you connect different
sized cubes, which you could easily end up with...by finding a nice function made mostly for circuit assembly
in a 300mm cube and using it with a 625mm cube milling machine as a first step in a chain passing parts to have
other things attached to them.

To me, physical latching isn't even needed to be in a corner -- it could be done by clamping side struts.
Corners could be for aligning -- pins in the bolt holes would do that. Clamps that engage a cube's strut slots
or nuts in the slots and hold two together that are laying along side each other would be a
simple way of anchoring cubes to each other. I don't see a big need for cubes to stack flush against each other
in all directions, just in lines.

[Robert Teeter]

I think that we are over thinking the cube system.  First the electrical power needs to be supplied externally to each cube because of unique power loading of each individual cube.  Also the Ethernet data connection should also be provided individually to each cube because of how and why each production line is created.  The only interconnect should be from specialty lines from an adjacent cubes such as one that supplies hydraulic power/air power and such.  The only other case is a cable that carries physical items interface signals. (IE.  Item done/moving and such).  For the power and Ethernet I think that the interface area of the cube should be defined but not a fixed plate structure so that umbilicals can be connected from that area. the connection cable should be no longer than 1 foot so that they can be tucked away when the unit is being stored.

Just my $.02

Bob Teeter

[John Griessen]

On 11/15/2012 03:38 PM, Robert Teeter wrote:
> The only other case is a cable that carries physical items interface signals. (IE. Item done/moving and such).

I can see specifying that. It should be short packets and low data rate over all, (low as in 50Kbits/second
max everyone), and each cube should limit communication to 1Kbits/second average, so 30 or so cubes could use it
in a time slot way, like CAN bus. (Or just specify CAN bus). Cheaper and easy is to use I2C or IIC bus.

[Cube Spawn]

There are a lot of issues in these two emails...

'cause I mostly to partially agree with everything you mention, but don't fully agree with a significant portion of it.

I'll respond to the first paragraph now and carefully parse through the rest before addressing them.

>>I can see more than ten modules easily in a production line.

oh, me too! but as you mention, that limit is only in one dimension, and I agree we should stick to 2 at first...

this picture is for ONE TYPE of array in which there is a semi random mix of tasks scheduling through, or where parallelism is needed (such as 5 cube mills makeing a high count part in parallel)

https://picasaweb.google.com/103828779781480193226/CubeConceptuals#5810536612984998162

but, this approach fails to address long stock and/or long parts and since stock can be anywhere up to 21 feet long (or longer in special cases) that COULD require a 40 cube linear array (in 625's) in the worst case to handle a that scenario which I do not see as entirely feasable I think 625's are a poor fit to that kind of problem.

 

 I can see making a single module out of cube components such that it is not a cube shape, and the several pieces together are not a cube shape, but rectangular solid.

I think I follow you here - using standard cube parts to build a 20 foot rectangular prism (similar to a cube but longer in one dimension) that contains all the steps to vacuum form a part and trim it out in a dedicated machine....

started in the AM - got called to repair a machine...Left it open 

Ima send it now without testing my morning logic....

[Cube Spawn]

Bob, I have been overthinking it for 4 years, why stop now? ;-)

OK, I concede that getting it to work at all trumps getting it to work as a generation IV "elegant" solution right out of the gate.

But once again - this has machine tool architecture all through it, but it should not behave like a machine tool  --> take a look at ROS 

http://www.willowgarage.com/pages/software/ros-platform

This is a very robust open source robot control suite - can run on the beagle bone, or the rasperry pi - and many other linux platforms and manage an aggregate machine of arbitrary complexity

So the move command for a pallet transporter that crosses the boundary between two cubes can broadcast over the universal ethernet conections to the "outside" interface on the cube, so that the traffic manager (ROS) can command another move after checking (or eliciting)  the latest status from the next cube I feel that externally at least ethernet is enough - now between composit cubes that form some tightly coupled process this may not be enough - but I'm not imagining a 15 to 150 lb pallet will merit "real" time responsiveness if there is a hybrid of network level traffic management and local level sensing and command...

plus there will be purely robotic cells that do not receive GCode or obey a PLC but have one or more dedicated processors running complete OS's onboard so in this case and regarding the system overall ROS seems like a better fit - on the machine tool cells the beagle or pi will recieve start stop, load unload style commands and internal execution will more closely resemble a pc dripfeeding gcode to a conventional industrial control (smoothie, GRBL, BOSS4 Fanuc, whatever - you get my point...)

so once again I agree that these esoteric connection issues can be solved after core issues like nanocomputer--controller--motor boards--motors--drivetrain--sensors....

[Robert Teeter]

Guys - here is a video of a warehouse system run by robots.

http://www.youtube.com/watch?v=lWsMdN7HMuA

Please notice that a machine is designed to do one thing well.

A general purpose robot like this item can be used effectively but can not do everything.

http://machinedesign.com/article/a-robot-for-the-rest-of-us-1016

It is possible for this robot to modify its general instructions to a variation of specific type things but it is still a robot that requires direction.

Bob Teeter