search

open-ephys / plugin-GUI

Software for processing, recording, and visualizing multichannel electrophysiology data
https://open-ephys.org/gui
GNU General Public License v3.0
193 stars 683 forks source link

Opening the Rhythm FPGA source node takes a very long time in Linux #58

Closed jonnew closed 2 years ago

jonnew commented 8 years ago

OS: Ubuntu 14.04 OE Version: 94771673fec1f55bd84acde1a586506b91ecabdb

The GUI blocks for about 1 minute when I drag/drop the Rhythm FPGA node to the signal chain. It is completely unresponsive during this time period and mangles other windows that get dragged across it. it spends about 30 seconds in this state:

Item dropped at insertion point 0
Creating from description...
Sources::Rhythm FPGA (0-0)
/home/jon/public/open-ephys/plugin-GUI/Builds/Linux/build
---- Intan Technologies ---- Rhythm RHD2000 Controller v1.41 ----

FrontPanel DLL loaded.  Built: Feb  1 2012  17:34:05

Scanning USB for Opal Kelly devices...

and then another 30 stuck at 

Found 1 Opal Kelly device connected:
  Device #1: Opal Kelly XEM6010LX45 with serial number 141000081U

Eventually, either the

  1. Opal Kelly device is recognized or
  2. I receive and endless stream of ...error usb control message: Cannot allocate memoryerror usb control message: Cannot allocate memory... at the terminal and I must forcibly kill the GUI (SIGQUIT) to get it to stop. This seems to happen after the GUI has crashed during acquisition previously. EDIT: this occurs every time I close the GUI, even if its through a normal mechanism. Brining the USB connection back to life requires me to unplug/plug the USB.
aacuevas commented 8 years ago

Yeah, this both are issues with the Opal Kelly frontPanel library.

Can you check if with the USB3-compatible opalkelly frontpanel library the software still takes so much to detect the board? (you might have to tweak your linux system for it to work, full instructions at the end of https://open-ephys.atlassian.net/wiki/display/OEW/Rhythm+FPGA ) The default frontpanel lib is an older version which has its share of issues, but we ship that one by default so users who don't need usb3 support do not need to mess with their systems, but perhaps this issue is solved in the newer USB3. (Also, although I've experienced slow detections, its never as long as in your case, there's probably some hardware-related variable in that).

The second point you mention is also known, when crashing, the frontpanel usb state sometimes gets stuck in a bad state. The best option, when you have a crash when acquiring, is to unplug and plug again the FPGA board.

malfatti commented 8 years ago

About the second point, it happens to me exactly 50% of the time, in both Debian and Gentoo. I don't even need to close the GUI, just removing the FPGA module from signal chain is enough.

Steps (assuming that the module loads OK once):

Either way, after killing the GUI, I don't need to replug the board. It works 100% of the time after killing the GUI and reopening it. However, I never had this problem of long time to detect the board.

Maybe the module is not been closed cleanly? I only get "Removing processor with ID 100; RHD2000 interface destroyed" in the terminal (so it should be ok).

jsiegle commented 2 years ago

The delays in launching this plugin on Linux have been solved by upgrading to the latest version of the Opal Kelly library.