pulling it all together

[Hepheastus]

from your site

"What is lacking (to my knowledge) is a mechanism to integrate
multiple machines into a PROCESS, and control the steps required to
execute and coordinate the process to complete parts or assemblies."

Try microsoft robotic studio.

[Joshua D. Johnson]

Schmicrosoft...,
each machine or module should have its own programming and "trigger" I/O so that when combined creates a process. Gaps can be filled with simple PLC's and microcontrollers if required.  J

[John Griessen]

On 06/28/11 11:37, Joshua D. Johnson wrote:
> each machine or module should have its own programming and "trigger" I/O

Yes, central control is old school -- control headquarters.

What kind of standard data bus is good for machining, robots, or fast moving
power supplies and such? There are dozens.

Sercos plastic optical fiber bus is used for some motors to avoid problems of
ground loops and signal integrity going bad as a bunch of things are
connected with a fair distance between them. I could see figuring out a low cost
electrical to POF (plastic optical fiber) transceiver circuit and using that...

Then you could skip it at first, and add it as things get complex and you start to need it.

John

[Joshua D. Johnson]

I just disembowled a pretty high tech electronic of hydraulic/pneumatic system that was %80 Bosch extrusion ( 80/20 equiv.) they were using fiber optic between processes and PLC's and microcontrollers at the core. this machine was for simple hair sorting/mixing for brush making. I'm hoping to use the parts to start making cubes in cubespawn fashion and will probably use high axis count drivers and controllers with as many I/O ports and a microcontroller with as much processing capability as possible.

When programming G-code a person can add these triggers, I don't know what they are called but I've tied into them in a process environment. The simplest of these only pause while say a pallet is exchanged or a vice is opened. the more complicated trigger whole routines in robots etc. the great thing about this arrangement is you aren't trying to control everything from one vantage point, everything is timed individually and triggered so you don't have something crazy at one end happening when it shouldn't.

Interesting conversation here. I'd like to see where the mechanicals are and contribute..

JOSH

--

[Data Pathway]

I on the other hand, do NOT have a lot of practical, contemporary Machine controls experience.

But given that each machine (in my model, or if you prefer, in my mind) is semi-autonomous in that its a node on a the network, and  whose neighboring cubes can and will change position as the manufacturing sequence is optimized for different orders-of-operation on different parts.

The triggering concept correlates most closely with what I see as the essential element for managing a system who's distribution is of unknown scope when a module is being designed.

If the design uses well documented commands to move a pallet, ack that its in position, set a status to "locked" on a pallet thats parked for a machining operation etc. then each cube can ask for something and await an acknowledge before proceeding -- this actually sounds like willow garages ROS in some ways  http://www.willowgarage.com/pages/software/ros-platform with a publish, subscribe architecture

which then makes passing "canned" gcode something that is managed as a file delivery event at the loading of a new setup in a cube -- in other words, the cube participates in the network as a peer with other cubes - and hands g-code to a dedicated control within itself...

This could be any of a wide range of PLC's, embedded micro-controllers or a function running on the PC104 or other embedded Industrial PC that participates as a peer

I think getting the architecture straight is an important project in its own right - then committing to the preliminary steps to implement it becomes a much clearer path

feedback please!

James

[Data Pathway]

bear with the typos, please

[John Griessen]

On 06/28/11 21:29, Data Pathway wrote:
> The triggering concept correlates most closely with what I see as the essential element for managing a system who's distribution
> is of unknown scope when a module is being designed.
>

It would help to have a time scale in mind at least.
Precision time protocol is something that is available in real hardware now, and what I think of,
but you may think it is "too good", since it gets you 25 or 50 ns resolution over TCP/IP ethernet
when the ethernet is the PTP upgraded kind...

John

[Data Pathway]

So then, Ethercat?

[CubeSpawn]

Just recieved this tip from a guy in toronto

Not a Circuit Designer, but this looks interesting - described to me
as a "kind of like a github for electronics design"

http://upverter.com/

On Jun 29, 8:02 am, Data Pathway <data.path...@gmail.com> wrote:
> So then, Ethercat?
>

[CubeSpawn]

I set it up a long time ago, but never really got a clear conceptual
picture of its workings - I'll probably steer clear of closed source
when I can and ROS looks a lot more Viable for the long haul...

As an amateur roboticist, I'm sure I don't know much, but committing
to open source seems to make a broader adoption more likely.

I do appreciate all arguments for and against particular approaches,
however because its rare that I don't learn something by reading them.

Thanks for the input!

[John Griessen]

On 06/29/11 08:02, Data Pathway wrote:
> So then, Ethercat?

Ethercat seems to be not compatible with ordinary ethernet.
PTP enabled ethernet is, so there is no loss of standard function.

See http://en.wikipedia.org/wiki/Precision_Time_Protocol, IEEE-1588.

John

[Data Pathway]

Very cool, I'll read up! 

[Patrick Connolly]

Baha... "guy in toronto" here :)

They're still in alpha, but I'm expecting them to do some amazing things once they get off the ground.

I'm feeling proper version-control will be key, and if you agree, this thread might be of interest:

http://feedback.upverter.com/forums/99661-alpha-release/suggestions/1984907-start-a-discussion-on-possibilities-for-version-co

[Data Pathway]

He's Everywhere, He's Everywhere!!

between octopart, and github I guess all the "other" functionality is present (version control, parts catalog) so this will presumably glue those elements to eagle files and BOMs