Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 29 Jun 2006 22:04:28 GMT
|
Viewed:
|
3597 times
|
| |
|
|
[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.
--
Brian Davis
|
|
Message has 2 Replies:
 | | Re: thoughts on gbc module reliability
|
| (...) This brings me to a question: is there any restriction on bringing last year's modules to this year's Brickfest? On one hand it seems like that could make it even bigger (!) but on the other hand we want some new stuff, right? Thoughts, (...) (18 years ago, 29-Jun-06, to lugnet.robotics)
| | | Re: thoughts on gbc module reliability
|
| (...) 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 (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
Message is in Reply To:
| | thoughts on gbc module reliability
|
| All GBCers, This will likely be a long post, so be forwarned. It contains some rambling thoughts on development and reliability of GBC modules. Now that I have started writing, I'm not sure exactly where this is headed, but I have this need to try (...) (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
