Results 6 10 of about 2800.
|
Search took 0.00 CPU seconds.
|
|
|
I can't seem to find it now, but not long ago someone posted some Ldraw-type
pics of the impossible to disassemble technic cube that had clear beams and
a light blue background that would make very nice wallpaper.
|
|
|
| impossible, disassemble (score: 3.012) |
|
|
I have problems with two seized electric motors 71427 which come with 8479 sets.
It is impossible to rotate shafts with bare fingers. Could anybody give me
detailed guidelines how to safely disassemble them to clean or to repair them?
Please, help me!
|
|
|
| impossible, disassemble (score: 3.002) |
|
|
PeterBalch wrote:
> Kyle
>
>
> > What I thought was harder, was that the PC programming software wouldn't
> > easily be able to tell How many motors you have or how many sensors.
>
>
> Plug-And-Play works well under Windows (at least, it does under XP).
You mean 'plug and pray' don't you?? ;)
> The chip on the sensor or motor can say what it is - an ASCII string that
> says 'motor' or 'servo' - and who it is - a unique id like 2908347525.
This is one way. Yes.
I never claimed that this was an impossible problem to solve. And
I agree that for you and I who have experience in the computer
programming field (I know I work in that field I don't know about you?)
These solutions are obvious, logical and easy to work with.
My only claim was that it would be tough (not impossible - just not
trivial) for LEGO to be able to modify the current graphical programming
environment to work in such an open ended system without forcing
the kids to learn about things like Unique identifiers, and virtual
device name mappings.
>
> The cpu "brick" uses the id number to address to peripheral - not the
> peripheral's position on the bus.
All I was saying was that both solutions are possible. If you want to
avoid having to think about ID's and mappings, then a possibly simpler
solution might be to assign ID's based on connection order. I was
mainly just pointing out that both solutions (like solutions to almost
any problem) have their trade-offs. Pros, Cons. And I believe that
neither one has an obviously better solution for the basic type of
programming environment that LEGO would like to deliver 'out of the
box'
>
> > Without some type of marking on the outside
> > of the motor though (maybe LEDs that the software could light up?) it'd
>>be hard to make sure you and the PC environment are talking about the
>>same motor/sensor without having to enter long numbers.
>
> You come home from the shop with your brand new motor. You plug it into
> your cpu "brick" and plug the cpu into your PC. You select the PC menu
> command New Hardware. The PC talks to the cpu, the cpu talks to the bus and
> asks everyone whose attached to identify themselves. The PC sees the new
> motor and says 'You've got a new "motor". What do you want to call it'. You
> take a felt-tip and write on the motor "XYZ" then tell the PC 'It's called
> "XYZ"'. From now on, the PC always refers to that motor as XYZ. No-one need
> ever see the long id number 2908347525.
Ok what if I have 3 new motors?
Maybe 'entering' was the wrong word. Either you have to print the number
on the outside of the motor, and at least read it there and on the
screen to see which one is which, or possibly the software lights one
up (or makes it spin but that can cause problems) at at time and
you name them that way.
One solution is to plug them all in one at a time to name them. That's
not always practical, what if I'm an 8yr old who built a cool robot
and programmed it at home and brought it to my friends house and we
want to reprogram it? I'd hate to have to disassemble it just to be
able to plug each motor (which his PC hasn't seen yet) in one at a
time.
> It's all straightforward stuff and the sort of thing that comms programmers
> do every day.
All the things you describe are fine and easy for people like you and
me that want to use NQC or BrickOS. We're familiar with these concepts.
'comms programmers' are familiar with all this stuff.
8yr olds aren't.
Again, I never claimed that this wasn't something that one of us
as a hobbyist couldn't design or handle. I was trying to discuss the
problems LEGO would have to overcome to feel comfortable marketing
a product like this to children. They'd need to feel that they had
made it simple and unfrustrating enough for the children and beginners
that they were selling it to to even bother trying to make a product
like this.
>
> > Debugging embedded software isn't easy, even in the current RCX. While
> > I think the added flexibility from this type of design would be great,
> > I also think it is a potential source of frustration for the kids who
> > don't have a strong programming background. This I think it's a huge
> > challenge for the Programming environment developers to try to ease
> > that frustration.
>
>
> Yes. That is the huge challenge. Lego did a wonderful job with the
> Minstorms programming language. It introduces you to real-time embedded
> programming in a tremendously gentle way. But then you find it's so
> limiting. And runs so slowly.
And even with the nice environment they provide it is still very easy
to create race conditions and unreachable code blocks, and still *very*
hard to debug those types of things. But then again Debugging itself
is never easy... (anyone who can make it simple could become rich over
night!)
> I think a graphical language is the ideal for beginners and there is no
> reason why such a language shouldn't have all the power of a textual
> language.
I agree that a graphical language can have the power of a textual one.
I'm not sure that if it did, it would still be as useful to beginners
though. power almost always brings at least some complexity.
> Does anyone have any references to research done on graphical programming
> languages for children?
I don't, no.
-Kyle
--
_
-------------------------------ooO( )Ooo-------------------------------
Kyle J. McDonald (o o) Systems Support Engineer
Sun Microsystems Inc. |||||
Enterprise Server Products Kyle.McDonald@Sun.COM
1 Network Drive BUR03-4630 \\\// voice: (781) 442-2184
Burlington, MA 01803 (o o) fax: (781) 442-1542
-------------------------------ooO(_)Ooo-------------------------------
|
|
|
| impossible, disassemble (score: 3.001) |
|
|
Thanks to all who made me feel so welcome at my first
BF.
I especially want to thank Kevin Clague, who calming
presence kept me from going ballistic when I learned
we couldn't disassemble the instruction books for
the timed 8421 crane build.
But we still set a record on it anyway: 1:48:14, over
seven minutes better than the German team's time.
The build team was Randall Crabtree, Ondrew Hartigan,
Augie Thiesing, Kevin and myself. I worked with
Ondrew on the cab and boom; he is the fastest builder
I've come across.
Then I got my ABS butt kicked in the mega-sumo robot
contest by Steve Hassenplug and Bryan Bonahoom. Oh
well, it was just my second sumo design, I'll do
better next time.
The breadth and depth of building skill in the model
displays is impossible to describe. I think I got
pictures of everything (over 600 photos), so maybe
I'll learn something after I've digested it all.
And I got to give Kjeld a brief personal thank you
for all the good things Lego toys have done for me.
I came home completely exhausted, but it was the
most sheer fun I've had in many years. I hope to
see y'all again!
|
|
|
| impossible, disassemble (score: 3.000) |
|
|
In lugnet.pirates, Bruce Schlickbernd writes:
> [snip]
> ... Loonies at auczilla have paid as much for a ... backpack
> as I do for the entire figure.
Now, wait a second, I'm one of those so-called loonies,
and I'd like to object (just as soon as I can figure out
how to get out of this straightjacket ;-)
The reason I was willing to pay a rather high price
on AucZilla for some of those Backpacks,
and the reason I'd (probably) do the same
for some Shako Hats, is that once I get a Trooper minifig,
whether Redcoat or Bluecoat, I'm not disassembling him!
("No disassemble! No disassemble!" -- trivia points
if you can give movie reference ;-)
Thus, if I'm not gonna disassemble a complete Trooper 'fig
(notice that I did *not* mention the Officer/Lieutenant 'figs...),
then the only way to get extra backpacks and/or shako hats
is to get them from other sources.
Now, you may ask *why* would I need extra shako hats,
and the answer is rather simple: I have *extra* Troopers
that are only *partially* complete; i.e., they're missing
their shako hats. (And, no, not quite all of them
started out as surplus Lieutenants... some of them, yes,
perhaps even *several*, but not quite *all* of 'em...)
And, as far as the backpacks go,
I'd like to be able to use brown backpacks with some
of my custom kit-bashed (modern/near-future) military 'figs.
I also use the dark grey backpacks (from the SW Speeder Bike sets),
but the military 'figs I make using dark grey torsos
look a whole lot better with a brown backpack
than with a dark grey backpack.
Thanks,
Franklin
|
|
|
| disassemble (score: 1.912) | More: Next Page >>
|