To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 23262
23261  |  23263
Subject: 
Re: The Great Ball Contraption
Newsgroups: 
lugnet.robotics
Date: 
Fri, 7 Jan 2005 20:11:28 GMT
Original-From: 
TMASSEY@OBSCORP.spamlessCOM
Viewed: 
6324 times
  
"Brass Tilde" <brasstilde@insightbb.com> wrote on 01/07/2005 01:52:19 PM:

To clarify--are we allowed to use 2 'module spaces' if
we want?

   Really, the only thing defining a "module space" is a flat L & R • edge,
and no part of the module extending more than 32 studs from the front
edge of the input bin "zone" - the footprint need not be remotely
rectangular, nor is there a set

   Right Now, the idea is a "linear" standard, but obviously we're
thinking (& building!) beyond this. But we're trying to stick to
the linear standard so that we can ensure *every* builder can • participate.

I'll point out that the standard as it's defined pictorially allows for • a
non-linear layout just as it stands.  As long as the input in in the • correct
place relative to the previous block's output, and the output is placed
correctly relative to the next module's input, you can have the input • and
output on any side of the 32 stud square you want.

While what you're saying will work fine, the standard does say:

Each module should have an "in" basket, and will move balls to the next
module's "in" basket, which must be directly in line.

It also says:

The In basket should be located on the left side of the module, and output
should go to the right.

So the standard *does* specify a lineary progression.  Of course, there's
no reason why you couldn't have 4 "non-standard" modules designed for a 90
degree bend to act as corners...  But the standard does specify linearity.

An aside:  Depending on how rigorous you want this standard to be, I would
think that you might want to specify exactly how much clearance must be
left around the in basket so that each module is compatible.  For example,
should that entire vertical column be left free?  Or only to a certain
height?  Should extra width be reserved around the in basket to allow
space for some sort of container to fit over the basket with room for,
say, tipping?

Tim Massey



Message has 1 Reply:
  Re: The Great Ball Contraption
 
(...) In addition, there's an actual *reason* why that is set up that way. Can you picture trying to set up a large scale GBC if we need a certain number of "turns" and "straights"? There could also be interference issues if the rear of the GBC line (...) (20 years ago, 7-Jan-05, to lugnet.robotics)

Message is in Reply To:
  Re: The Great Ball Contraption
 
(...) I'll point out that the standard as it's defined pictorially allows for a non-linear layout just as it stands. As long as the input in in the correct place relative to the previous block's output, and the output is placed correctly relative to (...) (20 years ago, 7-Jan-05, to lugnet.robotics)

94 Messages in This Thread:



































Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR