Well, after starting the server under Win2000 (besides some fireall fiddeling =8) the communication works - at least in the shell via the python gui from the vision egg demo. Apparantly the labview gui can connect to the server, the transferred variables are echoed in the Shell, but for some reason not used by the server. I'm digging on that now, but again thanks a lot for the "get-back-on-the-right-track"-comment! =8)
We use a small extension to the EPhysGUI which implements a very simple raw TCP connection to our data acquisition program. (This is in addition to the Pyro/TCP connection that EPhysGUI makes to EPhysServer. Also, EPhysGUI and the data acquisition program actually run on the same computer, although because we're using TCP, this is not necessary.) The TCP connection simply coordinates the onset and duration of trials, with final synchronization between the data acquisition program and ephys_server implemented via a hardware trigger between those two computers. The data acquisition program could then be implemented in anything that speaks TCP and would require only a minimum of TCP programming or other modification. Although our data acquisition program is written in Python, the original concept was that it would be written in Matlab using the data acquisition toolbox. Let me know if you need help going down this > path.
The last point is particular interesting - some while ago I participated in the development of 128 channel daq-board and the requiered software for acquisition and some analysis (at that time in tcl/tk and c); any knowledge about the minimal time resolution for the communication via TCP ? The TCP/IP stack and its priority are controlled by your python code - or does the data acquisition and stimulation "wait" if the TCP/IP stack does its regular whatever service polling?