File Error

[cave2596]

Hello,

I haven't worked with LabView yet.

But I have to do it now.

My task is to find out the color of several balls with the Lego Mindstorms robot.

Therefore I have made a small (test-)program.

It should find out the colors of two balls.

If the coloursensor shows black, it should measure again, until he finds a blue or red ball.

This he should do of two balls, after another.

Because of this, there are two loops.

In my example, the robot gives out two different sounds, depending on the color.

Because of the testversion, I put a big loop around both parts.

It has no other reason.

If I now download this program to the NXT, the robot crashes or shows "file error!".

LabView doesn't show any errors.

Someone said, that I should make a completely new program, and so I did.

But it doesn't change anything.

I tried different versions, but the robot always crashes.

One loop works, but both loops don't work.
Thank you for your answers!

[CemY]

Hello cave2596,

A "File Error" can occur when the program runs of out memory at runtime. Variables, Text strings, and some other internal things require a small amount of memory allocation internally when the program first initializes, so although your programs downloads and fits, it's possible you are short on memory when running.

A "File Error" can also mean that the program crashed, due perhaps to a corrupt compiled file or an illegal operation, which would be a bug in the software... It is not supposed to be possible to create a crashing program with NXT-G. But it's possible in theory (bug in the compiler), in which case you will need to try to do something different to make it go away.

If your program is really long, the first thing I would try is splitting it up into some chunks with My Blocks.

Best regards,

Cem Yalcin

National Instruments

[APena]

Hi Andi,

I just wanted to close the loop on this and post the workaround that was given to you in Jakarta at WRO so others may benefit from it as well. The issue here is that the reentrancy of the NXT_ColorSensor.vi was causing an issue during compilation that was leading to the behavior you were seeing. The workaround for now is to turn off reentrant execution for that VI, which can be found on disk here:

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\NXT\Remote Library\NXT Color Sensor\NXT_ColorSensor.vi

You can do this by:

1. Change the permissions of the VI on disk to not be Read-only (right-click on it in the Windows File Explorer, select Properties, uncheck the Read-only checkbox, click OK).
2. Open the VI.
3. Right-click on the icon or the connector pane in the top right corner of the window and select VI Properties.
4. Select Exectution from the dropdown.
5. In the Reentrancy section, select the "Non-reentrant execution" option.
6. Click OK.
7. Save the VI (CTRL+S or File->Save)

Before doing this, I'd recommend closing all other LabVIEW projects you may have open.

Please let me know if you have any questions. Thanks.

- Aaron

[CarlosOtiniano]

hello, to priemra inspection program needs a delay routine, using good practice this is the most recommended, another detail is that the communication with the NXT Brick is observed, it is likely that the program is looking brick but this is not declared