 | | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I guess I don't understand what you mean by a leaky bucket module. I'm imagining something that would work well for "smoothing" the flow, but it will require the output to match the average input. (...) Last year, one section of the GBC was (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) I have three designs on paper for leaky bucket modules. The basic version of what I had in mind was a simple large hopper to receive balls from either the faster modules, the train, or both. The output would be a simple lifter, which was run (...) (18 years ago, 7-Jul-06, to lugnet.robotics, FTX)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) David, Sorry I can't explain this very well, but the leaky bucket will not provide an acceptable interface between the fast & slow modules, like you're suggesting. Steve (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) This is what Steve and I call "clocker" modules, and they have always been present. Here's a good example of Steves: (URL) can also redirect the output to a number of directions and heights. Very useful, in fact critical for the trains, as (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) A simple explaination: the rate in must equal the rate out, or the bucket overflows. Period. (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) <sigh> This is why one of designs I mentioned had a second, variable output. One in::two out. If the input rate was say 3 bps, then the two outputs would be equal to 3 (in this case) 1bps and 2bps. I didn't give a very detailed explanation of (...) (18 years ago, 8-Jul-06, to lugnet.robotics)
|
| |
| | 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)
|
