Required File is broken - Error 1003

[Silent_Lion]

We've encountered this problem when we call a MyBlock which has been saved/modified at a different time than the MyBlock originally called by the program. It may have the same name and contain identical code, but if it has a different time/date stamp, it will appear as cracked and often won't compile. I wonder if this is a 'smart' feature built into version 2.1 intending to protect us from frustration when behavior changes due to a different version of MyBlock being used.

One solution that always works for us is to delete the MyBlock which is causing the problem and then reinstall the desired MyBlock from the menu. I'm sure there's more sophisticated/elegant solutions using the Pack-and-Go feature, but as a fallback, this always works for us.

[Dean Hystad]

Originally Posted by Silent_Lion

We've encountered this problem when we call a MyBlock which has been saved/modified at a different time than the MyBlock originally called by the program. It may have the same name and contain identical code, but if it has a different time/date stamp, it will appear as cracked and often won't compile. I wonder if this is a 'smart' feature built into version 2.1 intending to protect us from frustration when behavior changes due to a different version of MyBlock being used.

One solution that always works for us is to delete the MyBlock which is causing the problem and then reinstall the desired MyBlock from the menu. I'm sure there's more sophisticated/elegant solutions using the Pack-and-Go feature, but as a fallback, this always works for us.

That can't be right. Such a feature would make the software almost unusable. Edit a My Block and you have to edit all the programs that use it? There must be something else going on.

I have seen a problem with a similar symptom but a different cause. If you have two My Blocks with the same name (in different directories) I have seen the dreaded jaggy and code that doesn't run correctly. I also know that if you change the interface to a My Block (including names for the data plugs) it will appear broken in programs that use the older version.

[ronmcrae]

Originally Posted by Silent_Lion

I wonder if this is a 'smart' feature built into version 2.1 intending to protect us from frustration when behavior changes due to a different version of MyBlock being used.

I don't believe that this 1003 file error problem is a smart feature added to V2.1. Even if it was, in this day and age it is shocking to me that professionally written software simply reports "Error code 1003" for some reason and gives up. No additional information is offered as to what might be causing the problem. From google searches related to labview it appears that error code 1003 is a generic "cannot find a file" problem so it can doubtless occur for a variety of reasons, which likely explains some of the reports of problems during installation.

NXT-G (labview?) would do well to report some additional troubleshooting information along the lines Error Code 1003 - cannot file file myblock.rbt referenced by myprogram.rbt so at least users have a clue what is causing the problem.

Several of the problems in this thread pertain to my blocks, and doubtless there are problems in that area too. But the program that is giving me grief has no myblocks. It will open, compile and download perfectly from V2.0, but never from the main screen download icon in V2.1. Strangely, it will download perfectly from the MULTIPLE NXT's menu option of V2.1. As others have reported, once V2.1 displays a 1003 file error it will no longer download any program using the main screen download icon, even something as simple as a newly opened single move block program, until NXT-G has been restarted.

Clearly something in certain programs presents a problem to V2.1, yet that something doesn't upset other versions of NXT-G. It sure would be helpful if NXT-G would tell the user what that *something* is, but it would be even more helpful if Lego/NI would investigate what I would consider to be a definite bug in V2.1.

Ron.

[GWhizNonKid]

I searched the files in the NXT program files folder and sub-folders and found an XML family of files that use "1003" in them to relate that number to the english message: The VI is not executable. My guess is now that the engine has found one of the 681 .VIs in this package to be faulty. The program that received this 1003 notification is not relaying the exact name of the .VI that fails. the name may not have been passed to it. The program authors might be trying to shield the general public from such minute details resulting in the generalized message.

I'm not going to delve any further into the hundreds of Mb of object code in the various .VIs and .CTLs files included in this package. I have little expectation of being able to figure out the intricacies of labview execution.

I did note that the readme.txt file contains notice that this product includes Adobe Flash Player. Adobe has recently updated the flash player to version 10.1 I think. If any of you who have reported this 1003 difficulty will report their recent activity with either updating or not updating their flash player, perhaps we can make a correlation with errors in mindstorms program.

[Robomom]

I called Lego to ask about this problem. I was told that code from 2.0 might not work in 2.1 and cause the 1003 error. If that happened, you would first need to close the NXT software and reopen it (or the 1003 would just continue to occur). Then reopen the 2.0 code, and open a separate new tab. He said to toggle back and forth between the old code and the new tab and recreate the code from scratch by dragging new blocks into the new tab. You can not copy and paste the old code into the new screen. I think this is ridiculous. Has anyone had the 1003 problem using completely new code written only in 2.1 or is the problem only with 2.0 code?

Basically, do not consider upgrading to 2.1 until after the FLL season is over unless you want to have your kids recreate all of their code block by block. If they have any code they want to reuse in the future (line followers etc), this code should probably be rewritten once you update to 2.1 to be sure you avoid future problems. This is definitely an off season task.

[bboorman]

We ran into this in mid October in an upgrade from 1.0 to 2.1 (Yes, we were on an original version, having bought used kits on eBay).

It didn't show up until we coded a myBlock. After two weeks I tracked the problem to a bad myBlock (the only one we had, btw). The error doesn't go away even if you close the offending program. You have to restart NXT-G.

In the end, I ended up recoding the myBlock anew and saving as a new file. Since I didn't change the code, I didn't think I should feel guilty that the kids didn't do it. They did code the original "broken" one.

[rcomeau]

We ran into this error again. This time it was caused by disabled blocks off of the sequence beam. The program downloaded ok when those blocks were first put there. The next day, after saving and closing, it raised error 1003 when trying to download. Fortunately, it showed each My Block broken as a trail to drill down to the problem. Drilling down took patience. It was very slow. It worked after deleting the stray blocks and restarting Minstorms (which is necessary to clear the error state).

Sometimes it helps to press the End key to scroll to the last block because the last block might be a stranded block off of the screen. The scrolling action helps show blocks that the program knows about.

[GWhizNonKid]

Originally Posted by rcomeau

...
Sometimes it helps to press the End key to scroll to the last block because the last block might be a stranded block off of the screen. The scrolling action helps show blocks that the program knows about.

Doesn't the screen map on the lower right show the stranded stuff too? If you have "words" of help in that area, click the other tiny tab to see a screen map. You can click in there to center the main display on whatever part of the program you wish to see.

[VinayD]

I just logged in to seek help on Error 1003 and find that others are having the same problem! I have reviewed the thread and dont think any of the possible causes apply to us. The program was working fine a minute ago and kids made one small change and started getting this error. Chasing though many my blocks, we found one of the my blocks was cmpletely messed up - it basically had all its blocks moved off the sequence beam and to a side. We patiently fixed it by dragging each block back to the sequence beam and that seems to have solved the problem.

We have been running into this issue every other day ever since we started using my blocks. I diagnosed a different reason each time and fixed it - basically the 'thou shall...' set of rules at the start of this thread is what we discovered (but one at a time)! Not sure what rule to follow to avoid what happened today.

This is such waste of time and morale killer:-(

[Robomom]

Originally Posted by VinayD

We have been running into this issue every other day ever since we started using my blocks. I diagnosed a different reason each time and fixed it - basically the 'thou shall...' set of rules at the start of this thread is what we discovered (but one at a time)! Not sure what rule to follow to avoid what happened today.

This is such waste of time and morale killer:-(

Are these blocks that were written in 2.0 and you are now using in 2.1? Or are they completely new 2.1 blocks? If they are older 2.0 blocks, supposedly you need to recreate them from scratch, one block at a time in 2.1 if you want to be sure they won't keep crashing. This is what the tech guy from Lego told me.