Re: RobotPy 2010.beta2
 

It's UDP broadcasted by the robot to 10.255.255.255, port 6666. There's no data format, the UDP payload is simply the console output.

Re: RobotPy 2010.beta2
 

so i listen for a broadcast on port 6666?

how would i do this with netcat?

Re: RobotPy 2010.beta2
 

Untested, but something like "nc -u -l -p 6666" ?

Remember that to get anything you need to have the NetConsole server running on the cRIO (by editing ni-rt.ini per the instructions in the above link).

Also I've only seen this work over wired connections (on the PC side); wireless to the robot works fine, but the PC has to be hardwired to the router (I think this has to do with it being broadcast instead of unicast).

Re: RobotPy 2010.beta2
 

UDP 6666 for packets to the client.
UDP 6668 for packets to the cRIO.

Re: RobotPy 2010.beta2
 

You can use this utility (since netcat doesn't play very nicely with listening for broadcast UDP).

You can then use the script here.... or just run (after compiling ncb.c):
Enjoy,
-Joe

Re: RobotPy 2010.beta2
 

thanks :)

so i add netconsole.out to the startupdll's?

Re: RobotPy 2010.beta2
 

Add it to the beginning of EarlyStartupLibraries. Guess you didn't find the instructions.

Re: RobotPy 2010.beta2
 

just confirming

Re: RobotPy 2010.beta2
 

This is great!

I played with RobotPy a little, and here's a problem I encountered. When our code exits due to some error, it waits 5 seconds and then starts our script again, which is how we load new code.

However, when it's an actual error, not an intentional interrupt for new code, while we look at the source and fix the problem it keeps on restarting every 5 seconds. Eventually it crashes with some memory error and we have to restart the robot. (I don't have the output in front of me; I'll try and reproduce it so I can post the exact error.)

Has anyone else had this issue? How can I prevent it from doing this?

Re: RobotPy 2010.beta2
 

I will fix this in the first 2011 release (Wednesday at the latest). What I will do is handle the restart/reload exception specially; any other exception will result in ending the user program (requiring a full robot reboot).

Re: RobotPy 2010.beta2
 

Full robot reboot as in a power cycle? That seems like it could be improved (though, timely release of the first 2011 release is probably more important). The advantage of quickly reloading code without a power cycle is great, and syntax errors are probably common.

How long does a power cycle take for most people? With our LabView code (I don't know if your language makes a difference), it took a minute or two before we got communications after turning the robot on.

If the error is happening because the user code is being loaded/unloaded so often, then I can't think of any good fix that doesn't involve fixing the memory error/bug.

Re: RobotPy 2010.beta2
 

When there's an error can't it just sit there and wait for you to load new code? Maybe that's something that could be done in robot.py inside of run(), if it catches an exception then checkRestart() continuously.

Re: RobotPy 2010.beta2
 

By scanning the /py/ directory for updated date/time/size files (maybe non-ideal because of multiple files...)? Or wait for a joystick button press?

Re: RobotPy 2010.beta2
 

Unfortunately the memory leak appears to be very difficult to fix (it's a leak in Python itself).

With regards to reboot time, you don't need to power cycle the whole robot. Clicking the "Reboot Robot..." button on the Driver Station Diagnostics tab only takes 20-30 seconds. Still non-ideal, of course, but much faster than a power cycle (the additional delay is due to the wireless network startup time).

Re: RobotPy 2010.beta2
 

Wait for a button press, same as usual. I was just going to try wrapping the whole run method in a try..except, and in the `except' continuously check for a joystick button to raise the restart runtime error.

http://pastebin.com/9bcUEy96