|
|
| |
Having to trouble shoot a Dell Inspiron 1100 not booting up cleanly. An alarm
goes off and it goes to safe boot mode. I am running the original Home version
of XP without updates and RoboLab 2.94. Keeping the 2007 working original
program until new application arm is working. Side arm needs to come in and heat
up surface where oil pastel dot is applied and move aside for the application
wheel to rotate to the color and move down to apply the dot. Thinking it will be
a side arm where the heating box flips down, moves into dot area for allotted
time then out. http://tomlohre.com/lego.htm
|
|
| |
I am back on the Lego wagon, making another painting machine. Looking forward to
creating the best practices program with your advising.
|
|
| |
In lugnet.robotics.rcx, Iain Hendry wrote:
> BrixCC doesn't recognize "wait1Msec", and when I try to download a program with
> it, it just gives me an error.
>
> That's kind of what I was getting at with the motor power stuff; I can tell the
> RCX can handle more motor powers, but there doesn't appear to be a way to use
> them in the program...
D'oh...
I'm posting this because I'm sure I'm not the only one who missed this: I
didn't realize there's a drop-down when BricxCC starts up, to select "Swan"
instead of "RCX" when making the first handshake with the brick.
After doing that, it compiles no problem. MotorSetPower128 doesn't seem to
work, though...
At any rate, WaitMS() is great! Super-precision motor control, here I come!
http://www.youtube.com/watch?v=kZlBlbe2cu0
-Iain
|
|
| |
In lugnet.robotics.rcx, Jetro de Chateau wrote:
> > I found this site: http://www.elenafrancesco.org/old/lego/index.html
> Thanks for the link!
(snip)
> The documentation on this page
> http://www.elenafrancesco.org/old/lego/Firmware%20Features.html mentions the
> following:
>
> "new wait1Msec opcode to perform program waits using one millisecond resolution"
>
> Maybe that is what you are looking for.
BrixCC doesn't recognize "wait1Msec", and when I try to download a program with
it, it just gives me an error.
That's kind of what I was getting at with the motor power stuff; I can tell the
RCX can handle more motor powers, but there doesn't appear to be a way to use
them in the program...
-Iain
|
|
| |
In lugnet.robotics.rcx, Iain Hendry wrote:
>
> I found this site: http://www.elenafrancesco.org/old/lego/index.html
Thanks for the link!
> After downloading the 100x firmware, I can tell that it is a different firmware
> (different clock, tone on button press is different, etc.) - however, it seems
> like I just can't unlock this 1/1000 sec. timer issue. Wait(1); still results
> in a 1/100 second delay.
>
> I found some reference to a "WaitMS" command in the NQC programming guide,
> however, if I enter "WaitMS(1);" I get a "Error: Undefined function 'WaitMS'"
> whenever I try to compile. BrixCC recognizes the WaitMS command (it turns blue
> when I type it), so it must be valid...
>
> I'm not a programmer. I just want a 1/1000 wait :)
>
> -Iain
The documentation on this page
http://www.elenafrancesco.org/old/lego/Firmware%20Features.html mentions the
following:
"new wait1Msec opcode to perform program waits using one millisecond resolution"
Maybe that is what you are looking for.
|
|
| |
In lugnet.robotics.rcx, David Koudys wrote:
> I have it and use it exclusively. i'll mail you a copy when i get your e-mail
> sddess
Hi Dave,
Thanks - I tried to send you a note, but your email bounced...
I found this site: http://www.elenafrancesco.org/old/lego/index.html
After downloading the 100x firmware, I can tell that it is a different firmware
(different clock, tone on button press is different, etc.) - however, it seems
like I just can't unlock this 1/1000 sec. timer issue. Wait(1); still results
in a 1/100 second delay.
I found some reference to a "WaitMS" command in the NQC programming guide,
however, if I enter "WaitMS(1);" I get a "Error: Undefined function 'WaitMS'"
whenever I try to compile. BrixCC recognizes the WaitMS command (it turns blue
when I type it), so it must be valid...
I'm not a programmer. I just want a 1/1000 wait :)
-Iain
|
|
| |
In lugnet.robotics.rcx, Iain Hendry wrote:
> Hi all,
>
> One of the common ways I like to control the speed of a gearmotor (in NQC) is by
> introducing a loop, for example, like this:
>
> while(true)
> {
> OnFwd(motor);
> Wait(a);
> Off(motor);
> Wait(b);
> }
>
> I often do this as a motor approaches a setpoint (say an offset from a target
> position as measured by a rotation sensor) or the like. Variable a and b could
> be defined somewhere else but usually are around 1/100 or 2/100 of a second.
> Any more than that and the motion gets jittery. I sometimes swap out Off for
> Float, depending on the application (unloaded the motors tend to glide right
> through the Float, however).
>
> I seem to remember hearing someone (Dick Swan?) built some Firmware a while back
> that ran much faster and allowed for 1/1000 second (millisecond) intervals for
> the Wait command, instead of 1/100 (decisecond). Any truth to that?
I have it and use it exclusively. i'll mail you a copy when i get your e-mail
sddess
Take care,
Dave K
>
> Obviously if I could cut down the time delay, the sawtooth of "On" to "Off" gets
> a lot crisper and the whole thing would work a lot better.
>
> Thanks in advance,
>
> -Iain
|
|
| |
Hi all,
One of the common ways I like to control the speed of a gearmotor (in NQC) is by
introducing a loop, for example, like this:
while(true)
{
OnFwd(motor);
Wait(a);
Off(motor);
Wait(b);
}
I often do this as a motor approaches a setpoint (say an offset from a target
position as measured by a rotation sensor) or the like. Variable a and b could
be defined somewhere else but usually are around 1/100 or 2/100 of a second.
Any more than that and the motion gets jittery. I sometimes swap out Off for
Float, depending on the application (unloaded the motors tend to glide right
through the Float, however).
I seem to remember hearing someone (Dick Swan?) built some Firmware a while back
that ran much faster and allowed for 1/1000 second (millisecond) intervals for
the Wait command, instead of 1/100 (decisecond). Any truth to that?
Obviously if I could cut down the time delay, the sawtooth of "On" to "Off" gets
a lot crisper and the whole thing would work a lot better.
Thanks in advance,
-Iain
|
|
| |
Matthew Sheets wrote:
> The Bibo Patch Rollup Collection posted to SourceForge at
> http://sourceforge.net/tracker/?func=detail&aid=2773502&group_id=58151&atid=486699
> has been updated.
Excellent, Matthew. Many thanks for keeping the project alive and moving
forward.
I've uploaded a little patch with the edge counting (which I needed once
upon a time when I tried to build a plotter without any rotation sensors)
re-implemented in a more sensible way. Here:
https://sourceforge.net/tracker/?func=detail&aid=3527703&group_id=58151&atid=486699
I'm currently working on figuring out all the little quirks of the power
functions protocol (such as what happens with the toggle bit state for
commands where the toggle bit is ignored). Once I have it fully working,
I'll release a patch with power functions control based on Bob Kojima's
code but updated to match the latest PF specification.
Cheers,
//Carl
|
|
|
