Subject:
|
Re: thoughts on gbc module reliability
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 6 Jul 2006 13:35:09 GMT
|
Viewed:
|
5604 times
|
| |
|
|
In lugnet.robotics, Brian Davis wrote:
> In lugnet.robotics, Rafe Donahue wrote:
>
> > So then there are shunts needed to allow some balls to go
> > to slow-land and some to return to fast-land, right? Is
> > this where the train comes in?
>
> In *principle*, this is one reason to have the possibility of "splitter"
> modules - you could take a 1 bps stream, and subdivide it into two streams with
> lower rates (0.5 and 0.5 bps, or even things like 0.75 & 0.25 bps, are easy to
> do mechanically). *BUT*, to do this you also need at least one module that can
> recombine, and BOTH modules need to satisfy the minimum standard of 1 bps and
> the specified input/output locations (with the possibility of others that can be
> easily switched on or off). This isn't easy, but it is possible (I've modules
> that satisfy both these constraints). But even these "odd" modules Follow The
> Standard, so they can always be used in a normal way.
> As to using the train to fix a lot of this, keep in mind that the train as a
> whole *also* has to adhere to the standard - that is, 1 bps minimum throughput
> over time. It turns out, that can actually be a pretty strict constraint,
> because the train has to stop, wait for a dump and reset, move, locate the next
> station, wait for a loading, etc. This ends up influencing the size of the cars
> as well as the number of the cars, and the number of stations that can be
> serviced. Steve Hassenplug & I went through many rounds to try to get the twined
> GBC trains functioning for the last BF.
>
> > I'm thinking this adds a certain level of complexity to the whole
> > organization process.
>
> Yes. For BF '05, the idea was four segments, some for reliable modules, and
> some for less reliable or fault-prone ones. That way when a sector went down, by
> a simple mechanical change at the loading/unloading stations, the entire sector
> could be cut from the loop for repairs. It was a simple ingenous system, with a
> huge amount of credit going to a train sensor idea that Steve had. And we both
> worked very very hard at it. And still, it never did quite live up to our
> standards. Stations had issues, multiple sectors sometimes failed at once, and
> even then the train almost did not have the excess capacity needed at times. I'm
> still not sure of a perfect solution.
Plus, one of the train motors died, which required Steve to go to the LEGO store
and buy the 4512 Cargo Train as a replacement. I also think the track was dirty
and stopped conducting well, since by the end of the weekend the volunteers were
having to help push the trains along the rails.
Overall, though, I thought the trains did a tremendous job. Without them,
shutting down part of the GBC for repairs would have been impossible.
|
|
Message is in Reply To:
 | | Re: thoughts on gbc module reliability
|
| (...) In *principle*, this is one reason to have the possibility of "splitter" modules - you could take a 1 bps stream, and subdivide it into two streams with lower rates (0.5 and 0.5 bps, or even things like 0.75 & 0.25 bps, are easy to do (...) (18 years ago, 6-Jul-06, to lugnet.robotics)
|
43 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
