Fixing yet another bug in the WPILib implementation of networktables. This bug leaked sockets each time a client connection failed (which is pretty much all the time if there’s no robot present). If you’re using pynetworktables to talk to the robot, you’re probably going to want this update.
The latest downloads are available at FIRST Forge. Please report any bugs you find at our github tracker.
I’m thinking about using pynetworktables on a separate coprocessor on our robot, but our CRIO and driver station are currently configured for Java. I was wondering whether pynetworktables is compatible with the default Java code for NetworkTables.
Yes. pynetworktables is just a wrapper over the WPILib C++ implementation of NetworkTables, which is compatible with the Java implementation.
Yay, thanks! Dumb question - on Windows 8 (64 bit) running 64bit Python 2.7 can I just use pynetworktables-2014.4.win32-py2.7.exe or do I have to build from source.
You would need to build from source, or install the 32-bit version of python.
any chance we could charm you into building the 64 bit version…? If not, no worries…
My Windows computer won’t be available to me until tomorrow, so I can’t do anything about that until the afternoon at the earliest. Did you have problems compiling the 64-bit build? It shouldn’t be too bad if you happen to have VS 2008 installed 
Any particular reason you prefer the 64-bit build of python to the 32-bit build?
I have VS 2013… I’ll give it a try myself when I get a chance. I have all 64-bit stuff on Windows 8 - didn’t want to deal with trying to mix and match - but I take your point that I can homogeneously go to all 32-bit nonetheless. For that matter, I could try to run new Python 3.x in 64-bit mode… I’d be delighted with whatever you can do when you can do it, … I really appreciate all your support and encouragement on NetworkTables
I’ve uploaded a 64-bit build for python 2.7
Super! Thanks!
Do you have a list of changes made to this build from previous builds. I can’t seem to find that.
Thanks for this by the way,
Regards,
Kevin
Also is there a particular upgrade process when moving from a previous version of pynetworktables to this one?
Must you uninstall the previous version of pynetworktables before running the new .exe or can you run it will the previous version installed, and the appropriate files will be overwritten?
Thanks,
Kevin
I haven’t been maintaining a changelog, but I probably should be doing that. I need to change around the relationship to robotpy works too, as there isn’t a definite 1:1 way to figure out what source goes with what.
That notwithstanding, the only fix in this binary release is https://github.com/robotpy/wpilib/commit/9a6ece2a79d6dafb0b117d8c97e754c012394444, which closes client sockets when the robot connection fails.
Upgrading doesn’t require anything special, just run the exe.
Also, if you want to know what version of pynetworktables you’re running on a machine, you can look at pynetworktables.version . It should work on all versions of pynetworktables released this year – with the exception that 2014.1 (and maybe 2014.2) as ‘PYNETWORKTABLES_VERSION’ as the value, instead of the actual version. The latest releases have this fixed, however.
Hi,
We’re using pynetworktables to communicate results of vision processing python code from a pandaboard to a crio that IS NOT using robotpy. We had problems that caused our robot to become unresponsive to autonomous or teleop controls when a match began (but didn’t have any problem during practice matches, or during non-field system testing.) Disconnecting the pandaboard eliminated the problem, but also our vision processing.
Since we don’t have a field system to debug with, we’re investigating alternative communication pathways to pynetworktables (like i2c, since we don’t need to communicate much info). I wondered if virtuald had an idea whether the bugs fixed by this pynetworktables release might cause this kind of problem or not, as more weight to encouraging the team to update pynetworktables. (I think that involves re-building pynetworktables through sip on the pandaboard due to its architecture.) The team is hesitant to apply the fix with a view of not changing things unless we have to, mid-season.
Thanks for any quick thoughts.
What language is your robot code running?
If you’re using C++ on your robot, then see this thread. The unresponsiveness is a known bug in the C++ implementation of NetworkTables. A workaround is always make sure everything is off before the match (including Driver Station, beagle, and cRio), and if any of them turn off, turn all of them off.
I’ve been told that FRC will be releasing an official patch for this in the next week or two, but my unofficial patch is also available.