sending info to a console

[full_auto]

Hey guys, first post here.
We are also having trouble with using DriverStationLCD. The code that I am attempting to use is as follows:

textOut.println(DriverStationLCD.Line.kUser3, 2, message);
textOut.updateLCD();

where 'textOut' is an instance of DriverStationLCD retrieved with DriverStationLCD.getInstance() and 'message' is a String that is never more than 15 characters.

This code is executed periodically. The problem is that after it executes a few times the DS stops responding and must be restarted to regain functionality. This does not happen if I remove those two lines, so I'm fairly sure that they are the cause.

Has anyone gotten this to work? Any help is greatly appreciated.

[full_auto]

Nobody knows anything that could help?

[jhersh]

Originally Posted by full_auto

This code is executed periodically. The problem is that after it executes a few times the DS stops responding and must be restarted to regain functionality. This does not happen if I remove those two lines, so I'm fairly sure that they are the cause.

Where are they called from? How quickly are they called? Does rebooting the robot affect anything, or is restarting the driver station application the only thing that makes it work again?

[full_auto]

Originally Posted by jhersh

Where are they called from? How quickly are they called? Does rebooting the robot affect anything, or is restarting the driver station application the only thing that makes it work again?

I just got in here a little while ago... It turns out that the problem was not related to the calls to DriverStationLCD, removing those lines only made the error occur much later. All is well now. Thanks.

[jhersh]

Originally Posted by full_auto

I just got in here a little while ago... It turns out that the problem was not related to the calls to DriverStationLCD, removing those lines only made the error occur much later. All is well now. Thanks.

So... for anyone else who runs into this behavior, please explain what it ended up being and how you fixed it.

Thanks
-Joe

[full_auto]

Originally Posted by jhersh

So... for anyone else who runs into this behavior, please explain what it ended up being and how you fixed it.

Thanks
-Joe

Sorry, no problem. 'message' was sometimes being indexed out of an array prior to those two lines and I had sized the array incorrectly, so I was getting IndexOutOfBounds exceptions I did not see the exceptions because I was using a development machine separate from the DS. Fixing that by properly sizing the array was the solution (i'm ashamed that I missed this)

I do not know why commenting the two lines with DriverStationLCD seemed to delay the problem. It may have been a coincidence...

I apologize for the confusion. DriverStationLCD appears to work as intended and was not the cause of my trouble. Thank you for your responses.

Regards,
Bill

[KevinJ]

Originally Posted by jhersh

Where are they called from? How quickly are they called? Does rebooting the robot affect anything, or is restarting the driver station application the only thing that makes it work again?

Originally Posted by full_auto

It turns out that the problem was not related to the calls to DriverStationLCD, removing those lines only made the error occur much later. All is well now. Thanks.

A note to everyone that doing this to send data back to the DS...

Make sure you aren't running this code CONSTANTLY. Sending new messages and running the updateLCD() method too fast will run the cRIO out of memory, and my guess is because it backlogs all the packets and fills up the memory. You'll get an OutOfMemoryError, and will have to reboot the cRIO to do anything else (like load new code).

(Found this out the hard way on WPILibJ version 1.0.0a, and my guess is it happens with the latest version too...)

[jhersh]

Originally Posted by KevinJ

A note to everyone that doing this to send data back to the DS...

Make sure you aren't running this code CONSTANTLY. Sending new messages and running the updateLCD() method too fast will run the cRIO out of memory, and my guess is because it backlogs all the packets and fills up the memory. You'll get an OutOfMemoryError, and will have to reboot the cRIO to do anything else (like load new code).

(Found this out the hard way on WPILibJ version 1.0.0a, and my guess is it happens with the latest version too...)

That's a bit strange. Are you sure that's the only thing that's happening in your loop? I just looked at the code path for that in Java and I don't see any allocations at all in that loop. Are you allocating memory yourself? Is the out of memory error coming from the Java VM or from vxWorks?