Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 8 Jul 2006 01:36:09 GMT
|
Viewed:
|
6321 times
|
| |
|
|
In lugnet.robotics, Brian Davis wrote:
> 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).
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 possible here...I have a tendency to make simple things harder than they
need to be.
>
> > I have a couple more ideas than this.
>
> Like what?
See http://news.lugnet.com/robotics/?n=26231 from Steve. I had three proposed
ideas. I'm glad they were theoretical at this point because it's obvious to me
(and probably everyone reading this thread) that I'm going through some of the
same problems you guys did over the past couple years. I guess this
conversation can also help out other "newbies" like myself. Although I'd like
to think that I've graduated beyond that moniker.
I know I can rest a little easier knowing that the veteran gbc guys will mostly
be there to spread their experieces to those of us who have no MUG to speak of!
I guess at this point I am wondering if there is an improvement in ball flow
control that SHOULD be addressed, and whether or not it's similar to what I have
already proposed....? Is there a need for a better "clocker" module?
> > This would reduce the frequency of hopper overflow in this
> > scenario.
I was basically describing the case where you might have to slow down the
clocker module to accomodate slower modules. This would give you more time to
compensate in an overflowing bucket situation to adjust the variable lift output
up or down.
Dave
|
|
Message is in Reply To:
 | | Re: thoughts on gbc module reliability
|
| (...) 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 (...) (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
|
|
|
|
