Cross posted from G+ community

[CubeSpawn]

OK!!
Couple of major minor breakthroughs this last week:

Looks like the Cura software will be good for producing G-Code for packaging jobs for later efforts at automation.

The Ultimaker board is populated and tested everything seems good so far, I have a knock-off Arduino Mega with marlin firmware which has been effortless thus far to upgrade etc. I hooked up the X axis Nema 17 and can jog it through the software

I'm looking for input on an operations tool-chain to help architecture the control files for automation, these will be unique to each process, that is, one for milling, another for printing and so on...

Also, I will attempt to coordinate postings from the google group to the community and vice versa.

[John Griessen]

On 01/20/2013 05:27 PM, CubeSpawn wrote:
> The Ultimaker board is populated and tested everything seems good so far, I have a knock-off Arduino Mega with marlin firmware
> which has been effortless thus far to upgrade etc. I hooked up the X axis Nema 17 and can jog it through the software

Sounds great. From your self descriptions I didn't know you were so able at assembly/debug/load-code/go. Congrats.

> I'm looking for input on an operations tool-chain to help architecture the control files for automation, these will be unique to
> each process, that is, one for milling, another for printing and so on...

Not sure what that means. Are you thinking along the lines of puppet scripts that set up machines with
code they will run, tear them down to nothing, set them up again? The benefits of such coding systems
is the essence of what you want is boiled down, with less chances for mistakes, and may even
be portable to different hardware with less work as time goes on and hardware fails/obsoletes.

[James Jones]

John, without your calls for clarity, I'd get to spew a lot more high minded sounding gibberish...

BUT, since you asked, I'll attempt to clarify:

IF we are someday able to get to a "hands-free" level of automation, (and I'm not presuming via some super duper AI) 

I'm visualizing a web interface where I check off the several items I'd like to have made.

My "order" gets submitted to the closest queue, but it contains several items that take a while to make so the "deliver by" date triggers the software to break the order up and spread it to additional queues.

Any single item in the queue - (let use a Machined part on the mill for example) needs to have a sequencing file associated with it to order material by type and dimensions and this may trigger additional machines to select material and cut it to the raw stock dimension - which must be specified in the master BOM for the part.

We have already defined the first section of the file in the "operations tool-chain" referenced in my original comment of necessity:

Milled Part Header

*

*

*

Material Specification

*

&

*

Stock Dimensions

 *

So presuming the information in the "stock dimensions" triggers the scheduling of the automated cutoff saw to lop a 75mm piece of 25x12.5mm barstock off and then deburrs that stock to a general level of smoothness and delivers it to the "stock for pending jobs" holding area or to the fixturing system...

Next, a Fixturing file will have to be translated to action by a Fixturing machine - modular tooling affixed to a pallet following a "placement recipe" to hold the stock in place during machining operations. 

this will likely be a template file and a motion control writer that interprets the template file in terms of placing,  then attaching each modular tooling component.

Then placing and securing the stock,

Now the work can be queued at the mill...

Oh, wait what tool(s) are specified for the first operation? is that tool available in the system? is it sharp? is it set to the proper Z- offset?

are the machines that do those things part of this system? and much more.....

I believe thinking these processes through will help define, and then prioritize what kind of programming needs to occur in the "control layer" of the overarching control system AND what information will be a part of the specification embedded with the part number - I see what we would call a part number, be vastly richer for this kind of system, probably a tarball with versioning and detailed control and specification information included in it. 

I see the puppet scripts as a way for the control system to add machines, setup new machines, keep everything synchronized and allow updates, fixes, and changes to the "on-machine" environment to propagate from templates into the field, and corrections and identified problems to get consolidated and applied to the "master" templates.

But I am totally ignorant about puppet/chef/others? So my comment is about sequencing for operations/, rather than OS deployment templating. 

hope that's clarifying!!!

James

[John Griessen]

On 01/21/2013 07:20 PM, James Jones wrote:
> I believe thinking these processes through will help define, and then prioritize what kind of programming needs to occur in the
> "control layer" of the overarching control system

It can, but it's overwhelming, so I just think of figuring a setup time and processing time for each recipe
and that humans will do the scheduling selections first. Most of allowing bigger dreams,
(of bot swarms doing your bidding), to happen is keeping the building block
costs down down down.

AND what information will be a part of the specification embedded with the part
> number - I see what we would call a part number, be vastly richer for this kind of system, probably a tarball with versioning and
> detailed control and specification information included in it.
>
> I see the puppet scripts as a way for the control system to add machines, setup new machines, keep everything synchronized and
> allow updates, fixes,

[jg]so far sounds OK

and changes to the "on-machine" environment to propagate from templates into the field, and corrections and
> identified problems to get consolidated and applied to the "master" templates.

[jg]might be stretching it to think no human intervention in that.

my comment is about sequencing for operations/, rather than OS deployment templating.

OK. Please tell us more about a template definition if you call it that. I think
of processes as cooking recipes mostly. I like a cooking analogy for making things.
All you'll get from puppet scripts is sequencing on computers that have rather complete OS's,
not really the small ones on some of the simpler machines. Puppet could set up things to do with
ROS, but not really go as far as reloading the low cost machine controllers we've been discussing
based on $5 ARM 32 bit computer and peripherals, (called microcontrollers). They will probably
run Smoothie for many types of mechanical cutter machines, and that is not a full OS as
puppet usually works with. It's probable that much of the set up function often done with
puppet will have to be done inside ROS, a nice OS with file systems that puppet can converse with.

If I'm wrong about puppet and it could be good for setting up any kind of mini-OS/command scheduler
like Smoothie on ARM Cortex M4's with only 2MB flash and 256KB of RAM, then I'll be all smiles.

Many machines/part handlers/sensors would be even better served by a super simple serial port command
handler mini-OS on M3 ARM chips with even less RAM and flash. They would need ROS serial connections
to get much done. So we might end up with a $150 ROS controller for a line of machines doing
a process, and including the part moving in the line, but then being reloaded by puppet
setups to change functions, and orchestrated by one
main ROS controller for several of these lines and part flows to and from them to warehouse shelves
or packaging lines as just another process getting them ready to ship out.

John Griessen

[James Jones]

On Mon, Jan 21, 2013 at 11:18 PM, John Griessen <jo...@industromatic.com> wrote:

On 01/21/2013 07:20 PM, James Jones wrote:

I believe thinking these processes through will help define, and then prioritize what kind of programming needs to occur in the
"control layer" of the overarching control system

It can, but it's overwhelming, so I just think of figuring a setup time and processing time for each recipe
and that humans will do the scheduling selections first.  Most of allowing bigger dreams,
(of bot swarms doing your bidding), to happen is keeping the building block
costs down down down.

Oh, Agreed, part of the excitement comes from dreaming about the end result - and my mind ALWAYS outruns my feet, since it has no heavy lifting to do and no miles to walk...

also, I STARTED at the end result (bot swarms doing my bidding) finding a practicable way of getting the process grounded enough to be real and not outrageously expensive has been the challenge...

 AND what information will be a part of the specification embedded with the part

number - I see what we would call a part number, be vastly richer for this kind of system, probably a tarball with versioning and
detailed control and specification information included in it.

I see the puppet scripts as a way for the control system to add machines, setup new machines, keep everything synchronized and
allow updates, fixes,

[jg]so far sounds OK


and changes to the "on-machine" environment to propagate from templates into the field, and corrections and

identified problems to get consolidated and applied to the "master" templates.

[jg]might be  stretching it to think no human intervention in that.

Yeah, I don't see the machines doing this anytime soon - but there are portions they CAN do after the human reasoning part is applied to change the specifications/coding/etc - rolling it out to all the devices in the field fr'instance...

 

my comment is about sequencing for operations/, rather than OS  deployment templating.

OK.  Please tell us more about a template definition if you call it that.

Probably just a part # named folder with several discrete files in it to begin with:

a machine readable "control" or "configuration" file that delineates the role each of the discrete files play.

One would likely be a G-code file for printing or other CNC operations, 

a material specification, possible with a primary selection, and acceptable substitutions, if their are any. 

Some human readable instructions, diagrams, cad files, how-to's might be worthwhile until the automation is up to running the process.

Basically all the relevant documentation to be able to run the project that either an operator of a semi manual process would need and the structured control files that autonomous machines would need is the final form...

 

 I think of processes as cooking recipes mostly.

 I like a cooking analogy for making things.

I'm also fond of the culinary comparison: I like to use the roast beef sandwich analogy:

Bread - a complex result of the huge agricultural infrastructure--Plant->fertilize->irrigate+harvest->process->Transport->mill->package->transport->mix->bake->slice->package->distribute->purchase

etc etc

I also use the "Stew" analogy a lot - mixing bits and pieces together for a desired result 

So, with that in mind its understood that this is an integration project - putting existing things together in a useful way to end up with -->Swarms of bots doing our bidding.

 

All you'll get from puppet scripts is sequencing on computers that have rather complete OS's,
not really the small ones on some of the simpler machines.  Puppet could set up things to do with
ROS, but not really go as far as reloading the low cost machine controllers we've been discussing
based on $5 ARM 32 bit computer and peripherals, (called microcontrollers).

Again, I entirely agree puppet probably populates PC's, BeagleBones, Rasberry Pi's and potentially other SBC's in an automated way. but not necessarily everything

 

 They will probably
run Smoothie for many types of mechanical cutter machines, and that is not a full OS as
puppet usually works with.  It's probable that much of the set up function often done with
puppet will have to be done inside ROS, a nice OS with file systems that puppet can converse with.

If I'm wrong about puppet and it could be good for setting up any kind of mini-OS/command scheduler
like Smoothie on ARM Cortex M4's with only 2MB flash and 256KB of RAM, then I'll be all smiles.

as mentioned before - in either scenario i.e. Puppet, or something else really has a very simple task to do: transfer a pre-formulated flash image or E^2PROM image to a device by Serial or JTAG or whatever. Formulating those images will likely be manual/require human judgement for quite a while, but burning them to blank hardware is very automatable...

 

Many machines/part handlers/sensors would be even better served by a super simple serial port command
handler mini-OS on M3 ARM chips with even less RAM and flash.  They would need ROS serial connections
to get much done.  So we might end up with a $150 ROS controller for a line of machines doing
a process, and including the part moving in the line, but then being reloaded by puppet
setups to change functions, and orchestrated by one
main ROS controller for several of these lines and part flows to and from them to warehouse shelves
or packaging lines as just another process getting them ready to ship out.

I believe we are seeing the same picture here, with barely discernible variations in the tint of the picture ;-) 

John Griessen