Business start up for Cubespawn

[CubeSpawn]

As most of you know, I had begun discussions with a large research facility back in November this induced me to start looking around for additional ways to get CubeSpawn off the ground.

So, last weekend - I went through a "3 day startup" program and suddenly I have a group of interested, talented individuals participating in getting this idea shipping - those of you who have show interest or contributed more directly are invited to pay attention as we plan to roll out the printer design, get some documentation completed and as rapidly as practical - get kits shipping.

I would be very interested in your input.

James

[Samuel Rose]

I just thought about CubeSpawn today, and thought about putting some
time back into doing some builds with
Vagrant/VirtualBox/Puppet/Ubuntu/RoS to CI on Jenkins with perhaps a
custom Ubuntu image.

Anyway, it's been tough for me lately to keep up with where CubeSpawn
is at, exactly. Is there one place you can point to that summarizes
the state of of CS? Are you building a 3D plastic printer first? Just
curious, and kudos and congrats on taking it to this level!

> --
> You received this message because you are subscribed to the Google Groups
> "Cube Spawn" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cube-spawn+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Samuel Rose]

The other thing that I forgot to mention, that I've been interested in
experimenting with in a simulated CubeSpawn stack is
https://getsentry.com/welcome/ tied to Redmine (or RT). Sentry would
monitor logs from Robot OS and the underlying operating system, plus
any custom logs created that monitor, well, anything. Rules can be
created in Sentry to alert people via email, SMS, etc, and rules can
be created as conditions for placing trouble tickets into a queue such
as RT or Redmine.

So, if a machine is in production, and monitoring systems on the
machine throw an error, Sentry can pick it up, give a visualization of
the output of logs, and send messages if the condition meets a
predetermined criteria.

[James Jones]

Yes Sir!

Finishing the plastic printer, and applying to a hardware startup accelerator program in the next week - we will very likely be doing Kickstarters for each cube design going forward as well as applying for some grants and potentially presenting to a group of Angel VC's here in San Antonio Anybody looking for a slightly used internal organ? I may have to sell one to have an income during the startup process... ;-)

[Samuel Rose]

On Sat, May 4, 2013 at 10:15 PM, James Jones <cube...@gmail.com> wrote:
> Yes Sir!
> Finishing the plastic printer, and applying to a hardware startup
> accelerator program in the next week - we will very likely be doing
> Kickstarters for each cube design going forward as well as applying for some
> grants and potentially presenting to a group of Angel VC's here in San
> Antonio Anybody looking for a slightly used internal organ? I may have to
> sell one to have an income during the startup process... ;-)
>

LOL. I will put the word out for you!

[Adam Gmail]

Congrats James, really glad to see cube spawn moving forward. All my time has been absorbed by my new project www.letstalkbitcoin.com, are you guys into Bitcoin yet?

Sent from my iPad

[John Griessen]

On 05/04/2013 09:13 PM, Samuel Rose wrote:
> The other thing that I forgot to mention, that I've been interested in
> experimenting with in a simulated CubeSpawn stack is
> https://getsentry.com/welcome/ tied to Redmine (or RT). Sentry would
> monitor logs from Robot OS and the underlying operating system, plus
> any custom logs created that monitor, well, anything. Rules can be
> created in Sentry to alert people via email, SMS, etc, and rules can
> be created as conditions for placing trouble tickets into a queue such
> as RT or Redmine.
>
> So, if a machine is in production, and monitoring systems on the
> machine throw an error, Sentry can pick it up, give a visualization of
> the output of logs, and send messages if the condition meets a
> predetermined criteria.

Sounds good. I've even heard of redmine and I'm no expert, so it's
a small set of SW dependencies and robust parts...

[John Griessen]

On 05/05/2013 12:08 AM, Adam Gmail wrote:
> are you guys into Bitcoin yet?

Can you point me to real cases of early adopters of manufacturing equipment
that have bitcoins to spend?

[Adam Levine]

No, Bitcoin is still in the distribution and speculative growth phase - Over the next year I expect the situation to clarify (if it's the future of payment, or if it's going to be illegal)

Adam B. Levine
Editor-in-Chief
Let's Talk Bitcoin!
Collaborators! Apply Here to be added to my Rolodex
ph. 510-779-0195

--
You received this message because you are subscribed to the Google Groups "Cube Spawn" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cube-spawn+unsubscribe@googlegroups.com.

[Samuel Rose]

Yeah, these things might not be immediate. But, they could be really useful in using cubespawn in actual production machining processes ...

[James Jones]

So a quick read about RedMine, Request Track and a comparison of the functionality leads me to believe these would be human interface tools and/or mostly for system monitoring and issue resolution/tracking

I'm still very interested in building a roadmap/blueprint for how the machines see and resolve problems and how this can be a cumulative library of prioritized applied solutions - a hierarchy of alerts that induce certain canned logic to be run until either the problem is resolved or an alert is passed "up" to human logic - in this type of system it can start out very "stupid" (frequent alerts) and "smarter" logic can be added to automate issue resolution over time so it becomes progressively more automated without having to solve everything at once when the system is designed.... my 2 pesos...

[Samuel Rose]

On Mon, May 6, 2013 at 6:24 AM, James Jones <data.p...@gmail.com> wrote:
> So a quick read about RedMine, Request Track and a comparison of the
> functionality leads me to believe these would be human interface tools
> and/or mostly for system monitoring and issue resolution/tracking
>
> I'm still very interested in building a roadmap/blueprint for how the
> machines see and resolve problems and how this can be a cumulative library
> of prioritized applied solutions - a hierarchy of alerts that induce certain
> canned logic to be run until either the problem is resolved or an alert is
> passed "up" to human logic - in this type of system it can start out very
> "stupid" (frequent alerts) and "smarter" logic can be added to automate
> issue resolution over time so it becomes progressively more automated
> without having to solve everything at once when the system is designed....
> my 2 pesos...
>

Well, we are on the same page. RT or Redmine are just escalation
levels for humans for sure. Although, one *could* mix human/machine
intervention. So that if no human can answer within "x" amount of
time, a machine takes over (maybe just stopping production. It all
depends on the scenario). In practical use now, you'd have a mix of
some end users that are comfortable with lots of automated
intervention, all the way to some who would want to intervene at every
hiccup. I anticipate that in early adoption of cubespawn, there would
be lots of human intervention. So, that is why I imagined these tools
would be immediately useful.

However, to your point, there could be a stack of applications.
Machines could simply respond to sensor levels, log-level errors, etc.
Machine error response is the kind of thing that software testing
approaches would be really great at simulating and refining. This is
something I think I can help with, too. There are already really good
all-purpose software testing tools that could likely be used as-is for
automated testing of:

* Building software stack (a mix of local and system unit and integration tests)
* Simulating production runs and error response (possibly some more
local and system unit/integration tests, plus some server/client load
simulation runs)

There are also some scenarios that can be modeled with tools like
http://ccl.northwestern.edu/netlogo/ before building hardware or
software, just to see if you would run up against known limits of
networks and information systems, resource distribution, etc.