Subject:
|
RE: RCX & Cybermaster (VLL comms and MicroScout)
|
Newsgroups:
|
lugnet.technic, lugnet.robotics
|
Date:
|
Tue, 20 Mar 2001 11:16:16 GMT
|
Reply-To:
|
<marco@soporcelANTISPAM.pt>
|
Viewed:
|
1350 times
|
| |
|
|
> -----Original Message----- • [snip]
> In lugnet.technic, Marco Correia writes:
> > Hi Chris,
> >
> > Do a search for "CM-RCX Comm" thread, in lugnet.robotics :) • [snip]
> Thx, Marco. I'm investigating! btw, Do you mean that they communicate
> through a standard lead attached to sensor inputs, say, or some other
> electrical connection?
Yep, besides using the "normal" Light->LightSensor type of comms, the direct
electric connection is possible too, by using NQC's Off() and Float()
commands, you simulate the ON/OFF state of a TouchSensor. This way, it's
possible to use a connection through a standard lead attached between a
(motor) OUT-port and a (sensor) IN-port
Be careful not to use any OnFrw() or OnRev() type of commands, because that
would send a 9Volt signal through the IN-port, and that's not good.
(well... by accident, I did that once, and thankfully nothing happened to
the in-port of my CyberMaster. Nevertheless, it's not a wise thing to do ;)
> Interesting that the CM can't communicate at speed, but the MS & CP will.
Well... IMHO all bricks (MS, CP, *CM*, RCX) have a CPU fast enough to deal
with Standard VLL input. The thing is that, MS & CP have "special" firmware
routines to do just that, VLL input/Barcode reading.
My feeling is that, with a bit of more time and tweaking, I could make the
CM deal with standard VLL input too, but I didn't have the time to think of
an alternate method besides using Timer() to measure the difference between
VLL pulses.
One alternate method would use a simple n++ counter. IT would first do a
self-calibration by measuring the time it takes n to reach a certain value,
it could correlate it to a 1/100 second and then, instead of using Timer()
and because CM doesn't have FastTimer(), I'd use some sort of a loop with
n++ in code.
I think this isn't precise enough, because it depends of the ticks the CM
CPU dedicates to the loop measuring the time between pulses.
erm... forgive my bad english (I'm portuguese) but I think it's enough to
give you an idea of what could be done. For now, after making it work (that
was a major step for me) I'm trying to make a NQClib small enough to fit in
CM's memory and give *at least* SlowVLL input/output and a few spare bytes
for some simple roverbot coding (or a simple message passthrough system
between the PC and RCX).
If, on top of that, I can implement Standard VLL output, fine, but I don't
have many projects that take advantage of a CyberMaster->CodePilot or a
CyberMaster->MicroScout. The projects I have in mind, all use a
CyberMaster<->RCX->CodePilot (but, because I can't get a cheap CodePilot
anywhere, I'll have to use a CyberMaster<->RCX->MicroScout setup instead).
> I'd noticed the lack of memory in the CM also - it
> doesn't hold a very long period of recorded motion.
Have you tried using NQC on CyberMaster instead of the included LEGO
software ?
> Unfortunately, I'm suffering from that lack of hobby time also :^(
Don't we all :(
> but I'm probably also trying to bite off more than I can yet
> chew on this one!
>
> Chris.
Feel free to add any new info on this subject, using this thread :)
mc.
|
|
Message is in Reply To:
6 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
