|
|
| |
In lugnet.robotics.rcx.nqc, Dennis Clark wrote:
> Hello with a query from the past...
Funny I'm tripping over this just today...
> I used MacNQC for ages on other computers but I find now that I can't
> write a program out to an RCX 1.0 brick using MacNQC 3.04 or 4.05b. I
> can send the firmware with no problem but when I try to download a
> program I get a "communications error" type of message every time. This
The most weird thing happened to me today on my iMac - I've only dug out the old
Mindstorms stuff last weekend and went through reviving cybermaster and
Spybotics - and guess what, the RCX and IR Tower failed me as well. I have
finally managed to download a simple program again after reloading the firmware
_twice_ to an old 1.0 RCX (it's the 2.0 firmware, though).
Comms seem to work now, but for sake of completeness I have just loaded a second
RCX.
Strikingly, both seemed to require a reload of the firmware first but still want
to be talked to as an RCX rather than RCX 2.
> is with either the USB tower or a regular serial tower through a
> USB/serial dongle. I'm using a 1.33GHz G4 running Tiger 10.4.6. Has
> anyone else seen this and know what critical step that I'm missing?
Can't say really - one major problem with MacNQC seems to be that it is still a
Rosetta application - a UB build would be nice to come by but apparently not
much is happening about MacNQC anymore.
I've tried two USB towers and a serial w/ dongle now (it _had_ to work as
Spybotics and cybermaster talk just fine) - before firmware refresh -> no use.
After firmware refresh -> all fine.
I'll have an eye on it, the kids are keeping me busy to program their models
(I'll have to show them the ways anytime soon).
Regards,
Jerry
|
|
| |
I have updated the earlier NQC patch and uploaded two additional patches.
Patch 1 - Update of the NQC USB and TCP Patch
http://sourceforge.net/tracker/?func=detail&aid=2639763&group_id=68600&atid=521778
* Updated for compatibility with gcc 4.4.x
* Removed the DESTDIR patch for the Makefile (moved to another patch)
Patch 2 - Support Makefile Variables DESTDIR and TOOLPREFIX
http://sourceforge.net/tracker/?func=detail&aid=2833299&group_id=68600&atid=521778
* Added support for the Makefile variables DESTDIR and TOOLPREFIX,
enhancing compatibility with distro packaging tools
Patch 3 - Enable Setting a Default Port Name in a Configuration File
http://sourceforge.net/tracker/?func=detail&aid=2833359&group_id=68600&atid=521778
* If no port is specified on the command line (the "-S" argument) and if
the environment variable RCX_PORT is not defined, NQC on Linux will then
check for a default device name in the following configuration files (in
order):
1) ~/.rcx/device.conf
2) /etc/rcx/device.conf
These configuration files are designed to be compatible with Bibo, as
patches have been created for Bibo to allow it to process port names that
are specified in the NQC format. Due to limitations with environment
variables, there is a need to have an alternate means for specifying a
default port.
Thank you,
Matthew
--------------------------------------------
Matthew Sheets <mesheets@hotSPAMMERmail.com> wrote in message
news:KGBJK3.IBu@lugnet.com...
For those interested, I have posted a patch to SourceForge for NQC at
http://sourceforge.net/tracker/index.php?func=detail&aid=2639763&group_id=68600&atid=521778 .
This patch includes several changes, most of which are related to Linux,
though portions may be of use to other platforms.
* Removed the dependency of <LegoUSB/legousbtower.h> when building with USB
support for Linux
* Set some properties so that they can be set from the "make" command line
instead of modifying the Makefile, facilitating easier package creation
(including DEFAULT_SERIAL_NAME and DEFAULT_USB_NAME).
* Now that the Lego USB tower driver is included in the kernel, the device
is typically either /dev/legousbtower0 or /dev/usb/legousbtower0. The code
files have been updated to reflect these names.
* If the NQC "-S" argument is in the format "usb[:<device>]" (e.g.
usb:/dev/lego0), the program will use /dev/lego0 as the USB device; if the
"-S" argument is simply "usb" then the program will check for the presence
of DEFAULT_USB_NAME, /dev/legousbtower0, or /dev/usb/legousbtower
* A "tcp" option has been added as an option to the "-S" argument,
performing communication over a TCP connection instead of a serial or USB IR
device. This facilitates the use of NQC with programs such as BrickEmu, an
RCX emulator (see http://hoenicke.ath.cx/rcx/brickemu.html ). The full
option format is "tcp[:<host>[:<port>]]" If port is not provided, the
program will default to the "magic" Lego port of 50637, and if the host is
not provided, the program will default to localhost.
I hope that some of this might be useful for a future release. If there is
a future release, I would also like to propose that the source archive be
packaged more GNU-style, in that the root of the archive would only contain
a single folder named in the format $PACKAGE-$VERSION (e.g. nqc-3.1r7). All
the source content would then be under this folder, easing some package
management tasks for certain distributions.
Thank you,
Matthew
|
|
| |
Hello with a query from the past...
I used MacNQC for ages on other computers but I find now that I can't
write a program out to an RCX 1.0 brick using MacNQC 3.04 or 4.05b. I
can send the firmware with no problem but when I try to download a
program I get a "communications error" type of message every time. This
is with either the USB tower or a regular serial tower through a
USB/serial dongle. I'm using a 1.33GHz G4 running Tiger 10.4.6. Has
anyone else seen this and know what critical step that I'm missing?
I've posted to LUGNET, but it takes forever for a non-member's post to
show up there apparently, so I'm taking a stab at the robot crew at
large here. Any ideas?
thanks,
DLC
|
|
| |
For those interested, I have posted a patch to SourceForge for NQC at
http://sourceforge.net/tracker/index.php?func=detail&aid=2639763&group_id=68600&atid=521778 .
This patch includes several changes, most of which are related to Linux,
though portions may be of use to other platforms.
* Removed the dependency of <LegoUSB/legousbtower.h> when building with USB
support for Linux
* Set some properties so that they can be set from the "make" command line
instead of modifying the Makefile, facilitating easier package creation
(including DEFAULT_SERIAL_NAME and DEFAULT_USB_NAME).
* Now that the Lego USB tower driver is included in the kernel, the device
is typically either /dev/legousbtower0 or /dev/usb/legousbtower0. The code
files have been updated to reflect these names.
* If the NQC "-S" argument is in the format "usb[:<device>]" (e.g.
usb:/dev/lego0), the program will use /dev/lego0 as the USB device; if the
"-S" argument is simply "usb" then the program will check for the presence
of DEFAULT_USB_NAME, /dev/legousbtower0, or /dev/usb/legousbtower
* A "tcp" option has been added as an option to the "-S" argument,
performing communication over a TCP connection instead of a serial or USB IR
device. This facilitates the use of NQC with programs such as BrickEmu, an
RCX emulator (see http://hoenicke.ath.cx/rcx/brickemu.html ). The full
option format is "tcp[:<host>[:<port>]]" If port is not provided, the
program will default to the "magic" Lego port of 50637, and if the host is
not provided, the program will default to localhost.
I hope that some of this might be useful for a future release. If there is
a future release, I would also like to propose that the source archive be
packaged more GNU-style, in that the root of the archive would only contain
a single folder named in the format $PACKAGE-$VERSION (e.g. nqc-3.1r7). All
the source content would then be under this folder, easing some package
management tasks for certain distributions.
Thank you,
Matthew
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
>
> Um... I'm sorry, planes flying overhead. :) I literally am on the cusp of
> understanding programming; I just learned what an array was at our last rtl
> event. :)
What I said had less to do with programming as it had to do with understanding
your new Linux-based PC. Do you know how to use Linux from a command prompt?
Can you open a terminal window on your eeePC and type "gcc" and see what
happens?
I googled a bit and it looks like eeePC uses a Xandros 4 distribution. Googling
"Xandros NQC" makes it look like there could be a package available in the
Xandros distro for NQC. You'd need to install that package. From my googling
it appeared that people have had to install gcc manually before they could build
packages from source code.
Send me an email if you want me to send you an already compiled NQC executable
that you can try out on your eeePC.
John Hansen
|
|
| |
In lugnet.robotics.rcx.nqc, John Hansen wrote:
> Normally people build NQC from sourcecode for Linux platforms so there has not
> been a binary release for Linux in the past. Does the eeePC include all the
> standard GNU development tools such as yacc, flex, and GCC? If it does then you
> can probably build NQC yourself after downloading the sourcecode from the NQC
> website
>
> http://bricxcc.sourceforge.net/nqc/
>
> If it doesn't include those tools perhaps they can be added via download? If
> not, I could build you a binary for an x86 architecture (which I believe is what
> the eeePC uses).
Um... I'm sorry, planes flying overhead. :) I literally am on the cusp of
understanding programming; I just learned what an array was at our last rtl
event. :)
-Iain
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
> No, the eeePC runs Linux, with a custom-designed interface over top by ASUS.
> So, I was wondering if NQC is available for Linux.
Normally people build NQC from sourcecode for Linux platforms so there has not
been a binary release for Linux in the past. Does the eeePC include all the
standard GNU development tools such as yacc, flex, and GCC? If it does then you
can probably build NQC yourself after downloading the sourcecode from the NQC
website
http://bricxcc.sourceforge.net/nqc/
If it doesn't include those tools perhaps they can be added via download? If
not, I could build you a binary for an x86 architecture (which I believe is what
the eeePC uses).
John Hansen
|
|
| |
In lugnet.robotics.rcx.nqc, Jetro de Chateau wrote:
> Is it Windows based? If so, have you tried installing BricxCC?
Hi Jetro,
No, the eeePC runs Linux, with a custom-designed interface over top by ASUS.
So, I was wondering if NQC is available for Linux.
-Iain
|
|
| |
In lugnet.robotics.rcx.nqc, Iain Hendry wrote:
> Hi all,
>
> I have an ASUS eeePC, and was wondering if anyone knew of a way to get NQC onto
> it so I could program my RCX with it?
>
> Thanks!
>
> -Iain
Is it Windows based? If so, have you tried installing BricxCC?
Jetro
|
|
| |
Hi all,
I have an ASUS eeePC, and was wondering if anyone knew of a way to get NQC onto
it so I could program my RCX with it?
Thanks!
-Iain
|
|
| |
Sorry I have to bring this up again,
I think it would be nice to actually have a universal binary version of MacNQC
around.
Does anybody know somebody who could help with achieving this? I currently have
two Intel-based Macs around (plus two old G3, but the kids have their hands on
them). I don't even know whether there ever was an update to MacNQC since I
downloaded it almost two years ago. Please don't tell me the project is
abandoned.
Thanks for any and all hints and pointers,
Jerry
|
|
| |
Kevin wrote:
> Is there a usable version of pbForth for Mac OS X and the USB tower?
> I have NQC, so there should be no trouble downloading firmware, and Mac OS X has
> good terminal software, but how do I set up things so that terminal
> communication goes via the USB connection to the tower. Is there a mode in NQC
> that will allow it to act as a terminal for pbForth?
I think John Hansen actually made a pbForth terminal in NQC. My RCXTcl
works on a PC, but I never did get around to packaging it for Macs.
Probably because I don't have one myself :-)
That being said, once you have a terminal program to talk to the USB
tower, then a Mac is fine for development. You're just sending ASCII
files - the RCX does the compiling.
Cheers, Ralph
|
|
| |
Is there a usable version of pbForth for Mac OS X and the USB tower?
I have NQC, so there should be no trouble downloading firmware, and Mac OS X has
good terminal software, but how do I set up things so that terminal
communication goes via the USB connection to the tower. Is there a mode in NQC
that will allow it to act as a terminal for pbForth?
|
|
| |
In lugnet.robotics.rcx.nqc, Elizabeth Mabrey wrote:
> NQC: with RCX2, it has a function to display a user defined value. Is there
> a way to do it with RCX 1.0?
If you load RCX2 firmware in a RCX1 brick (they are fully compatible*), you'll
have acces to this function (and all other RCX2 specific possibilities)
Philo
*Except for some minor differences in IR hardware.
|
|
| |
NQC: with RCX2, it has a function to display a user defined value. Is there
a way to do it with RCX 1.0? How about just to display the current mail
value with RCX1.0?
Suggestion?
Thanks in advance.
--Elizabeth
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 2798
|
|
| |
I have posted a new release of NQC which includes the fixes from r5 which were
never officially released (aside from being included along with recent versions
of BricxCC). It also includes a small source code change which makes it
possible to compile NQC on 64-bit platforms.
If you are involved with any linux or freeBSD distributions which include NQC as
a port or installable package of any kind please update the code to 3.1.r6.
John Hansen
|
|
| |
At 08:00 PM 3/8/07, Jordan Bradford wrote:
> I've also tried this in BrixcCC and it can't get a response from the brick,
> either. Meanwhile, on another machine the IR tower and RCX work fine.
>
> Does anyone have an idea of what's wrong?
Jordan,
I only have one suggestion that may, or may not be useful.
I'd suggest you try a fresh battery in the tower. I know you said it
works on another PC.
Sorry, that's the best I can do. :)
Steve
|
|
| |
I have a used Dell Inspiron 8200 laptop that is old enough to have a serial
port. I’m trying to use a serial port IR tower to program an RCX and am having
problems. When I plug in the tower the green light turns on immediately, which
AFAIK is not normal, and any NQC command I try comes back with “No reply from
RCX.” Here is some output from the command-line NQC’s verbose option, in case it
helps:
Tx: 55 ff 00 10 ef 10 ef
Rx: 55 ff 00 10 ef 10 ef
Retrying...
Tx: 55 ff 00 10 ef 10 ef
Rx: 55 ff 00 10 ef 10 ef
Retrying...
Tx: 55 ff 00 10 ef 10 ef
Rx: 55 ff 00 10 ef 10 ef
Retrying...
Tx: 55 ff 00 10 ef 10 ef
Rx: 55 ff 00 10 ef 10 ef
Retrying...
Tx: 55 ff 00 18 e7 18 e7
Rx: 55 ff 00 18 e7 18 e7
Retrying...
Tx: 55 ff 00 18 e7 18 e7
Rx: 55 ff 00 18 e7 18 e7
Retrying...
Tx: 55 ff 00 18 e7 18 e7
Rx: 55 ff 00 18 e7 18 e7
Retrying...
Tx: 55 ff 00 18 e7 18 e7
Rx: 55 ff 00 18 e7 18 e7
Retrying...
No reply from RCX
I used this command, specifically:
C:\nqc>nqc -SCOM3 -v -d -pgm 2 test.nqc > output.txt
I’ve also tried this in BrixcCC and it can’t get a response from the brick,
either. Meanwhile, on another machine the IR tower and RCX work fine.
I believe that COM1 and COM2 on this machine are the PCMCIA slots which are
currently unused. To make sure I wrote a quick C# console app to get a list of
all the COM ports:
using System;
using System.Collections.Generic;
using System.Text;
using System.IO.Ports;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string[] lPorts = SerialPort.GetPortNames();
foreach(string port in lPorts)
Console.WriteLine(port);
}
}
}
It simply reports “COM3,” and this is also the only port BricxCC can find when I
try its automatic discovery option. I have a USB tower I can use (but haven’t
tried yet), but because I also want to use this laptop with the old Dacta
Control Lab, I need to make sure the serial port works.
Does anyone have an idea of what’s wrong?
|
|
| |
In lugnet.robotics.rcx.nqc, Gus Jansson wrote:
> In lugnet.robotics.rcx.nqc, Theo Epstein wrote:
> >
> > both support for indirect variables and arrays is specified in
> > http://bricxcc.sourceforge.net/nqc/doc/NQC_Guide.pdf page 11 and 15
> >
> > so.. whats the problem?
>
> Only the RCX2 firmware supports these features. If you set the target to RCX2
> then it will compile.
>
> Gus
thank you.
specific sulution:
'nqc -Trcx2 error.nqc' instead of 'nqc error.nqc'
|
|
|
