[visionegg] Re: Interfacing visionegg and LabView

Hello,

and a BIG THANKS for the fast reply.

On martes, agos 12, 2003, at 19:06 Europe/Madrid, Andrew Straw wrote:

The LabView demo works with demo/tcp/gratingTCP.py, if I recall correctly. This is a totally different program and the ephys_server and ephys_gui pair. The LabView program and the gratingTCP demo use raw TCP/IP with a simple string format to control parameters, etc.

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)

The ephys_server / ephys_gui concept is inherently more powerful and more tested (although I recommend getting the "bleeding edge" release if you play around with it much -- there have been some significant bug fixes in that code).
In theory, if you want to use the ephys_server and communicate from LabView, you could embed Python in LabView, assuming one can extend LabView with C programs. You would write a C/LabView module which embeds a Python interpreter according to the standard Python documentation "Extending and Embedding".

We have started looking into this - but don't hold your breath, I guess it'll take some more weeks. The development is in the context of a freely available data-acquisition setup for patchclamp purpose (partly based on a NI-daq-board which is controlled by LabView) - i'll put a notification here if it is ready.

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?

anyway: nice mailinglist =8)

cheers,

Markus


-------------------------------------------
Markus Bongard
Universidad Miguel Hernandez
Dept. Histologia y Anatomia
Campus San Juan
Aptdo. de Correos 18
E-03550 San Juan de Alicante
SPAIN
-------------------------------------------
markus.bongard@xxxxxx
visit us at http://cortivis.umh.es
-------------------------------------------

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: