|
|
| |
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
|
|
|
