Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 7 Jul 2006 18:22:10 GMT
|
Viewed:
|
6124 times
|
| |
|
|
In lugnet.robotics, David Hurley wrote:
> we might try is to implement this splitter at the junction of the
> throughput zones to catch any ball overflow from the leaky bucket
> module. Then this shunted ball flow could be loaded onto several
> train cars and haulled around the track to the high zone side.
Or to put it another way, use a GBC train system to handle 0.5 bps at a
splitter module, so that downstream of the splitter the thinned stream would be
0.5 bps. This would seem to require (a) a dedicated train (& room for it), (b) a
splitter module that can *also* load, and (c) a combiner module that can *also*
unload. I've built the second, and I can see ways to build the first... but
that's still a lot of special infrastructure to run a low-throughput section.
Heck, if we had that set-up, I'd use this train by-pass to produce a
higher-throughput, not lower throughput, section (a downstream splitter/loader
feeds a train that hauls the balls back upstream to an unloader/combiner,
recycling a portion of the high-throughput ball stream through the
high-throughput sector).
> Another idea I thought of was that last year's BF contraption
> probably wasn't running at full capacity due to the slower/problem
> modules.
True, but in a sense it will always be true - a community GBC will always be
limited by the operation of the slowest/weakest module. Several modules did have
built-in abilities to handle excess balls, allowing the stream to be impounded
or bled out (if needed) to accomodate balky or faulty downstream modules. This
actually worked fairly well.
> This would reduce the frequency of hopper overflow in this
> scenario.
I'm not sure I understand this. Can you explain? If a module goes down and
the GBC keeps running, all you need to do is manually catch the balls from the
module just upstream of the broken one. No hoppers overflow (except, perhaps,
the one of the broken module, and I don't see how a by-pass would help this).
> However we do it, we need a plan for ball flow regulation...
We did - that's why there's a section in the standard that demands a module
meet the 1 bps throughput requirement, and why one of the modules in a GBC
always has an adjustable rate, to act as a "clocking" module. If the clocking
module outputs 1 bps, then all the other modules (even if they can handle faster
throughputs than this) will also be regulated to 1 bps.
> I have a couple more ideas than this.
Like what?
--
Brian Davis
|
|
Message has 1 Reply:
 | | Re: thoughts on gbc module reliability
|
| (...) I recall reading about Steve's ideas of sectors to handle downed modules. Is this a given or some optional aspect? I would think it would be mandatory. I think at this point, I'm going with the KISS plan, but I'm trying to learn as much as (...) (18 years ago, 8-Jul-06, to lugnet.robotics)
|
Message is in Reply To:
| | Re: thoughts on gbc module reliability
|
| (...) Another thing we might try is to implement this splitter at the junction of the throughput zones to catch any ball overflow from the leaky bucket module. Then this shunted ball flow could be loaded onto several train cars and haulled around (...) (18 years ago, 7-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
|
|
|
|
