 | | 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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
|
|
(...) 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)
|
| |
| | Re: thoughts on gbc module reliability
|
|
John Brost writes: > 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- (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
| |
| | Re: thoughts on gbc module reliability
|
|
(...) If I understand what you mean, yes, you can make an arrangement of modules that satisfys the GBC spec input/output as a whol, even though they don't individually. That's fine (like Rafe's "supermodule", for instance). But then the individual (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
