Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 Jul 2006 16:04:39 GMT
|
Viewed:
|
4108 times
|
| |
|
|
In lugnet.robotics, Brian Davis wrote:
> [Others have addressed most of this, so I'm just putting in my 2 cents and not a
> bunch of "me too"s]
>
> In lugnet.robotics, Rafe Donahue wrote:
>
> > Building a (reliable, functioning) GBC module
> > is harder than it looks.
>
> Ok, but that one I do have to add a "me too" :-).
>
> > "one ball per second" --- over what time period?
>
> Over any long-term average. This could be 1 ball every second, or a batch of
> four balls every four seconds, etc., (up to batches of 30 balls every 30 seconds
> or so, in some cases). Note that this is a *minimum* throughput, and really
> trying to overengineer these aspects is a Good Thing. One of my modules can
> handle sudden batches of 60-70 balls, and can output them at about 2-3 bps. The
> result is it is "robust", in the sense that it can do things like temporarily
> impound the ball stream (downstream module not functioning? I switch this module
> to "recycle", and even if the rest of the GBC is feeding it at 1 bps, the
> downstream system can be shut down for a minute or so without any other action
> needed).
>
> > I can easily build a module that can absorb
> > balls at 1 bps but has an equivalent leak rate
> > so that's not right.
>
> True, but it doesn't match the standard either (that's a throughput of zero
> bps). In practice, minimize the error rates as low as you can possibly get them,
> and hope. For small GBCs, this is sufficient. For large GBCs like BrickFest, as
> you note, even really good low error rates still mean nearly constant attention.
> The allowable error rate would therefore be set in a sense by the size of the
> GBC assembly, and you don't know that (worse, the largest GBC assemblies would
> require the lowest error rate modules... which are also the rarest modules, so
> there's not usually enough of them to build a large GBC).
>
> > How much testing does one have to do to determine
> > that the rate is actually that small?... nearly 70
> > hours of testing at 1 bps with no jams.
>
> Or to put it another way, enough to drive your spouse to kick you out of the
> house. Worse, all you've done then is prove that you module works with a
> particular input... and in a real GBC, you never know how the upstream module
> will be handing off balls to yours (and that can actually influence a lot).
>
> > Get testing!
>
> Yeah. Well, first I need to build some more modules, and update some old
> ones... and reconstruct some train modules I'm happier with. But point well
> taken.
Roger that on the spouse kicking out part. We already had our annual Brickfest
argument! She says I run and hide in my Lego room for endless hours. She's
wrong: I walk there!
I have one more tidbit: please email me at
mr.roboto@NOSPAMgreatballcontraption.com with any layout requests, planning tips
or other lessons learned. The website has a lessons learned page that I will
update to include a lot of the ones in this thread too. Don't be afraid to sign
up for Brickfest GBC too!
Dave H.
www.greatballcontraption.com
|
|
Message is in Reply To:
 | | Re: thoughts on gbc module reliability
|
| [Others have addressed most of this, so I'm just putting in my 2 cents and not a bunch of "me too"s] (...) Ok, but that one I do have to add a "me too" :-). (...) Over any long-term average. This could be 1 ball every second, or a batch of four (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
|
43 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
