 | | Re: thoughts on gbc module reliability —David Hurley
|
| | | (...) 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 (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
| | | |
| | | | | Re: thoughts on gbc module reliability —Steve Hassenplug
|
| | | | (...) 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)
|
| | | | |
| | | | | | Re: thoughts on gbc module reliability —Anders Isaksson
|
| | | | (...) What about a 'splitter' with two outputs (nominally 0.5 bps/output) and a 'joiner' for combining the two streams later on? (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| | | | |
| | | | | | Re: thoughts on gbc module reliability —Brian Davis
|
| | | | | (...) That works, but it's not as simple as it sounds. Keep in mind with all the below, it *can* be made to work: I'm not nearly as negative as I seem below :-). First, you need a splitter and combiner that... (a) work At Least as well as a "normal" (...) (18 years ago, 7-Jul-06, to lugnet.robotics)
|
| | | | | |
| | | | | | Re: thoughts on gbc module reliability —David Hurley
|
| | | | (...) 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 —Steve Hassenplug
|
| | | | | (...) 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 —David Hurley
|
| | | | | | (...) 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 —Steve Hassenplug
|
| | | | | | | (...) 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 —Brian Davis
|
| | | | | | | | | (...) 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 —David Hurley
|
| | | | | | | | (...) <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 —Brian Davis
|
| | | | | | (...) 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 —Brian Davis
|
| | | | (...) 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 —David Hurley
|
| | | | (...) 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)
|
| | | | |
