Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 Jul 2006 15:45:07 GMT
|
Viewed:
|
5404 times
|
| |
|
|
In lugnet.robotics, John Brost wrote:
> In lugnet.robotics, David Hurley wrote:
> > I was wondering the exact same thing. For BF06 planning purposes, I was
> > tentatively planning on having "throughput zones" grouped according to balls per
> > second. The faster modules would be grouped together just as the slower ones
> > would be with others of similar speed. My big mama-jama module can barely do
> > .4bps on a sunny day. The junction between the faster to slower modules can be
> > regulated with what I call "leaky bucket" modules to regulate/throttle the ball
> > flow from faster modules to slower ones.
> >
> > Dave
>
> I'm not sure this is the way to do things... I don't want to seem cruel or
> anything (but I will be blunt), but this module of yours doesn't meet the GBC
> spec of 1 bps. It is your responsibility as a builder to make it fit the spec,
> not change the layout to meet your module's ability. It isn't terribly
> difficult to split the ball stream within a single GBC module. I once had a 48
> x 48 module that split the ball stream into 4 separate streams for this very
> purpose. If your module as is can't meet the 1bps spec, then something in the
> module needs to be changed. The idea of the spec was so that EVERY module could
> be put ANYWHERE in the GBC and it would all work. In the past, this has been
> bent so that modules that can't handle large batches are not placed downstream
> of a batch- output module, but overall throughput was still 1bps.
>
> In my mind, reliability is a completely different issue. Reliability specs
> aren't specifically laid out in the GBC spec (unless that has changed since I
> last looked at them), and as Rafe pointed out, getting very high reliability
> requires LOTS of testing, which some simply do not have the resources for. It
> is perfectly okay to split the GBC into high reliability and lower reliability
> zones.
>
> Just my $.02
>
> John
FWIW I do have a bypass on my module. I just have it blocked right now while I
am testing the remainder of it. My earlier post was an acknowledgement of the
difficulties that exist in meeting the minimum rate. I certainly am not trying
to make the GBC fit my needs ;) although Bunnie and I certainly wouldn't mind
helpers in the area at BF06! Currently, I have no idea whatsoever how large and
complicated this will be. A lot of people wait until the last minute to commit
on this, so planning will have to be as well. The idea of throughput zones was
mine, but if too many people find it offensive or it proves to be too
complicated, then its no biggie. Right now I haven't seen anyone commit to
anything yet, so again I am going on what I know right now. I certainly am in
favor the standard being implemented. I just don't want to be a "ball nazi":"No
GBC for you!"
Dave H.
|
|
Message has 1 Reply:
 | | Re: thoughts on gbc module reliability
|
| (...) I don't think it's a question of being offensive. It's simply a question of how it would work. The "Leaky Bucket" analogy only works if all modules can handle the same average throughput over an extended period of time. Otherwise, the "bucket" (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: thoughts on gbc module reliability
|
| (...) I'm not sure this is the way to do things... I don't want to seem cruel or anything (but I will be blunt), but this module of yours doesn't meet the GBC spec of 1 bps. It is your responsibility as a builder to make it fit the spec, not change (...) (18 years ago, 6-Jul-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
|
|
|
|
