Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
theonlydvr opened this issue Mar 29, 2024 · 11 comments
Open

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

theonlydvr opened this issue Mar 29, 2024 · 11 comments
Assignees

Comments

@theonlydvr
Copy link

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
Copy link
Collaborator

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?

@medengineer medengineer self-assigned this Mar 30, 2024
@theonlydvr
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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

@theonlydvr
Copy link
Author

Thank you! Great to hear!

@medengineer
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Contributor

jsiegle commented Apr 12, 2024

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
Copy link
Author

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
Copy link
Contributor

jsiegle commented Apr 16, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants