Required File is broken - Error 1003

[ronmcrae]

Originally Posted by Dean Hystad

It has always been an error to have a condition not connect to an output connection of a switch block. If you think about how scheduling is done in NXT-G, this is a potentially catastrophic error.

You know I actually agree with what you say. To me it makes little sense to have a sometimes unsatisfied wire exiting a switch statement.

That said, I uncovered this difference while trying to figure out why an older program by a well known NXTG writer wouldn't compile in V2.1. Like you I had questions in my mind why the code was written the way it was, but it had compiled in the older version. So I then went online to investigate how this apparent peculiarity of the switch statement *should* be used. On P113 of Jim Kelly's book I find a program with a similar construct exiting the switch statement, which for me partially validated the style. Here is the link.

http://books.google.com/books?id=sj7...page&q&f=false

Now I'm not really too sure what Jim's program actually does (don't have the book myself and don't have a brick to hand), but I recreated it and it compiles normally in V1.1. Yet V2.1 throws an error 1003 after which the GUI must be restarted.

If programs from an existing book are not supported by the latest release then either it is deliberately not backwards compatible or it contains a bug. Even if one argues that the NXT-G V2.1 has been deliberately changed to disable a questionable programming style, it should never be necessary to restart the entire GUI as a result of a compiler error, and at the very least it should provide a more meaningful error message.

Even then, it certainly shouldn't be possible to compile a newly created program in the current session but then never again once it has been reopened from a file. In my book (no pun intended) that's just plain wrong and extremely confusing for the average user.

[Robomom]

Originally Posted by ronmcrae

Now I'm not really too sure what Jim's program actually does (don't have the book myself and don't have a brick to hand), but I recreated it and it compiles normally in V1.1. Yet V2.1 throws an error 1003 after which the GUI must be restarted.

Did you create the program from scratch in 2.1 or did you use the code that you created in 1.1? According to Lego support some code must be completely recreated block by block from scratch in 2.1 in order for it to work. I'm curious if that would be the case in this example. I am purposely holding off on upgrading to 2.1 until after the season is over. We tried to upgrade early in the season and immediately ran into the error 1003 problem so we went back to 2.0.

I have the book. The program is comparing two random numbers (number A and number B) between 1 and 9, displaying them on the screen and telling if A is greater than B.

[Coach Tron]

I've actually had this error recently multiple times. I have found nothing wrong with my program and have had good luck by closing NXT 2.1 software and reopening it and the program downloads fine.
Hope this helps someone.

[ronmcrae]

With less than 8 hours to opening ceremonies for a regional tournament I sit here in Illinois beyond midnight having just recreated block-by-block two programs of my rookie team. If others deem that excessive coach involvement - too bad - these kids should not be having to deal with buggy software to this degree.

For whatever reason they started seeing the dreaded 1003 error code in two of their programs earlier this evening and, as several others have experienced, this time it seems to relate to their MyBlock which is referenced by both programs. As yet I haven't figured out the cause but rest assured I'll be right on the case once tomorrow is done. What I have noticed, however, is that MyBlocks with names that exceed the available space within the block itself cause very strange things to happen to their positioning when they are dropped onto the main sequence beam. The team's long filenamed MyBlock ends up about 1/16" out of position when dropped. An even longer named one that I created for testing was dropped about 1/2" below the main sequence beam. Neither of these issues actually caused the 1003 error, and when the block was manually repositioned it lined up properly. Whether this is a 2.1 phenomenon remains to be seen.

I also noticed that both programs that generate the 1003 error open with the start icon of the main sequence bar greyed out. Attempts to do anything but view the individual blocks (e.g add block, convert to MyBlock) immediately cause NXT-G to crash.

[Steve Putz]

I have seen this error, and I have one more suggestion that I have not seen on the discussions I've read. In my experience, once a "bad" program that triggers this error is loaded into the NXT program editor, ANY program (even an empty one) will get the error. So it is not enough to recreate the bad program from scratch. It is also important to not even open the bad program. The fix that has worked for me is:

A) after encountering the error, exit and restart the NXT software, and DO NOT reopen the problem program
B) re-code the problem program from scratch.

That seems to work for me. I think people are having a hard time diagnosing and working around this problem because encountering the error seems to make the compiler stop working for any program until the NXT software is restarted.

I'd like to know if others find the same, and if this suggestion helps.

Steve Putz
www.RoboticsLearning.com