Subject:
|
Re: Download problem
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Sat, 2 Oct 1999 19:15:30 GMT
|
Viewed:
|
1921 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Mario Ferrari writes:
> Hi Dave and everybody,
>
> I have a strange problem with an NQC program. It's something Marco Beri and
> I are preparing for the Mindfest.
>
> The program is rather large if compared to the average NQC programs: about
> 240 lines of code with large inline functions (I know this is not a very
> precise way to measure the program size but just to give you an idea). The
> problem is it compiles ok, but NQC is not able to download it. After some
> "dots" NQC simply writes "error" and exits. The strange point is that the
> download always stops in different points, and Marco was even able to
> succesfully download it after some tries (I wasn't with more than 30 tries).
> I tried both short and long range IR transmission.
>
> Any idea?
>
> Mario
> http://www.geocities.com/~marioferrari
What you're describing sounds like a problem I had when downloading VB
programs with the Spirit.OCX. I coded a huge program, with lots of tasks and
subroutines, and long stretches of code. When I try to download it, I get the
dots and then AsyncronBrickError returns Error 2048 (not 100% certain about
the number) with no error description. It got me really ticked off because
like you said it seemed to happen at random times during the download
process. Additionally, downloading each of the tasks separately to the same
program slots via piecewise downloads mysteriously made the problem vanish.
My eventual solution was to add a VB MsgBox that popped up in the DownloadDone
event saying "Task x finished downloading." Since MsgBoxes are modal, the
Spirit.OCX couldn't do anything until the user clicked OK. Setting artificial
pauses in between the task downloads apparently caused the problem to fix
itself. Also, as I said above, downloading the tasks in separate processes
also fixed the problem.
Does this sound like what's happening with your program? I assumed that my
RCX was simply being cranky, since the rest of the setup (connection, IR
interference minimized, code free of bugs) appeared to be functioning
perfectly. Now with your post I'm beginning to wonder if this isn't a product-
wide problem.
The only conclusion I can come to is that this is a bug in the RCX, since it
appears to be happening with both NQC and Spirit.OCX (and, since NQC doesn't
use the Spirit.OCX, this indicates that the problem doesn't lie with either of
them - Dave is off the hook). Perhaps the RCX has a "download receive" buffer
that can overflow, and the transmitter can download faster than it empties
out. Like you said, it doesn't happen with my short programs, only the really
long ones.
I'd be curious as to whether anyone else has experienced this problem. It
might turn out to be the first reported bug with the RCX 1.0!
|
|
Message has 1 Reply:
 | | Re: Download problem
|
| (...) Thanks for your help. Hope you're wrong, otherwise I have to dramatically downsize my program and make it a lot more stupid :-) Some more info on the problem: - The memory has been cleared before any attempt. - I tried both NQC 1.3 and NQC 2.0 (...) (25 years ago, 2-Oct-99, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | Download problem
|
| Hi Dave and everybody, I have a strange problem with an NQC program. It's something Marco Beri and I are preparing for the Mindfest. The program is rather large if compared to the average NQC programs: about 240 lines of code with large inline (...) (25 years ago, 1-Oct-99, to lugnet.robotics.rcx.nqc)
|
14 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
