Got an error on startup when displaying the very first log message on the GUI console window. This could be a Python version compatibility issue - the server was developed for 3.1.1 and on my home office PC I have 3.2.2 (latest stable release). However, I'm not sure why this is causing problems, because I ran the server successfully at home previously? Was I using a different version back then? Anyway, I should debug and fix this problem. It would be nice to be able to run the server in the latest version of Python.
Looking at the log file, it seems that the logger didn't get configured properly or something - the file name, function name, and line number aren't getting set automatically in the log messages like they are supposed to. Perhaps they changed the logging package in some incompatible way?
I'm going to try to install the latest release of 3.1 (which is 3.1.4) at home and see if the server runs better with that.
OK, that seemed to fix that error (although I'm not sure why this happened, because there was nothing in the "what's new about 3.2" doc that obvious would have broken this. Now I'm having a problem opening the mainserver socket. It looks like sitedefs.py is assigning the wrong IP address - I'm no assigning Theo a static IP from my router since I'm bridging the wireless from my laptop. OK, fixed that.
The server starts up now, but I can't fully test it without a WiFi module. I actually have a WiFi module here. However, I will have to recompile the autorun script to adjust for the new server IP address.
Really, we need to rearchitect the discovery protocol for initiating communication between the WiFi board and the server so that they can automatically find each other as long as they are on the same subnet as each other, without already knowing each others' IP addresses. This could be accomplished using broadcast packets, perhaps. Right now there is no discovery protocol per se; the WiFi boards have the server's IP address hard-coded into them. This is not very elegant.
At minimum, the server IP address should be in a config file (called "config.txt" or something) that can get downloaded onto the WiFi board without having to recompile the autorun script. This file could also include the Node ID information, so that we would no longer need the existing nodeid.txt file.
In my notes in the sites.uwi module of the autorun script, I talked about having "site.txt" and "debug.txt" config files to contain site-specific settings and debug levels. However, these two functions could be easily absorbed into a single config.txt file. But, a module to read and interpret that file would still need to be written. And when I was last working on the autorun script I was bumping up against memory limitations. That could happen again if I try to add new features. Best for now, probably, if I just modify the hard-coded IP address in sites.uwi and recompile. Doing that now.
OK, the Wi-Fi board started up and opened its 3 connection windows on Theo with no errors.
It occurs to me that the easiest kind of "input stub" might be to simply stream a sample text stream that might be produced by the DE3 or FEDM board directly to the Wi-Fi board using UwTerminal's "Stream File Out" option. If the students have a Wi-Fi board to work with, this is a heck of a lot easier than creating a whole new app to simulate it.
While I had the WiFi autorun script open, I made a couple of minor changes to it to reduce the startup time (mostly, turning off info logging to the network). These changes won't take effect, of course, until the next time we re-burn the modules. I've done that now.
I added a message BRIDGE_MODE to the Wi-Fi board to support informing the server of the Wi-Fi board's current bridging mode, since this influences whether and how best the server can communicate with the Wi-Fi module and to the host behind it.
Fixed a minor bug in the Wi-Fi script having to do with call stack maintenance.
Changed the server to now put the node name in the window title after the first command is received.
Fixed a bug that was causing the server to become crippled if commands were typed in the console window.
I added a message BRIDGE_MODE to the Wi-Fi board to support informing the server of the Wi-Fi board's current bridging mode, since this influences whether and how best the server can communicate with the Wi-Fi module and to the host behind it.
Fixed a minor bug in the Wi-Fi script having to do with call stack maintenance.
Changed the server to now put the node name in the window title after the first command is received.
Fixed a bug that was causing the server to become crippled if commands were typed in the console window.
No comments:
Post a Comment