[visionegg] Re: Interfacing visionegg and LabView

  • From: Andrew Straw <andrew.straw@xxxxxxxxxxxxxxx>
  • To: visionegg@xxxxxxxxxxxxx
  • Date: Wed, 13 Aug 2003 16:59:15 +0200

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)

I think I remember someone else had this problem. I think the problem was solved by sending a newline after each string. Also, you can debug just by telnetting into the server on the correct port.

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?

I have never used TCP/IP where latency shorter than 25-50 msec was required. All the TCP stuff (including the Pyro based ephys_server) in the demos merely sets up parameters before trials. (And the trigger is done separately in hardware in my setup.) I think it would be feasible to update parameters in realtime over the network, but I would do some benchmarking before committing to anything. Also, I know many multiplayer games use UDP instead of TCP to minimize latency. For minimizing latency with TCP, I've heard hints that you may need to reduce the size of packets so that the OS doesn't wait (long) for them to fill up before sending them.

I haven't looked closely at the Twisted framework for network programming in Python, but I believe it offers some higher-level support for UDP-based communications. (Pyro doesn't currently, to the best of my knowledge.)


Other related posts: