open-ephys-plugins / nidaq-plugin

Acquires analog and digital signals from National Instruments DAQs
GNU General Public License v3.0
4 stars 14 forks source link

Open Ephys Crashes when Adding NI-DAQmx Plugin to Signal Chain #16

Open theonlydvr opened 3 months ago

theonlydvr commented 3 months ago

When I try all available versions of the plugin with the most recent versions of OpenEphys, the GUI will immediately crash after adding the plugin to the signal chain. The following text is the related portion of the log file:

[open-ephys] Creating processor with name: NI-DAQmx
[open-ephys][debug] 
0: juce::SystemStats::getStackBacktrace + 0x89
1: ofSerialDeviceInfo::~ofSerialDeviceInfo + 0x18137
2: juce::Time::getYear + 0x6a
3: UnhandledExceptionFilter + 0x1ec
4: memcpy + 0x2bbd
5: _C_specific_handler + 0x97
6: _chkstk + 0x12f
7: RtlFindCharInUnicodeString + 0xa96
8: KiUserExceptionDispatcher + 0x2e
13: SourceNode::createEditor + 0x29
14: PluginClass::setPluginData + 0x5056
15: Visualizer::startCallbacks + 0x105d4
16: juce::UndoManager::perform + 0x3e
17: Visualizer::startCallbacks + 0x929d
18: Visualizer::startCallbacks + 0xb202
19: juce::ComboBox::mouseUp + 0x298
20: juce::LowLevelGraphicsPostScriptRenderer::writeXY + 0x72a0
21: juce::Component::internalMouseUp + 0x38b
22: juce::Button::setButtonText + 0x1f6
23: juce::MouseInputSource::handleEvent + 0x206
24: juce::MouseInputSource::handleEvent + 0x96
25: juce::TooltipWindow::displayTip + 0x6db
26: juce::TooltipWindow::displayTip + 0xa1a
27: juce::DrawableShape::pathChanged + 0xa6f
28: juce::MouseInactivityDetector::wakeUp + 0x259
29: DispatchMessageW + 0x741
30: DispatchMessageW + 0x201
31: juce::MessageManager::runDispatchLoop + 0x111
32: juce::JUCEApplicationBase::main + 0xa9
33: TiledButtonGroupManager::setMinPaddingBetweenButtons + 0xd2e
34: BaseThreadInitThunk + 0x1d
35: RtlUserThreadStart + 0x28

Let me know if any other information would be helpful!

medengineer commented 3 months ago

Hi,

Have the NIDAQmx drivers been installed via the Requirements section here:

https://open-ephys.github.io/gui-docs/User-Manual/Plugins/NIDAQmx.html#requirements

If so, what is the NI device model you are using?

theonlydvr commented 3 months ago

The computer has the latest version of NIDAQmx installed and I've confirmed it works with other software (and earlier versions of the plugin/OpenEphys). The device is a NI USB-6343 (which did work with earlier versions of the plugin). If it matters, there is a second DAQ plugged in associated with our behavioral system that is not intended to be used with the plugin. This also wasn't an issue in the earlier version.

medengineer commented 3 months ago

What was the last combination of GUI + plugin version that was working with your described setup?

Is the second DAQ a digital only card? Does disconnecting it make any difference with the latest GUI + plugin version?

theonlydvr commented 3 months ago

GUI version was 5.5.4 and plugin version was 0.1.0 from 2023-10-26.

The second DAQ is a digital only card but we can't disconnect it very easily since it's a PCI DAQ and there's behavior actively running off that computer.

medengineer commented 3 months ago

Got it. I'm working on a fix for this case, will post a version here to test early next week.

theonlydvr commented 3 months ago

Thank you! Great to hear!

medengineer commented 2 months ago

Hi,

Can you try replacing your nidaq-plugin with this one? This is a temporary fix to ignore your PCI device and only load any USB or PXI devices. The plugin is located in C:/ProgramData/Open Ephys/plugins

You should see output similar to below in the console window after inserting the new nidaq-plugin:

[open-ephys] Added device: Dev3 with product name: USB-6001 [open-ephys] Removed device: Dev5 with product name: PCIe-6321

theonlydvr commented 2 months ago

Looks like that works, thank you! This is probably better suited for a separate issue but is there any way to go above 40 kHz sampling?

jsiegle commented 2 months ago

Because the GUI's data processing callbacks are driven by your computer's audio card, if you have a card that can go up to 96 or 192 kHz, it would be possible to increase the max sample rate of the NIDAQ plugin. In general, though, we recommend using a separate piece of software (like Bonsai) to record >30 kHz signals.

What type of signals you'd like to record at higher sampling rates?

theonlydvr commented 2 months ago

The main curiosity was if it would be possible to visualize a stimulation waveform (50 us pulsewidth) with relatively good resolution. We use the NIDAQ plugin for other purposes but it could be nice to just be able to quickly visualize many stimulation outputs in the clean interface (and with the plugins) the OpenEphys GUI has to offer. I do think our sound cards can go up to 192 kHz so that would likely be sufficient but if there's an existing cleaner solution in other software that would work as well!

jsiegle commented 2 months ago

I would recommend acquiring the stimulation waveform using a separate NIDAQ card – the Bonsai DAQmx package should work well for this. You can configure the sampling rate to the max of what your DAQ can acquire.