RobotPy 2010.beta2

[Peter Johnson]

Originally Posted by Robototes2412

oh, what port is this on?

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.

[Robototes2412]

so i listen for a broadcast on port 6666?

how would i do this with netcat?

[Peter Johnson]

Originally Posted by Robototes2412

so i listen for a broadcast on port 6666?

how would i do this with netcat?

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).

[jhersh]

Originally Posted by Robototes2412

oh, what port is this on?

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

[jhersh]

Originally Posted by Robototes2412

so i listen for a broadcast on port 6666?

how would i do this with netcat?

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):

./ncb 6666 &
nc -u 10.xx.yy.2 6668

Enjoy,
-Joe

[Robototes2412]

thanks

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

[jhersh]

Originally Posted by Robototes2412

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

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

[Robototes2412]

just confirming

[blakeelias]

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?

[Peter Johnson]

Originally Posted by blakeelias

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?

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).

[Slix]

Originally Posted by Peter Johnson

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).

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.

[blakeelias]

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.

[Peter Johnson]

Originally Posted by blakeelias

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.

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?

[Peter Johnson]

Originally Posted by Slix

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.

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).

[blakeelias]

Originally Posted by Peter Johnson

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?

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