DaqCalibrateAIn causes problem with channels

masondar123 · May 28, 2013, 12:02pm

Hi,

I have been collecting data successfully using my Macbook pro and a measurement computing 1608FS for the last month. Typically the data that I collect from my potentiometer is from 0-2 volts.

I collected some test data yesterday and I received a warning that my channel had not been calibrated in over a month. I had previously calibrated my channels uing the standard DaqCalibrateAIn.m file in PTB. When I calibrated my channel (Chan 0) I could no longer collect any data, all I got were 'Nan' in a vector with the expected length of data.

I haven't changed anything in my code so something must have gone wrong with the during the calibration. I tried to reset the daq do another calibration and even calibrated another channel (Chan 1) and it produced the same results all NaN's in my data set. No other error appear while I am collecting data.

I even tried to calibrate the device using the measurement computing windows software. I was able to view the incoming data using their software and everything seemed to b working correctly, I also completed a test connecting DO0 to channel 0 and I received the expected sine wave with an average voltage of 2.54. However when using my mac again I still only got NaN's as data.

Additionally I calibrated Chan 2, 3 and 4 using the measurement and computing software. Both channels 2 and 4 seem to produce values in the way too high, each data point is around - 26,000,000. Channel 3 has values in the hundreds. From this i can presume that the whole device may be faulty or that something serious went wrong during the calibration using DaqCalibrateAIn.

Finally I get the following error at random times, sometimes after I make a change to the wiring:

ReceiveReports (249): source[7] 0000 != current source 26e479a0.

------------------------------------------------------------------------
Segmentation violation detected at Tue May 28 11:10:57 2013
------------------------------------------------------------------------

Configuration:
MATLAB Version: 7.10.0.499 (R2010a)
MATLAB License: 347765
Operating System: Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Window System: The X.Org Foundation (11006000), display /tmp/launch-lGVtNI/org.x:0
Current Visual: 0x22 (class 4, depth 24)
Processor ID: x86 Family 6 Model 5 Stepping 5, GenuineIntel
Virtual Machine: Java 1.6.0_45-b06-451-11M4406 with Apple Inc. Java HotSpot(TM) Client VM mixed mode
Default Encoding: UTF-8

Fault Count: 1

Register State:
eax = 27fea3bc ebx = 00000029
ecx = 946e56e4 edx = 00010001
esi = 27fb33bc edi = b9ffffff
ebp = b4a061b8 esp = b4a06194
eip = 92a75d4b flg = 00010202

Stack Trace:
[0] libobjc.A.dylib:objc_msgSend~(0x27fea3bc, 0x27fb33bc, 0xb4a061e8, 0x996e5345) + 27 bytes
[1] CoreFoundation:__CFRunLoopModeEqual~(0x247df130, 0xb4a062b0, 0xb4a061e8, 1) + 30 bytes
[2] CoreFoundation:CFEqual~(0x247df130, 0xb4a062b0, 0xb4a06248, 0x996d81d4) + 261 bytes
[3] CoreFoundation:__CFSetStandardEquateKeys~(0x0629e6c0, 0x247df130, 0xb4a062b0, 0x8fefe307) + 46 bytes
[4] CoreFoundation:CFBasicHashFindBucket~(0xb4a06268, 0x0629e6c0, 0xb4a062b0, 0x996e30ce) + 1844 bytes
[5] CoreFoundation:CFSetGetValue~(0x0629e6c0, 0xb4a062b0, 0x8ff20150, 0x932123b2) + 135 bytes
[6] CoreFoundation:__CFRunLoopFindMode~(0, 0x0629bb50, 0x0629bb58 "XTUM", 0x26e479a0) + 183 bytes
[7] CoreFoundation:CFRunLoopContainsSource~(0x0629bb50, 0x26e479a0, 0x27fb33bc, 0x27fbd25c "�y�&") + 114 bytes
[8] PsychHID.mexmaci:CheckRunLoopSource~(7, 0x27fa6f94 "ReceiveReports", 267, 1) + 368 bytes
[9] PsychHID.mexmaci:ReceiveReports~(7, 1, 0xb4a06488, 0x27fa755c "PSYCHHIDReceiveReports") + 459 bytes
[10] PsychHID.mexmaci:PSYCHHIDReceiveReports~(0x06756560, 0xb4a064e8 "ReceiveReports", 100, 0) + 934 bytes
[11] PsychHID.mexmaci:mexFunction~(1, 0xb4a06dc8, 2, 0xb4a06e28) + 1354 bytes
[12] libmex.dylib:mexRunMexFile(1, 0xb4a06dc8, 2, 0xb4a06e28) + 107 bytes
[13] libmex.dylib:Mfh_mex::runMexFileWithSignalProtection(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 111 bytes
[14] libmex.dylib:Mfh_mex::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 250 bytes
[15] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 300 bytes
[16] libmwm_interpreter.dylib:ResolverFunctionDesc::CallFunction(int, mxArray_tag**, int, mxArray_tag**)(0xb4a073b8 "P�y", 1, 0xb4a06dc8, 2) + 793 bytes
[17] libmwm_interpreter.dylib:Resolver::CallMFunction(int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*)(0xb4a06f94, 1, 1, 0x28553730) + 1462 bytes
[18] libmwm_interpreter.dylib:inResolveMFunctionCall(_m_function_desc*, int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*, inMarshalType*, int, mpsTypeSequenceNlhs const*, mxArray_tag* (*)(int))(0x28527a50, 1, 1, 0x28553730) + 462 bytes
[19] libmwm_interpreter.dylib:accelImpl::MFunctionCall(_accelOp**)(0xb4a07504 "xv��tv��", 0xb4a07518 "P�R(", 32, 0x2859fdc0 "��z%��Y(�5�&P:Q(") + 269 bytes
[20] libmwm_interpreter.dylib:accelImpl::Exec()(0xb4a07504 "xv��tv��", 0xac028a38, 0x005b5400, 0x26ec3534) + 199 bytes
[21] libmwm_interpreter.dylib:accelCode::Call(inMarshalType*, int*) const(0x26e04320 "�_�", 0xb4a07678, 0xb4a07674, 0x00a4b880) + 100 bytes
[22] libmwm_interpreter.dylib:inJit::ExecuteHotSegment(_inJitAccelInfo*, opcodes*, int*, int*)(0xb4a078b0, 0xb4a078fc, 0xb4a078cc, 0xb4a07ac0) + 1338 bytes
[23] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 9381, 500, 0) + 7720 bytes
[24] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 9381, 306, 0) + 112 bytes
[25] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e04750, 0xb4a07ac0, 0xb4a07ac0) + 266 bytes
[26] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x257ad6b0 "�\�", 0, 0x257ad6b0 "�\�", 2) + 932 bytes
[27] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(2, 0xb4a07d98, 2, 0xb4a07df8) + 696 bytes
[28] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 56 bytes
[29] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 300 bytes
[30] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(851, 0x240e651c "DaqAInScan_Test", 2, 2) + 990 bytes
[31] libmwm_interpreter.dylib:inDispatchCall(char const*, int, int, int, int*, int*)(2, 0xb4a08198, 0x03c2615c, 1) + 152 bytes
[32] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 100, 27, 0) + 5029 bytes
[33] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 100, 25, 0) + 112 bytes
[34] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285b6650 "�T�&��V", 0xb4a08360, 0xb4a08360) + 266 bytes
[35] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x28159450 "�\�", 0, 0x28159450 "�\�", 2) + 932 bytes
[36] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(1, 0xb4a08638, 2, 0xb4a08698) + 696 bytes
[37] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 56 bytes
[38] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 300 bytes
[39] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(850, 0x03bd484f "DaqAInScanBegin", 1, 2) + 990 bytes
[40] libmwm_interpreter.dylib:inCallFcnFromReference(32, 0xfffffff2, 1, 1) + 186 bytes
[41] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 31, 0) + 2212 bytes
[42] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
[43] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285a1fa0, 0xb4a08ba0, 0xb4a08ba0) + 266 bytes
[44] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x27ee7940 "�\�", 1, 0xb4a08e78, 0) + 932 bytes
[45] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(0, 0xb4a08e78, 0, 0xb4a08ed8 "��Y(��Y(") + 696 bytes
[46] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 56 bytes
[47] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 300 bytes
[48] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(827, 0, 0, 0) + 990 bytes
[49] libmwm_interpreter.dylib:inCallFcnFromReference(27, 0xfffffffc, 1, 0) + 186 bytes
[50] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 1, 0) + 2212 bytes
[51] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
[52] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e5b460, 0xb4a093e0, 0xb4a093e0) + 266 bytes
[53] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x26eaf0a0 "�\�", 1, 0xb4a0991c, 0) + 932 bytes
[54] libmwm_interpreter.dylib:inRunMfile(int, mxArray

If anyone has come across this before or has any advice i would be most grateful.

Alan

peter.scarfe · June 4, 2013, 4:35pm

I've found the screen shots, but they are a really low resolution. I just can't make anything out on them as they are tiny.

I'm really not sure if it could be a Java program. I'm not a developer of PTB, just someone who answers things on the forum and has started to help out with documentation. Mario would be you best bet as he is the main developer of PTB.

My gut instinct about Java being the problem, is no. As typing

help psychjava

at the command line doesn't show up anything which strikes me as being your problem. Most of the Java functions seem to relate to keyboard functions.

Maybe have a dig in the /PsychJava/ sub-directory of PTB to see if anything strikes you. I had a quick look but didn't see anything.

Thats just an (un)educated guess though.

I'm not sure how easy it is to downgrade updates on mac. I think all mac updates are logged on Apples site, so are re-downloadable. Certainly Java updates are.

Sorry I couldn't be of more help.

Mario is pretty active on the forum and helps people out massively, so give it a day or so you will probably get a reply more useful then mine.

Pete

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:
>
> sorry I put the screen shots in 'Photos'
>
> --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> >
> > Hi,
> >
> > Thanks for your post.
> >
> > I checked when the error first started which was around the 24th of May and none of my framework or application updates seem to fall close to that data.
> >
> > One of the main updates which occurred about a week before the 24th was a Java update, I'm not sure if that would have caused the error with DaqCalibrateAIn on my Mac?
> >
> > I have attached two screen shots in the attachements section under the name of this post. One shows the most recent updates in Software>Applications and the other Software>Frameworks.
> >
> > I think you are right about it not being a PTB issue, I only updated PTB 3.0.10 after the issues occurred in an attempt to solve the problem.
> >
> > I dont think it is a hardware issue as the DAQ works fine on a Windows PC using the Measurement Computing software and while on a newer Mac, iMac, I do get errors using the DAQ but it is not the same problem it is related to PTB trying to detect the correct device ID's which happened with my Mac Book Pro when I connected it to the DAQ for the first time.
> >
> > If the error was caused by some software update on my mac do you think it is easy to revert to an earlier system setting or at least downgrade the java update to see if that could solve the problem?
> >
> > kind regards,
> >
> > Alan
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "peter.scarfe" <peterscarfe@> wrote:
> > >
> > >
> > >
> > > I have no experience in the specifics of your setup, but this doesn't sound like a PTB problem to me.
> > >
> > > The reason I say this is if you haven't changed or updated your PTB version, then nothing should have changed on the PTB side of things i.e. the code will be exactly the same as when your kit was working.
> > >
> > > So it must be something else e.g.
> > >
> > > Operating system updates
> > > Matlab updates
> > > Hardware failure
> > > Other software updates
> > >
> > > Have any of these changed?
> > >
> > > If you have updated PTB between the kit working and not working, you can easily revert back to earlier versions of PTB using DownloadPsychtoolbox I believe. Just revert back to the version you were using initially. Then report back to the forum so the bug can be traced.
> > >
> > > But as I say, if your PTB version is exactly the same as when the kit was fully functional, it must be something else you have done.
> > >
> > > Peter
> > >
> > >
> > >
> > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm posting again hoping that someone might be able to respond to my initial post.
> > > >
> > > > I still cannot collect any data from channels that I calibrated using DaqCalibrateAIn on my MacBook Pro. No errors appear by the data is all NaNs. Has anyone very experienced this or does anyone know what may be causing the problem on my mac?
> > > >
> > > > kind regards,
> > > >
> > > > Alan
> > > >
> > > >
> > > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have been collecting data successfully using my Macbook pro and a measurement computing 1608FS for the last month. Typically the data that I collect from my potentiometer is from 0-2 volts.
> > > > >
> > > > > I collected some test data yesterday and I received a warning that my channel had not been calibrated in over a month. I had previously calibrated my channels uing the standard DaqCalibrateAIn.m file in PTB. When I calibrated my channel (Chan 0) I could no longer collect any data, all I got were 'Nan' in a vector with the expected length of data.
> > > > >
> > > > > I haven't changed anything in my code so something must have gone wrong with the during the calibration. I tried to reset the daq do another calibration and even calibrated another channel (Chan 1) and it produced the same results all NaN's in my data set. No other error appear while I am collecting data.
> > > > >
> > > > > I even tried to calibrate the device using the measurement computing windows software. I was able to view the incoming data using their software and everything seemed to b working correctly, I also completed a test connecting DO0 to channel 0 and I received the expected sine wave with an average voltage of 2.54. However when using my mac again I still only got NaN's as data.
> > > > >
> > > > > Additionally I calibrated Chan 2, 3 and 4 using the measurement and computing software. Both channels 2 and 4 seem to produce values in the way too high, each data point is around - 26,000,000. Channel 3 has values in the hundreds. From this i can presume that the whole device may be faulty or that something serious went wrong during the calibration using DaqCalibrateAIn.
> > > > >
> > > > > Finally I get the following error at random times, sometimes after I make a change to the wiring:
> > > > >
> > > > > ReceiveReports (249): source[7] 0000 != current source 26e479a0.
> > > > >
> > > > > ------------------------------------------------------------------------
> > > > > Segmentation violation detected at Tue May 28 11:10:57 2013
> > > > > ------------------------------------------------------------------------
> > > > >
> > > > > Configuration:
> > > > > MATLAB Version: 7.10.0.499 (R2010a)
> > > > > MATLAB License: 347765
> > > > > Operating System: Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
> > > > > Window System: The X.Org Foundation (11006000), display /tmp/launch-lGVtNI/org.x:0
> > > > > Current Visual: 0x22 (class 4, depth 24)
> > > > > Processor ID: x86 Family 6 Model 5 Stepping 5, GenuineIntel
> > > > > Virtual Machine: Java 1.6.0_45-b06-451-11M4406 with Apple Inc. Java HotSpot(TM) Client VM mixed mode
> > > > > Default Encoding: UTF-8
> > > > >
> > > > > Fault Count: 1
> > > > >
> > > > > Register State:
> > > > > eax = 27fea3bc ebx = 00000029
> > > > > ecx = 946e56e4 edx = 00010001
> > > > > esi = 27fb33bc edi = b9ffffff
> > > > > ebp = b4a061b8 esp = b4a06194
> > > > > eip = 92a75d4b flg = 00010202
> > > > >
> > > > > Stack Trace:
> > > > > [0] libobjc.A.dylib:objc_msgSend~(0x27fea3bc, 0x27fb33bc, 0xb4a061e8, 0x996e5345) + 27 bytes
> > > > > [1] CoreFoundation:__CFRunLoopModeEqual~(0x247df130, 0xb4a062b0, 0xb4a061e8, 1) + 30 bytes
> > > > > [2] CoreFoundation:CFEqual~(0x247df130, 0xb4a062b0, 0xb4a06248, 0x996d81d4) + 261 bytes
> > > > > [3] CoreFoundation:__CFSetStandardEquateKeys~(0x0629e6c0, 0x247df130, 0xb4a062b0, 0x8fefe307) + 46 bytes
> > > > > [4] CoreFoundation:CFBasicHashFindBucket~(0xb4a06268, 0x0629e6c0, 0xb4a062b0, 0x996e30ce) + 1844 bytes
> > > > > [5] CoreFoundation:CFSetGetValue~(0x0629e6c0, 0xb4a062b0, 0x8ff20150, 0x932123b2) + 135 bytes
> > > > > [6] CoreFoundation:__CFRunLoopFindMode~(0, 0x0629bb50, 0x0629bb58 "XTUM", 0x26e479a0) + 183 bytes
> > > > > [7] CoreFoundation:CFRunLoopContainsSource~(0x0629bb50, 0x26e479a0, 0x27fb33bc, 0x27fbd25c "�y�&") + 114 bytes
> > > > > [8] PsychHID.mexmaci:CheckRunLoopSource~(7, 0x27fa6f94 "ReceiveReports", 267, 1) + 368 bytes
> > > > > [9] PsychHID.mexmaci:ReceiveReports~(7, 1, 0xb4a06488, 0x27fa755c "PSYCHHIDReceiveReports") + 459 bytes
> > > > > [10] PsychHID.mexmaci:PSYCHHIDReceiveReports~(0x06756560, 0xb4a064e8 "ReceiveReports", 100, 0) + 934 bytes
> > > > > [11] PsychHID.mexmaci:mexFunction~(1, 0xb4a06dc8, 2, 0xb4a06e28) + 1354 bytes
> > > > > [12] libmex.dylib:mexRunMexFile(1, 0xb4a06dc8, 2, 0xb4a06e28) + 107 bytes
> > > > > [13] libmex.dylib:Mfh_mex::runMexFileWithSignalProtection(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 111 bytes
> > > > > [14] libmex.dylib:Mfh_mex::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 250 bytes
> > > > > [15] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 300 bytes
> > > > > [16] libmwm_interpreter.dylib:ResolverFunctionDesc::CallFunction(int, mxArray_tag**, int, mxArray_tag**)(0xb4a073b8 "P�y", 1, 0xb4a06dc8, 2) + 793 bytes
> > > > > [17] libmwm_interpreter.dylib:Resolver::CallMFunction(int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*)(0xb4a06f94, 1, 1, 0x28553730) + 1462 bytes
> > > > > [18] libmwm_interpreter.dylib:inResolveMFunctionCall(_m_function_desc*, int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*, inMarshalType*, int, mpsTypeSequenceNlhs const*, mxArray_tag* (*)(int))(0x28527a50, 1, 1, 0x28553730) + 462 bytes
> > > > > [19] libmwm_interpreter.dylib:accelImpl::MFunctionCall(_accelOp**)(0xb4a07504 "xv��tv��", 0xb4a07518 "P�R(", 32, 0x2859fdc0 "��z%��Y(�5�&P:Q(") + 269 bytes
> > > > > [20] libmwm_interpreter.dylib:accelImpl::Exec()(0xb4a07504 "xv��tv��", 0xac028a38, 0x005b5400, 0x26ec3534) + 199 bytes
> > > > > [21] libmwm_interpreter.dylib:accelCode::Call(inMarshalType*, int*) const(0x26e04320 "�_�", 0xb4a07678, 0xb4a07674, 0x00a4b880) + 100 bytes
> > > > > [22] libmwm_interpreter.dylib:inJit::ExecuteHotSegment(_inJitAccelInfo*, opcodes*, int*, int*)(0xb4a078b0, 0xb4a078fc, 0xb4a078cc, 0xb4a07ac0) + 1338 bytes
> > > > > [23] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 9381, 500, 0) + 7720 bytes
> > > > > [24] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 9381, 306, 0) + 112 bytes
> > > > > [25] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e04750, 0xb4a07ac0, 0xb4a07ac0) + 266 bytes
> > > > > [26] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x257ad6b0 "�\�", 0, 0x257ad6b0 "�\�", 2) + 932 bytes
> > > > > [27] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(2, 0xb4a07d98, 2, 0xb4a07df8) + 696 bytes
> > > > > [28] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 56 bytes
> > > > > [29] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 300 bytes
> > > > > [30] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(851, 0x240e651c "DaqAInScan_Test", 2, 2) + 990 bytes
> > > > > [31] libmwm_interpreter.dylib:inDispatchCall(char const*, int, int, int, int*, int*)(2, 0xb4a08198, 0x03c2615c, 1) + 152 bytes
> > > > > [32] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 100, 27, 0) + 5029 bytes
> > > > > [33] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 100, 25, 0) + 112 bytes
> > > > > [34] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285b6650 "�T�&��V", 0xb4a08360, 0xb4a08360) + 266 bytes
> > > > > [35] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x28159450 "�\�", 0, 0x28159450 "�\�", 2) + 932 bytes
> > > > > [36] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(1, 0xb4a08638, 2, 0xb4a08698) + 696 bytes
> > > > > [37] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 56 bytes
> > > > > [38] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 300 bytes
> > > > > [39] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(850, 0x03bd484f "DaqAInScanBegin", 1, 2) + 990 bytes
> > > > > [40] libmwm_interpreter.dylib:inCallFcnFromReference(32, 0xfffffff2, 1, 1) + 186 bytes
> > > > > [41] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 31, 0) + 2212 bytes
> > > > > [42] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > [43] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285a1fa0, 0xb4a08ba0, 0xb4a08ba0) + 266 bytes
> > > > > [44] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x27ee7940 "�\�", 1, 0xb4a08e78, 0) + 932 bytes
> > > > > [45] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(0, 0xb4a08e78, 0, 0xb4a08ed8 "��Y(��Y(") + 696 bytes
> > > > > [46] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 56 bytes
> > > > > [47] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 300 bytes
> > > > > [48] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(827, 0, 0, 0) + 990 bytes
> > > > > [49] libmwm_interpreter.dylib:inCallFcnFromReference(27, 0xfffffffc, 1, 0) + 186 bytes
> > > > > [50] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 1, 0) + 2212 bytes
> > > > > [51] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > [52] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e5b460, 0xb4a093e0, 0xb4a093e0) + 266 bytes
> > > > > [53] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x26eaf0a0 "�\�", 1, 0xb4a0991c, 0) + 932 bytes
> > > > > [54] libmwm_interpreter.dylib:inRunMfile(int, mxArray
> > > > >
> > > > >
> > > > > If anyone has come across this before or has any advice i would be most grateful.
> > > > >
> > > > > Alan
> > > > >
> > > >
> > >
> >
>

masondar123 · June 4, 2013, 4:39pm

I had sent my Matlab crash dumps to mathWorks to see if they could figure out the proble from their end of things.

They responded to me just now and stated that one of the matlab crashes was caused by 'PsychHID.mexmaci'. I wanted to mention this in case anyone else has experienced any problems or crashes with this MEX file?

thanks

Alan

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:
>
> sorry I put the screen shots in 'Photos'
>
> --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> >
> > Hi,
> >
> > Thanks for your post.
> >
> > I checked when the error first started which was around the 24th of May and none of my framework or application updates seem to fall close to that data.
> >
> > One of the main updates which occurred about a week before the 24th was a Java update, I'm not sure if that would have caused the error with DaqCalibrateAIn on my Mac?
> >
> > I have attached two screen shots in the attachements section under the name of this post. One shows the most recent updates in Software>Applications and the other Software>Frameworks.
> >
> > I think you are right about it not being a PTB issue, I only updated PTB 3.0.10 after the issues occurred in an attempt to solve the problem.
> >
> > I dont think it is a hardware issue as the DAQ works fine on a Windows PC using the Measurement Computing software and while on a newer Mac, iMac, I do get errors using the DAQ but it is not the same problem it is related to PTB trying to detect the correct device ID's which happened with my Mac Book Pro when I connected it to the DAQ for the first time.
> >
> > If the error was caused by some software update on my mac do you think it is easy to revert to an earlier system setting or at least downgrade the java update to see if that could solve the problem?
> >
> > kind regards,
> >
> > Alan
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "peter.scarfe" <peterscarfe@> wrote:
> > >
> > >
> > >
> > > I have no experience in the specifics of your setup, but this doesn't sound like a PTB problem to me.
> > >
> > > The reason I say this is if you haven't changed or updated your PTB version, then nothing should have changed on the PTB side of things i.e. the code will be exactly the same as when your kit was working.
> > >
> > > So it must be something else e.g.
> > >
> > > Operating system updates
> > > Matlab updates
> > > Hardware failure
> > > Other software updates
> > >
> > > Have any of these changed?
> > >
> > > If you have updated PTB between the kit working and not working, you can easily revert back to earlier versions of PTB using DownloadPsychtoolbox I believe. Just revert back to the version you were using initially. Then report back to the forum so the bug can be traced.
> > >
> > > But as I say, if your PTB version is exactly the same as when the kit was fully functional, it must be something else you have done.
> > >
> > > Peter
> > >
> > >
> > >
> > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm posting again hoping that someone might be able to respond to my initial post.
> > > >
> > > > I still cannot collect any data from channels that I calibrated using DaqCalibrateAIn on my MacBook Pro. No errors appear by the data is all NaNs. Has anyone very experienced this or does anyone know what may be causing the problem on my mac?
> > > >
> > > > kind regards,
> > > >
> > > > Alan
> > > >
> > > >
> > > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have been collecting data successfully using my Macbook pro and a measurement computing 1608FS for the last month. Typically the data that I collect from my potentiometer is from 0-2 volts.
> > > > >
> > > > > I collected some test data yesterday and I received a warning that my channel had not been calibrated in over a month. I had previously calibrated my channels uing the standard DaqCalibrateAIn.m file in PTB. When I calibrated my channel (Chan 0) I could no longer collect any data, all I got were 'Nan' in a vector with the expected length of data.
> > > > >
> > > > > I haven't changed anything in my code so something must have gone wrong with the during the calibration. I tried to reset the daq do another calibration and even calibrated another channel (Chan 1) and it produced the same results all NaN's in my data set. No other error appear while I am collecting data.
> > > > >
> > > > > I even tried to calibrate the device using the measurement computing windows software. I was able to view the incoming data using their software and everything seemed to b working correctly, I also completed a test connecting DO0 to channel 0 and I received the expected sine wave with an average voltage of 2.54. However when using my mac again I still only got NaN's as data.
> > > > >
> > > > > Additionally I calibrated Chan 2, 3 and 4 using the measurement and computing software. Both channels 2 and 4 seem to produce values in the way too high, each data point is around - 26,000,000. Channel 3 has values in the hundreds. From this i can presume that the whole device may be faulty or that something serious went wrong during the calibration using DaqCalibrateAIn.
> > > > >
> > > > > Finally I get the following error at random times, sometimes after I make a change to the wiring:
> > > > >
> > > > > ReceiveReports (249): source[7] 0000 != current source 26e479a0.
> > > > >
> > > > > ------------------------------------------------------------------------
> > > > > Segmentation violation detected at Tue May 28 11:10:57 2013
> > > > > ------------------------------------------------------------------------
> > > > >
> > > > > Configuration:
> > > > > MATLAB Version: 7.10.0.499 (R2010a)
> > > > > MATLAB License: 347765
> > > > > Operating System: Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
> > > > > Window System: The X.Org Foundation (11006000), display /tmp/launch-lGVtNI/org.x:0
> > > > > Current Visual: 0x22 (class 4, depth 24)
> > > > > Processor ID: x86 Family 6 Model 5 Stepping 5, GenuineIntel
> > > > > Virtual Machine: Java 1.6.0_45-b06-451-11M4406 with Apple Inc. Java HotSpot(TM) Client VM mixed mode
> > > > > Default Encoding: UTF-8
> > > > >
> > > > > Fault Count: 1
> > > > >
> > > > > Register State:
> > > > > eax = 27fea3bc ebx = 00000029
> > > > > ecx = 946e56e4 edx = 00010001
> > > > > esi = 27fb33bc edi = b9ffffff
> > > > > ebp = b4a061b8 esp = b4a06194
> > > > > eip = 92a75d4b flg = 00010202
> > > > >
> > > > > Stack Trace:
> > > > > [0] libobjc.A.dylib:objc_msgSend~(0x27fea3bc, 0x27fb33bc, 0xb4a061e8, 0x996e5345) + 27 bytes
> > > > > [1] CoreFoundation:__CFRunLoopModeEqual~(0x247df130, 0xb4a062b0, 0xb4a061e8, 1) + 30 bytes
> > > > > [2] CoreFoundation:CFEqual~(0x247df130, 0xb4a062b0, 0xb4a06248, 0x996d81d4) + 261 bytes
> > > > > [3] CoreFoundation:__CFSetStandardEquateKeys~(0x0629e6c0, 0x247df130, 0xb4a062b0, 0x8fefe307) + 46 bytes
> > > > > [4] CoreFoundation:CFBasicHashFindBucket~(0xb4a06268, 0x0629e6c0, 0xb4a062b0, 0x996e30ce) + 1844 bytes
> > > > > [5] CoreFoundation:CFSetGetValue~(0x0629e6c0, 0xb4a062b0, 0x8ff20150, 0x932123b2) + 135 bytes
> > > > > [6] CoreFoundation:__CFRunLoopFindMode~(0, 0x0629bb50, 0x0629bb58 "XTUM", 0x26e479a0) + 183 bytes
> > > > > [7] CoreFoundation:CFRunLoopContainsSource~(0x0629bb50, 0x26e479a0, 0x27fb33bc, 0x27fbd25c "�y�&") + 114 bytes
> > > > > [8] PsychHID.mexmaci:CheckRunLoopSource~(7, 0x27fa6f94 "ReceiveReports", 267, 1) + 368 bytes
> > > > > [9] PsychHID.mexmaci:ReceiveReports~(7, 1, 0xb4a06488, 0x27fa755c "PSYCHHIDReceiveReports") + 459 bytes
> > > > > [10] PsychHID.mexmaci:PSYCHHIDReceiveReports~(0x06756560, 0xb4a064e8 "ReceiveReports", 100, 0) + 934 bytes
> > > > > [11] PsychHID.mexmaci:mexFunction~(1, 0xb4a06dc8, 2, 0xb4a06e28) + 1354 bytes
> > > > > [12] libmex.dylib:mexRunMexFile(1, 0xb4a06dc8, 2, 0xb4a06e28) + 107 bytes
> > > > > [13] libmex.dylib:Mfh_mex::runMexFileWithSignalProtection(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 111 bytes
> > > > > [14] libmex.dylib:Mfh_mex::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 250 bytes
> > > > > [15] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 300 bytes
> > > > > [16] libmwm_interpreter.dylib:ResolverFunctionDesc::CallFunction(int, mxArray_tag**, int, mxArray_tag**)(0xb4a073b8 "P�y", 1, 0xb4a06dc8, 2) + 793 bytes
> > > > > [17] libmwm_interpreter.dylib:Resolver::CallMFunction(int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*)(0xb4a06f94, 1, 1, 0x28553730) + 1462 bytes
> > > > > [18] libmwm_interpreter.dylib:inResolveMFunctionCall(_m_function_desc*, int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*, inMarshalType*, int, mpsTypeSequenceNlhs const*, mxArray_tag* (*)(int))(0x28527a50, 1, 1, 0x28553730) + 462 bytes
> > > > > [19] libmwm_interpreter.dylib:accelImpl::MFunctionCall(_accelOp**)(0xb4a07504 "xv��tv��", 0xb4a07518 "P�R(", 32, 0x2859fdc0 "��z%��Y(�5�&P:Q(") + 269 bytes
> > > > > [20] libmwm_interpreter.dylib:accelImpl::Exec()(0xb4a07504 "xv��tv��", 0xac028a38, 0x005b5400, 0x26ec3534) + 199 bytes
> > > > > [21] libmwm_interpreter.dylib:accelCode::Call(inMarshalType*, int*) const(0x26e04320 "�_�", 0xb4a07678, 0xb4a07674, 0x00a4b880) + 100 bytes
> > > > > [22] libmwm_interpreter.dylib:inJit::ExecuteHotSegment(_inJitAccelInfo*, opcodes*, int*, int*)(0xb4a078b0, 0xb4a078fc, 0xb4a078cc, 0xb4a07ac0) + 1338 bytes
> > > > > [23] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 9381, 500, 0) + 7720 bytes
> > > > > [24] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 9381, 306, 0) + 112 bytes
> > > > > [25] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e04750, 0xb4a07ac0, 0xb4a07ac0) + 266 bytes
> > > > > [26] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x257ad6b0 "�\�", 0, 0x257ad6b0 "�\�", 2) + 932 bytes
> > > > > [27] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(2, 0xb4a07d98, 2, 0xb4a07df8) + 696 bytes
> > > > > [28] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 56 bytes
> > > > > [29] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 300 bytes
> > > > > [30] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(851, 0x240e651c "DaqAInScan_Test", 2, 2) + 990 bytes
> > > > > [31] libmwm_interpreter.dylib:inDispatchCall(char const*, int, int, int, int*, int*)(2, 0xb4a08198, 0x03c2615c, 1) + 152 bytes
> > > > > [32] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 100, 27, 0) + 5029 bytes
> > > > > [33] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 100, 25, 0) + 112 bytes
> > > > > [34] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285b6650 "�T�&��V", 0xb4a08360, 0xb4a08360) + 266 bytes
> > > > > [35] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x28159450 "�\�", 0, 0x28159450 "�\�", 2) + 932 bytes
> > > > > [36] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(1, 0xb4a08638, 2, 0xb4a08698) + 696 bytes
> > > > > [37] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 56 bytes
> > > > > [38] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 300 bytes
> > > > > [39] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(850, 0x03bd484f "DaqAInScanBegin", 1, 2) + 990 bytes
> > > > > [40] libmwm_interpreter.dylib:inCallFcnFromReference(32, 0xfffffff2, 1, 1) + 186 bytes
> > > > > [41] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 31, 0) + 2212 bytes
> > > > > [42] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > [43] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285a1fa0, 0xb4a08ba0, 0xb4a08ba0) + 266 bytes
> > > > > [44] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x27ee7940 "�\�", 1, 0xb4a08e78, 0) + 932 bytes
> > > > > [45] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(0, 0xb4a08e78, 0, 0xb4a08ed8 "��Y(��Y(") + 696 bytes
> > > > > [46] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 56 bytes
> > > > > [47] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 300 bytes
> > > > > [48] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(827, 0, 0, 0) + 990 bytes
> > > > > [49] libmwm_interpreter.dylib:inCallFcnFromReference(27, 0xfffffffc, 1, 0) + 186 bytes
> > > > > [50] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 1, 0) + 2212 bytes
> > > > > [51] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > [52] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e5b460, 0xb4a093e0, 0xb4a093e0) + 266 bytes
> > > > > [53] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x26eaf0a0 "�\�", 1, 0xb4a0991c, 0) + 932 bytes
> > > > > [54] libmwm_interpreter.dylib:inRunMfile(int, mxArray
> > > > >
> > > > >
> > > > > If anyone has come across this before or has any advice i would be most grateful.
> > > > >
> > > > > Alan
> > > > >
> > > >
> > >
> >
>

mariokleiner · June 7, 2013, 2:51am

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:

>
> Hi Pete,
>
> Thanks for your comments I really appreciate it!
>
> Sorry that this is such a long post my main questions are below:
>
> 1) Can I calibrate my DAQ on a windows computer using the Measurement Computing software and trust that this calibration will remain stable when I then try to collect data from a different? computer/operating system?
>

No, imho probably not. I don't know what the MCC software does, but our Daq toolbox stores and reads its calibration values in/from a .mat file with the filename:

calibFile = [DaqtoolboxConfigDir filesep 'DaqPrefs.mat']

Given that the MCC software doesn't write to our .mat files, both are independent, one can't affect the other. Unless of course the MCC software stores its calibration data in the DAQ device itself and the device automatically applies that internally stored calibration to all the data it sends over USB. That's something you'd need to find out from the user manual.

> 2) Does DaqCalibrateAIn do anything unusual that may cause errors within a mac based computer?
>

Here's what i think happens after looking at the code of DaqAIn.m and DaqCalibrateAIn.m and recovering from the nausea it caused in me:

1. DaqCalibrateAIn performs 5 repeated raw measurements for each calibration setting by calling DaqAIn() with the 'uncalibrated' flag set. For some reason, at least one measurement goes wrong in your case and DaqAIn returns NaN. Thanks to the non-existent error handling in DaqCalibrateAIn, that NaN is included in the mean() and causes a mean() of NaN which is propagated to the polyfit() fitting function which then computes NaN as correction coefficents and stores those in the calibration .mat files. Et voila, you have a unuseable file which will cause all future measurements to always return Nan!

Try to delete(calibFile) and see if measurements start working again.

The problem with DaqAIn.m is that it is totally fragile the way it is written. I don't know if the person who wrote it was actually awake and oriented while writing it, but just looking at the way it "checks" for errors is mildly horrifying to me, as is the idea of just silently returning NaN if something goes obviously totally wrong, instead of either handling or reporting it.

>
> The rest is more detailed info on what I have tried and the results I have got from different computers and operating systems.
>
> I decided to install Linux on two other computers to see if this would allow me to collect data accurately.
>

Good! A step in the right direction.

> My situation is getting even more unusual. I installed Ubuntu on a windows PC , >replacing the windows OS. Initially I had some difficulties trying to use >DaqCalibrateAIn, it caused several crashes but eventually after a few reboots I got it >working and I seem to be able to collect data using this OS and computer. I may use >this

What does "crashes" mean? What crashed? I assume your Psychtoolbox is up to date? Because i made some improvements to the Daq toolbox in the last release to make it a bit less horrible than before. On Linux unplugging and replugging your DAQ devices (or rebooting once) after installing the latest Psychtoolbox update should make it work. I made some tweaks which only get applied after the DAQ devices get redetected by the os.

computer to run my experiment but I would prefer to use my MacBook Pro or an iMac as the PC with linux has a lot of internal noise that can be heard from headphones and could disrupt the experiment i am doing.

>

You mean bad electronic shielding of the audio card or other EM interference?

> When I ran my code and calibration on an iMac with OSx I couldn't collect any data at all I kept having an issue with the device ID which has been discussed on this forum before:
>
> http://tech.groups.yahoo.com/group/psychtoolbox/message/15505.
>
> Basically every time you restart matlab or run DaqReset a different device ID for the DAQ is produced by DaqFind which completely messes up the code and causes an error. Eventually by forcing the device ID to be 8 every time and not using DaqFind I could collect data but it crashes after the second attempt to collect data every time, similar to what happened with my MacBook Pro, the crash relates to an issue with the PsychHID.mex file. After calibrating channel 0 I got the same error as before, data was all Nans and now I cannot collect data on any channel at all using OSx on this imac, everything comes up at 'Nothing Received.
>

What OSX version do you have? DAQ device enumeration is pretty broken on OSX. There's so far no robust way for us to detect interface #0 of the DAQ device thanks to Apple design brain damage, so we have to use rather fragile heuristics which frequently break thanks to even more Apple brain damage, like scrambling device ordering at each restart. Also they like to break our heuristic on every 2nd os update. These problems don't exist on Linux or Windows where we can detect which interface is which.

The PsychHID mex crash, usually after 'clear'ing PsychHID, e.g., via DaqReset, clear all etc. is a known bug to me, OSX only, the reason seems to be again MacOSX system bugs. I spent a very day not finding the cause for it. Afaict we do everything correctly, but it occassionally dies deep inside OS functions. There are various comments in the code and references to Apple developer forum posts which hint to the OSX USB stack being a rather fragile and buggy beast.

Yet another problem specific to 64-Bit PTB on OSX is that the DaqAInScan routines seem to be pretty broken for no apparent reason. I spent over 2.5 days with all kinds of debugging tools, code inspection, reading sample code and developer forums and whatnot, confirming that apparently we do everything right, there aren't any apparent malfunctions, but no data is received anyway. The same machines with 32-Bit PTB for OSX work at least without this specific problem. This is a bit tragic because i just cancelled support for 32-Bit PTB.

Switching to another OS than OSX and ideally Linux is the best thing you can do if you need to use the DAQ toolbox with less pain. Or sticking to 32-Bit Matlab/PTB if you must use OSX, without any future support though.

> I then decided to install Ubuntu on my iMac in parallel as it is only a borrowed >computer. I managed to install the rt kernal and could collect data BUT when I

The rt kernel is a nice thing to have for very demanding tasks, but not really needed for most applications.

attempted to use DaqCalibrateAIn on Channel 0 it caused the same error that I mentioned at the start of this post with my Macbook Pro. It appeared to calibrate the channel but after this when I tried to collect data, using the same code that I was using before, it only gives me NaNs, Other channels appear to be unaffected since I only calibrated channel 0 and I'm afraid to calibrate any more since when I did this with my macbook Pro it just caused the same problem each time.

>

It sounds like a timing problem. DaqAIn would be susceptible to that, given its poor design. Maybe the machines differ in processing speed or speed of their USB controller + OS combos, so you get different behaviour for that reason.

> I compared the values from my PC(Ubuntu), iMac(Ubuntu) and Windows which all seem to have slightly different values. The iMac appears to be off by about 12%.I was hoping to avoid the issues i'm having with DaqCalibrateAIn by calibrating on windows instead. Should the values from the same channel be exactly the same across different computers and platforms?
>

Ask MCC. But i would imagine that slight differences in supply voltage and current and bus power stability between different machines could also cause slightly different results.

> Could the fact that I installed Ubuntu in parallell with OSx be the reason for the difference between my two different ubuntu computers?
>

No. But machine speed or USB controller design.

As a quick check, try calling this before you call DaqCalibrateAIn and see if it helps:

options.secs = 0.1;
PsychHID('ReceiveReports',daq,options);

options.secs controls the timeout for data reception. Default is 0.01 for 10 msecs. If this is a timing effect, raising the timeout to 100 msecs via a 0.1 setting, or even higher settings may solve it.

Please report back the results asap.
-mario

> I'll have a look at the java issue with my MacBook Pro in the mean time. It seems like the issue may be related to mac-ptb compatibility or something similar as the error only seems to be produced on a Mac based computer.
>
> Thanks again for your help.
>
> Alan
>
> --- In psychtoolbox@yahoogroups.com, "peter.scarfe" <peterscarfe@> wrote:
> >
> >
> >
> > I've found the screen shots, but they are a really low resolution. I just can't make anything out on them as they are tiny.
> >
> > I'm really not sure if it could be a Java program. I'm not a developer of PTB, just someone who answers things on the forum and has started to help out with documentation. Mario would be you best bet as he is the main developer of PTB.
> >
> > My gut instinct about Java being the problem, is no. As typing
> >
> > help psychjava
> >
> > at the command line doesn't show up anything which strikes me as being your problem. Most of the Java functions seem to relate to keyboard functions.
> >
> > Maybe have a dig in the /PsychJava/ sub-directory of PTB to see if anything strikes you. I had a quick look but didn't see anything.
> >
> > Thats just an (un)educated guess though.
> >
> > I'm not sure how easy it is to downgrade updates on mac. I think all mac updates are logged on Apples site, so are re-downloadable. Certainly Java updates are.
> >
> > Sorry I couldn't be of more help.
> >
> > Mario is pretty active on the forum and helps people out massively, so give it a day or so you will probably get a reply more useful then mine.
> >
> > Pete
> >
> >
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > >
> > > sorry I put the screen shots in 'Photos'
> > >
> > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Thanks for your post.
> > > >
> > > > I checked when the error first started which was around the 24th of May and none of my framework or application updates seem to fall close to that data.
> > > >
> > > > One of the main updates which occurred about a week before the 24th was a Java update, I'm not sure if that would have caused the error with DaqCalibrateAIn on my Mac?
> > > >
> > > > I have attached two screen shots in the attachements section under the name of this post. One shows the most recent updates in Software>Applications and the other Software>Frameworks.
> > > >
> > > > I think you are right about it not being a PTB issue, I only updated PTB 3.0.10 after the issues occurred in an attempt to solve the problem.
> > > >
> > > > I dont think it is a hardware issue as the DAQ works fine on a Windows PC using the Measurement Computing software and while on a newer Mac, iMac, I do get errors using the DAQ but it is not the same problem it is related to PTB trying to detect the correct device ID's which happened with my Mac Book Pro when I connected it to the DAQ for the first time.
> > > >
> > > > If the error was caused by some software update on my mac do you think it is easy to revert to an earlier system setting or at least downgrade the java update to see if that could solve the problem?
> > > >
> > > > kind regards,
> > > >
> > > > Alan
> > > >
> > > >
> > > > --- In psychtoolbox@yahoogroups.com, "peter.scarfe" <peterscarfe@> wrote:
> > > > >
> > > > >
> > > > >
> > > > > I have no experience in the specifics of your setup, but this doesn't sound like a PTB problem to me.
> > > > >
> > > > > The reason I say this is if you haven't changed or updated your PTB version, then nothing should have changed on the PTB side of things i.e. the code will be exactly the same as when your kit was working.
> > > > >
> > > > > So it must be something else e.g.
> > > > >
> > > > > Operating system updates
> > > > > Matlab updates
> > > > > Hardware failure
> > > > > Other software updates
> > > > >
> > > > > Have any of these changed?
> > > > >
> > > > > If you have updated PTB between the kit working and not working, you can easily revert back to earlier versions of PTB using DownloadPsychtoolbox I believe. Just revert back to the version you were using initially. Then report back to the forum so the bug can be traced.
> > > > >
> > > > > But as I say, if your PTB version is exactly the same as when the kit was fully functional, it must be something else you have done.
> > > > >
> > > > > Peter
> > > > >
> > > > >
> > > > >
> > > > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm posting again hoping that someone might be able to respond to my initial post.
> > > > > >
> > > > > > I still cannot collect any data from channels that I calibrated using DaqCalibrateAIn on my MacBook Pro. No errors appear by the data is all NaNs. Has anyone very experienced this or does anyone know what may be causing the problem on my mac?
> > > > > >
> > > > > > kind regards,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > >
> > > > > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have been collecting data successfully using my Macbook pro and a measurement computing 1608FS for the last month. Typically the data that I collect from my potentiometer is from 0-2 volts.
> > > > > > >
> > > > > > > I collected some test data yesterday and I received a warning that my channel had not been calibrated in over a month. I had previously calibrated my channels uing the standard DaqCalibrateAIn.m file in PTB. When I calibrated my channel (Chan 0) I could no longer collect any data, all I got were 'Nan' in a vector with the expected length of data.
> > > > > > >
> > > > > > > I haven't changed anything in my code so something must have gone wrong with the during the calibration. I tried to reset the daq do another calibration and even calibrated another channel (Chan 1) and it produced the same results all NaN's in my data set. No other error appear while I am collecting data.
> > > > > > >
> > > > > > > I even tried to calibrate the device using the measurement computing windows software. I was able to view the incoming data using their software and everything seemed to b working correctly, I also completed a test connecting DO0 to channel 0 and I received the expected sine wave with an average voltage of 2.54. However when using my mac again I still only got NaN's as data.
> > > > > > >
> > > > > > > Additionally I calibrated Chan 2, 3 and 4 using the measurement and computing software. Both channels 2 and 4 seem to produce values in the way too high, each data point is around - 26,000,000. Channel 3 has values in the hundreds. From this i can presume that the whole device may be faulty or that something serious went wrong during the calibration using DaqCalibrateAIn.
> > > > > > >
> > > > > > > Finally I get the following error at random times, sometimes after I make a change to the wiring:
> > > > > > >
> > > > > > > ReceiveReports (249): source[7] 0000 != current source 26e479a0.
> > > > > > >
> > > > > > > ------------------------------------------------------------------------
> > > > > > > Segmentation violation detected at Tue May 28 11:10:57 2013
> > > > > > > ------------------------------------------------------------------------
> > > > > > >
> > > > > > > Configuration:
> > > > > > > MATLAB Version: 7.10.0.499 (R2010a)
> > > > > > > MATLAB License: 347765
> > > > > > > Operating System: Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
> > > > > > > Window System: The X.Org Foundation (11006000), display /tmp/launch-lGVtNI/org.x:0
> > > > > > > Current Visual: 0x22 (class 4, depth 24)
> > > > > > > Processor ID: x86 Family 6 Model 5 Stepping 5, GenuineIntel
> > > > > > > Virtual Machine: Java 1.6.0_45-b06-451-11M4406 with Apple Inc. Java HotSpot(TM) Client VM mixed mode
> > > > > > > Default Encoding: UTF-8
> > > > > > >
> > > > > > > Fault Count: 1
> > > > > > >
> > > > > > > Register State:
> > > > > > > eax = 27fea3bc ebx = 00000029
> > > > > > > ecx = 946e56e4 edx = 00010001
> > > > > > > esi = 27fb33bc edi = b9ffffff
> > > > > > > ebp = b4a061b8 esp = b4a06194
> > > > > > > eip = 92a75d4b flg = 00010202
> > > > > > >
> > > > > > > Stack Trace:
> > > > > > > [0] libobjc.A.dylib:objc_msgSend~(0x27fea3bc, 0x27fb33bc, 0xb4a061e8, 0x996e5345) + 27 bytes
> > > > > > > [1] CoreFoundation:__CFRunLoopModeEqual~(0x247df130, 0xb4a062b0, 0xb4a061e8, 1) + 30 bytes
> > > > > > > [2] CoreFoundation:CFEqual~(0x247df130, 0xb4a062b0, 0xb4a06248, 0x996d81d4) + 261 bytes
> > > > > > > [3] CoreFoundation:__CFSetStandardEquateKeys~(0x0629e6c0, 0x247df130, 0xb4a062b0, 0x8fefe307) + 46 bytes
> > > > > > > [4] CoreFoundation:CFBasicHashFindBucket~(0xb4a06268, 0x0629e6c0, 0xb4a062b0, 0x996e30ce) + 1844 bytes
> > > > > > > [5] CoreFoundation:CFSetGetValue~(0x0629e6c0, 0xb4a062b0, 0x8ff20150, 0x932123b2) + 135 bytes
> > > > > > > [6] CoreFoundation:__CFRunLoopFindMode~(0, 0x0629bb50, 0x0629bb58 "XTUM", 0x26e479a0) + 183 bytes
> > > > > > > [7] CoreFoundation:CFRunLoopContainsSource~(0x0629bb50, 0x26e479a0, 0x27fb33bc, 0x27fbd25c "�y�&") + 114 bytes
> > > > > > > [8] PsychHID.mexmaci:CheckRunLoopSource~(7, 0x27fa6f94 "ReceiveReports", 267, 1) + 368 bytes
> > > > > > > [9] PsychHID.mexmaci:ReceiveReports~(7, 1, 0xb4a06488, 0x27fa755c "PSYCHHIDReceiveReports") + 459 bytes
> > > > > > > [10] PsychHID.mexmaci:PSYCHHIDReceiveReports~(0x06756560, 0xb4a064e8 "ReceiveReports", 100, 0) + 934 bytes
> > > > > > > [11] PsychHID.mexmaci:mexFunction~(1, 0xb4a06dc8, 2, 0xb4a06e28) + 1354 bytes
> > > > > > > [12] libmex.dylib:mexRunMexFile(1, 0xb4a06dc8, 2, 0xb4a06e28) + 107 bytes
> > > > > > > [13] libmex.dylib:Mfh_mex::runMexFileWithSignalProtection(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 111 bytes
> > > > > > > [14] libmex.dylib:Mfh_mex::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 250 bytes
> > > > > > > [15] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27e814c0, 1, 0xb4a06dc8, 2) + 300 bytes
> > > > > > > [16] libmwm_interpreter.dylib:ResolverFunctionDesc::CallFunction(int, mxArray_tag**, int, mxArray_tag**)(0xb4a073b8 "P�y", 1, 0xb4a06dc8, 2) + 793 bytes
> > > > > > > [17] libmwm_interpreter.dylib:Resolver::CallMFunction(int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*)(0xb4a06f94, 1, 1, 0x28553730) + 1462 bytes
> > > > > > > [18] libmwm_interpreter.dylib:inResolveMFunctionCall(_m_function_desc*, int, int, _m_operand*, m_operand_storage*, int, _m_operand*, m_operand_storage*, int*, inMarshalType*, int, mpsTypeSequenceNlhs const*, mxArray_tag* (*)(int))(0x28527a50, 1, 1, 0x28553730) + 462 bytes
> > > > > > > [19] libmwm_interpreter.dylib:accelImpl::MFunctionCall(_accelOp**)(0xb4a07504 "xv��tv��", 0xb4a07518 "P�R(", 32, 0x2859fdc0 "��z%��Y(�5�&P:Q(") + 269 bytes
> > > > > > > [20] libmwm_interpreter.dylib:accelImpl::Exec()(0xb4a07504 "xv��tv��", 0xac028a38, 0x005b5400, 0x26ec3534) + 199 bytes
> > > > > > > [21] libmwm_interpreter.dylib:accelCode::Call(inMarshalType*, int*) const(0x26e04320 "�_�", 0xb4a07678, 0xb4a07674, 0x00a4b880) + 100 bytes
> > > > > > > [22] libmwm_interpreter.dylib:inJit::ExecuteHotSegment(_inJitAccelInfo*, opcodes*, int*, int*)(0xb4a078b0, 0xb4a078fc, 0xb4a078cc, 0xb4a07ac0) + 1338 bytes
> > > > > > > [23] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 9381, 500, 0) + 7720 bytes
> > > > > > > [24] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 9381, 306, 0) + 112 bytes
> > > > > > > [25] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e04750, 0xb4a07ac0, 0xb4a07ac0) + 266 bytes
> > > > > > > [26] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x257ad6b0 "�\�", 0, 0x257ad6b0 "�\�", 2) + 932 bytes
> > > > > > > [27] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(2, 0xb4a07d98, 2, 0xb4a07df8) + 696 bytes
> > > > > > > [28] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 56 bytes
> > > > > > > [29] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x257ad6b0 "�\�", 2, 0xb4a07d98, 2) + 300 bytes
> > > > > > > [30] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(851, 0x240e651c "DaqAInScan_Test", 2, 2) + 990 bytes
> > > > > > > [31] libmwm_interpreter.dylib:inDispatchCall(char const*, int, int, int, int*, int*)(2, 0xb4a08198, 0x03c2615c, 1) + 152 bytes
> > > > > > > [32] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 100, 27, 0) + 5029 bytes
> > > > > > > [33] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 100, 25, 0) + 112 bytes
> > > > > > > [34] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285b6650 "�T�&��V", 0xb4a08360, 0xb4a08360) + 266 bytes
> > > > > > > [35] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x28159450 "�\�", 0, 0x28159450 "�\�", 2) + 932 bytes
> > > > > > > [36] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(1, 0xb4a08638, 2, 0xb4a08698) + 696 bytes
> > > > > > > [37] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 56 bytes
> > > > > > > [38] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x28159450 "�\�", 1, 0xb4a08638, 2) + 300 bytes
> > > > > > > [39] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(850, 0x03bd484f "DaqAInScanBegin", 1, 2) + 990 bytes
> > > > > > > [40] libmwm_interpreter.dylib:inCallFcnFromReference(32, 0xfffffff2, 1, 1) + 186 bytes
> > > > > > > [41] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 31, 0) + 2212 bytes
> > > > > > > [42] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > > > [43] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x285a1fa0, 0xb4a08ba0, 0xb4a08ba0) + 266 bytes
> > > > > > > [44] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x27ee7940 "�\�", 1, 0xb4a08e78, 0) + 932 bytes
> > > > > > > [45] libmwm_interpreter.dylib:inRunMfile(int, mxArray_tag**, int, mxArray_tag**, Mfh_mp*, inWorkSpace_tag*)(0, 0xb4a08e78, 0, 0xb4a08ed8 "��Y(��Y(") + 696 bytes
> > > > > > > [46] libmwm_interpreter.dylib:Mfh_mp::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 56 bytes
> > > > > > > [47] libmwm_dispatcher.dylib:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x27ee7940 "�\�", 0, 0xb4a08e78, 0) + 300 bytes
> > > > > > > [48] libmwm_interpreter.dylib:inDispatchFromStack(int, char const*, int, int)(827, 0, 0, 0) + 990 bytes
> > > > > > > [49] libmwm_interpreter.dylib:inCallFcnFromReference(27, 0xfffffffc, 1, 0) + 186 bytes
> > > > > > > [50] libmwm_interpreter.dylib:inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag volatile*, int*)(1, 0, 1, 0) + 2212 bytes
> > > > > > > [51] libmwm_interpreter.dylib:protected_inInterp(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(1, 0, 1, 0) + 112 bytes
> > > > > > > [52] libmwm_interpreter.dylib:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*, int*)(0, 0x26e5b460, 0xb4a093e0, 0xb4a093e0) + 266 bytes
> > > > > > > [53] libmwm_interpreter.dylib:inExecuteMFunctionOrScript(Mfh_mp*, bool)(0x26eaf0a0 "�\�", 1, 0xb4a0991c, 0) + 932 bytes
> > > > > > > [54] libmwm_interpreter.dylib:inRunMfile(int, mxArray
> > > > > > >
> > > > > > >
> > > > > > > If anyone has come across this before or has any advice i would be most grateful.
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

mariokleiner · June 7, 2013, 2:25pm

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:

>
>
> > Here's what i think happens after looking at the code of DaqAIn.m and DaqCalibrateAIn.m and recovering from the nausea it caused in me:
> >
> > 1. DaqCalibrateAIn performs 5 repeated raw measurements for each calibration setting by calling DaqAIn() with the 'uncalibrated' flag set. For some reason, at least one measurement goes wrong in your case and DaqAIn returns NaN. Thanks to the non-existent error handling in DaqCalibrateAIn, that NaN is included in the mean() and causes a mean() of NaN which is propagated to the polyfit() fitting function which then computes NaN as correction coefficents and stores those in the calibration .mat files. Et voila, you have a unuseable file which will cause all future measurements to always return Nan!
> >
> > Try to delete(calibFile) and see if measurements start working again.
> >
> > The problem with DaqAIn.m is that it is totally fragile the way it is written. I don't know if the person who wrote it was actually awake and oriented while writing it, but just looking at the way it "checks" for errors is mildly horrifying to me, as is the idea of just silently returning NaN if something goes obviously totally wrong, instead of either handling or reporting it.
> >
>
> This worked for me on my MacBook Pro (10.7.5). Once the file was deleted i could collect data normally. Also when I checked the 5 iterations inside DaqCalibrateAIn where it calls DaqAIn, you were correct some of the vales appear as NaN while others appear to be normal expected values.
>
> Using your suggested code with options.secs adjusted to 10ms fixed the problem I was having with the iMac(Ubuntu) and the Macbook Pro (original reason why I posted). So I guess it was simply a timing issue on these computers.
>
> But it is unusual that I was able to calibrate my DAQ on my MacBook Pro several times over the last month and then suddenly it stopped working and gave me NaN's.
>

Timing issues. Something slightly changed the timing of your machine, a software update or maybe plugging in a new type of device, or maybe some performance degradation of the system due to old age. A properly written DaqAIn function wouldn't be sensitive to that. I'll try to improve it a bit.

> For the iMac(OSx) even if I delete the DaqPrefs.mat file and recalibrate using the suggested adjusted options.secs it just tells me 'Nothing Received' as before and matlab crashes on the second attempt at collecting data.
>

Is this a 32-Bit or 64-Bit Matlab on OSX?

> > You mean bad electronic shielding of the audio card or other EM interference?
>
> Yes i think that's what it is. I get a bit of noise from the processing on the computer in my headphones. Its not a major issues, especially now since I can record data on the iMac with Linux.
>

Ok. The internet is full of howtos to eliminate/reduce such problems, also some specific to Ubuntu Linux. Dynamic power management activity in combination with low quality mainboards or power supplies can be one cause. Sometimes one can workaround such issues without the need to replace hardware with some changes in system settings if one can isolate what kind of activity causes the noise.

Something that could help against bad shielding would be to run the "alsamixer" command line utility and mute or dial down all audio setting you don't need.

> > What OSX version do you have? DAQ device enumeration is pretty broken on OSX. There's so far no robust way for us to detect interface #0 of the DAQ device thanks to Apple design brain damage, so we have to use rather fragile heuristics which frequently break thanks to even more Apple brain damage, like scrambling device ordering at each restart. Also they like to break our heuristic on every 2nd os update. These problems don't exist on Linux or Windows where we can detect which interface is which.
>
> The iMac is using 10.8.1 OSx. I solved the enumeration issue by not using DaqFind and setting daq = 8. Also inside DaqAInScan I adjusted the line 475 (InterfaceInds = strmatch(SN,AllSNs);) and put in:
>
> InterfaceInds = (2:8)';
>
> I checked the device ID's before hand to ensure that these values are correct and everything seems to work fine.
>

What is the output of devs = PsychHIDDAQS; Would be interesting to know why enumeration breaks that badly on your 10.8 system.

-mario

mariokleiner · June 7, 2013, 2:52pm

Can you please test asap if this updated DaqAIn.m works better for you:

https://raw.github.com/kleinerm/Psychtoolbox-3/master/Psychtoolbox/PsychHardware/Daq/DaqAIn.m

-mario

--- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@...> wrote:
>
>
>
> --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> >
> >
> > > Here's what i think happens after looking at the code of DaqAIn.m and DaqCalibrateAIn.m and recovering from the nausea it caused in me:
> > >
> > > 1. DaqCalibrateAIn performs 5 repeated raw measurements for each calibration setting by calling DaqAIn() with the 'uncalibrated' flag set. For some reason, at least one measurement goes wrong in your case and DaqAIn returns NaN. Thanks to the non-existent error handling in DaqCalibrateAIn, that NaN is included in the mean() and causes a mean() of NaN which is propagated to the polyfit() fitting function which then computes NaN as correction coefficents and stores those in the calibration .mat files. Et voila, you have a unuseable file which will cause all future measurements to always return Nan!
> > >
> > > Try to delete(calibFile) and see if measurements start working again.
> > >
> > > The problem with DaqAIn.m is that it is totally fragile the way it is written. I don't know if the person who wrote it was actually awake and oriented while writing it, but just looking at the way it "checks" for errors is mildly horrifying to me, as is the idea of just silently returning NaN if something goes obviously totally wrong, instead of either handling or reporting it.
> > >
> >
> > This worked for me on my MacBook Pro (10.7.5). Once the file was deleted i could collect data normally. Also when I checked the 5 iterations inside DaqCalibrateAIn where it calls DaqAIn, you were correct some of the vales appear as NaN while others appear to be normal expected values.
> >
> > Using your suggested code with options.secs adjusted to 10ms fixed the problem I was having with the iMac(Ubuntu) and the Macbook Pro (original reason why I posted). So I guess it was simply a timing issue on these computers.
> >
> > But it is unusual that I was able to calibrate my DAQ on my MacBook Pro several times over the last month and then suddenly it stopped working and gave me NaN's.
> >
>
> Timing issues. Something slightly changed the timing of your machine, a software update or maybe plugging in a new type of device, or maybe some performance degradation of the system due to old age. A properly written DaqAIn function wouldn't be sensitive to that. I'll try to improve it a bit.
>
> > For the iMac(OSx) even if I delete the DaqPrefs.mat file and recalibrate using the suggested adjusted options.secs it just tells me 'Nothing Received' as before and matlab crashes on the second attempt at collecting data.
> >
>
> Is this a 32-Bit or 64-Bit Matlab on OSX?
>
> > > You mean bad electronic shielding of the audio card or other EM interference?
> >
> > Yes i think that's what it is. I get a bit of noise from the processing on the computer in my headphones. Its not a major issues, especially now since I can record data on the iMac with Linux.
> >
>
> Ok. The internet is full of howtos to eliminate/reduce such problems, also some specific to Ubuntu Linux. Dynamic power management activity in combination with low quality mainboards or power supplies can be one cause. Sometimes one can workaround such issues without the need to replace hardware with some changes in system settings if one can isolate what kind of activity causes the noise.
>
> Something that could help against bad shielding would be to run the "alsamixer" command line utility and mute or dial down all audio setting you don't need.
>
> > > What OSX version do you have? DAQ device enumeration is pretty broken on OSX. There's so far no robust way for us to detect interface #0 of the DAQ device thanks to Apple design brain damage, so we have to use rather fragile heuristics which frequently break thanks to even more Apple brain damage, like scrambling device ordering at each restart. Also they like to break our heuristic on every 2nd os update. These problems don't exist on Linux or Windows where we can detect which interface is which.
> >
> > The iMac is using 10.8.1 OSx. I solved the enumeration issue by not using DaqFind and setting daq = 8. Also inside DaqAInScan I adjusted the line 475 (InterfaceInds = strmatch(SN,AllSNs);) and put in:
> >
> > InterfaceInds = (2:8)';
> >
> > I checked the device ID's before hand to ensure that these values are correct and everything seems to work fine.
> >
>
> What is the output of devs = PsychHIDDAQS; Would be interesting to know why enumeration breaks that badly on your 10.8 system.
>
> -mario
>

masondar123 · June 7, 2013, 5:04pm

Tested the code and it seems to resolve the issue for both the iMac running OSx and my Macbook Pro, both of which are 64bit.

The iMac no longer produces any NaNs during the 5 iterations for the calibration but the crash still occurs during the second attempt to collect data. But I can now see data coming in during the first attempt to collect data, so the new code got rid of my 'Nothing Received' problem as well.

With my MacBook Pro it worked as with the iMac, no NaNs but the code itself produced some issues when I tried to use the new code for collecting data. I got the following error:

??? Error using ==> DaqAInScan
Too many output arguments.

Error in ==> DaqAInScanBegin at 26
[data,params]=DaqAInScan(daq,options);

Error in ==> basic_data_acquisition at 32
params = DaqAInScanBegin(DeviceIndex,options);

I'm not sure how to resolve this. I tried to adjust all DaqAInScanContinue/Begin/end so that the outputs '[data,params]' were removed and replaced with the 'v' that is now at the top of the new code. Also I adjusted the inputs and included the input for 'range':

v=DaqAInScan(daq,options,1);

But even with these changes I still got the following error:

??? Undefined function or method 'eq' for input arguments of type 'struct'.

Error in ==> ismember at 76
tf(i) = any(a(i)==s(:)); % ANY returns logical.

Error in ==> DaqAInScan at 107
if ~ismember(channel,0:MaxChannelID)

Error in ==> DaqAInScanBegin at 27
v=DaqAInScan(daq,options,1);

Error in ==> basic_data_acquisition at 32
params = DaqAInScanBegin(DeviceIndex,options);

I'm not sure what I may have done wrong because when I used the new code on the iMac to collect data after the calibration I had no errors?

The output from my iMac using devs = PsychHIDDAQS is in the 'files' section of this forum under the name 'DaqCalibrateAIn_issue_imac'.

Thanks for the updated code and for the advice on the noise issue with the PC I'll have a look on the internet and see what I can do to reduce the noise issue.

cheers,

Alan

--- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@...> wrote:
>
>
>
> Can you please test asap if this updated DaqAIn.m works better for you:
>
> https://raw.github.com/kleinerm/Psychtoolbox-3/master/Psychtoolbox/PsychHardware/Daq/DaqAIn.m
>
> -mario
>
> --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> >
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > >
> > >
> > > > Here's what i think happens after looking at the code of DaqAIn.m and DaqCalibrateAIn.m and recovering from the nausea it caused in me:
> > > >
> > > > 1. DaqCalibrateAIn performs 5 repeated raw measurements for each calibration setting by calling DaqAIn() with the 'uncalibrated' flag set. For some reason, at least one measurement goes wrong in your case and DaqAIn returns NaN. Thanks to the non-existent error handling in DaqCalibrateAIn, that NaN is included in the mean() and causes a mean() of NaN which is propagated to the polyfit() fitting function which then computes NaN as correction coefficents and stores those in the calibration .mat files. Et voila, you have a unuseable file which will cause all future measurements to always return Nan!
> > > >
> > > > Try to delete(calibFile) and see if measurements start working again.
> > > >
> > > > The problem with DaqAIn.m is that it is totally fragile the way it is written. I don't know if the person who wrote it was actually awake and oriented while writing it, but just looking at the way it "checks" for errors is mildly horrifying to me, as is the idea of just silently returning NaN if something goes obviously totally wrong, instead of either handling or reporting it.
> > > >
> > >
> > > This worked for me on my MacBook Pro (10.7.5). Once the file was deleted i could collect data normally. Also when I checked the 5 iterations inside DaqCalibrateAIn where it calls DaqAIn, you were correct some of the vales appear as NaN while others appear to be normal expected values.
> > >
> > > Using your suggested code with options.secs adjusted to 10ms fixed the problem I was having with the iMac(Ubuntu) and the Macbook Pro (original reason why I posted). So I guess it was simply a timing issue on these computers.
> > >
> > > But it is unusual that I was able to calibrate my DAQ on my MacBook Pro several times over the last month and then suddenly it stopped working and gave me NaN's.
> > >
> >
> > Timing issues. Something slightly changed the timing of your machine, a software update or maybe plugging in a new type of device, or maybe some performance degradation of the system due to old age. A properly written DaqAIn function wouldn't be sensitive to that. I'll try to improve it a bit.
> >
> > > For the iMac(OSx) even if I delete the DaqPrefs.mat file and recalibrate using the suggested adjusted options.secs it just tells me 'Nothing Received' as before and matlab crashes on the second attempt at collecting data.
> > >
> >
> > Is this a 32-Bit or 64-Bit Matlab on OSX?
> >
> > > > You mean bad electronic shielding of the audio card or other EM interference?
> > >
> > > Yes i think that's what it is. I get a bit of noise from the processing on the computer in my headphones. Its not a major issues, especially now since I can record data on the iMac with Linux.
> > >
> >
> > Ok. The internet is full of howtos to eliminate/reduce such problems, also some specific to Ubuntu Linux. Dynamic power management activity in combination with low quality mainboards or power supplies can be one cause. Sometimes one can workaround such issues without the need to replace hardware with some changes in system settings if one can isolate what kind of activity causes the noise.
> >
> > Something that could help against bad shielding would be to run the "alsamixer" command line utility and mute or dial down all audio setting you don't need.
> >
> > > > What OSX version do you have? DAQ device enumeration is pretty broken on OSX. There's so far no robust way for us to detect interface #0 of the DAQ device thanks to Apple design brain damage, so we have to use rather fragile heuristics which frequently break thanks to even more Apple brain damage, like scrambling device ordering at each restart. Also they like to break our heuristic on every 2nd os update. These problems don't exist on Linux or Windows where we can detect which interface is which.
> > >
> > > The iMac is using 10.8.1 OSx. I solved the enumeration issue by not using DaqFind and setting daq = 8. Also inside DaqAInScan I adjusted the line 475 (InterfaceInds = strmatch(SN,AllSNs);) and put in:
> > >
> > > InterfaceInds = (2:8)';
> > >
> > > I checked the device ID's before hand to ensure that these values are correct and everything seems to work fine.
> > >
> >
> > What is the output of devs = PsychHIDDAQS; Would be interesting to know why enumeration breaks that badly on your 10.8 system.
> >
> > -mario
> >
>

mariokleiner · June 10, 2013, 9:46pm

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:

>
> Tested the code and it seems to resolve the issue for both the iMac running OSx and my Macbook Pro, both of which are 64bit.
>

64-Bit Matlab with 64-Bit Psychtoolbox? What is the output of calling the function:

Is64Bit

> The iMac no longer produces any NaNs during the 5 iterations for the calibration but the crash still occurs during the second attempt to collect data. But I can now see data coming in during the first attempt to collect data, so the new code got rid of my 'Nothing Received' problem as well.
>

This is your iMac under 10.8 OSX with your hack of not using DaqFind and modifying DaqAInScan.m, right?

> With my MacBook Pro it worked as with the iMac, no NaNs but the code itself produced some issues when I tried to use the new code for collecting data. I got the following error:
>

This makes no sense:

> Error in ==> DaqAInScan at 107
> if ~ismember(channel,0:MaxChannelID)

Line 107 is part of the help text of the function and there hasn't ever been such an if statement in our DaqAInScan.m file.

Something is wrong with your installation on that machine.
-mario

> ??? Error using ==> DaqAInScan
> Too many output arguments.
>
> Error in ==> DaqAInScanBegin at 26
> [data,params]=DaqAInScan(daq,options);
>
> Error in ==> basic_data_acquisition at 32
> params = DaqAInScanBegin(DeviceIndex,options);
>
> I'm not sure how to resolve this. I tried to adjust all DaqAInScanContinue/Begin/end so that the outputs '[data,params]' were removed and replaced with the 'v' that is now at the top of the new code. Also I adjusted the inputs and included the input for 'range':
>
> v=DaqAInScan(daq,options,1);
>
>
> But even with these changes I still got the following error:
>
> ??? Undefined function or method 'eq' for input arguments of type 'struct'.
>
> Error in ==> ismember at 76
> tf(i) = any(a(i)==s(:)); % ANY returns logical.
>
> Error in ==> DaqAInScan at 107
> if ~ismember(channel,0:MaxChannelID)
>
> Error in ==> DaqAInScanBegin at 27
> v=DaqAInScan(daq,options,1);
>
> Error in ==> basic_data_acquisition at 32
> params = DaqAInScanBegin(DeviceIndex,options);
>
> I'm not sure what I may have done wrong because when I used the new code on the iMac to collect data after the calibration I had no errors?
>
> The output from my iMac using devs = PsychHIDDAQS is in the 'files' section of this forum under the name 'DaqCalibrateAIn_issue_imac'.
>
> Thanks for the updated code and for the advice on the noise issue with the PC I'll have a look on the internet and see what I can do to reduce the noise issue.
>
> cheers,
>
> Alan
>
>
>
>
> --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> >
> >
> >
> > Can you please test asap if this updated DaqAIn.m works better for you:
> >
> > https://raw.github.com/kleinerm/Psychtoolbox-3/master/Psychtoolbox/PsychHardware/Daq/DaqAIn.m
> >
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> > >
> > >
> > >
> > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > >
> > > >
> > > > > Here's what i think happens after looking at the code of DaqAIn.m and DaqCalibrateAIn.m and recovering from the nausea it caused in me:
> > > > >
> > > > > 1. DaqCalibrateAIn performs 5 repeated raw measurements for each calibration setting by calling DaqAIn() with the 'uncalibrated' flag set. For some reason, at least one measurement goes wrong in your case and DaqAIn returns NaN. Thanks to the non-existent error handling in DaqCalibrateAIn, that NaN is included in the mean() and causes a mean() of NaN which is propagated to the polyfit() fitting function which then computes NaN as correction coefficents and stores those in the calibration .mat files. Et voila, you have a unuseable file which will cause all future measurements to always return Nan!
> > > > >
> > > > > Try to delete(calibFile) and see if measurements start working again.
> > > > >
> > > > > The problem with DaqAIn.m is that it is totally fragile the way it is written. I don't know if the person who wrote it was actually awake and oriented while writing it, but just looking at the way it "checks" for errors is mildly horrifying to me, as is the idea of just silently returning NaN if something goes obviously totally wrong, instead of either handling or reporting it.
> > > > >
> > > >
> > > > This worked for me on my MacBook Pro (10.7.5). Once the file was deleted i could collect data normally. Also when I checked the 5 iterations inside DaqCalibrateAIn where it calls DaqAIn, you were correct some of the vales appear as NaN while others appear to be normal expected values.
> > > >
> > > > Using your suggested code with options.secs adjusted to 10ms fixed the problem I was having with the iMac(Ubuntu) and the Macbook Pro (original reason why I posted). So I guess it was simply a timing issue on these computers.
> > > >
> > > > But it is unusual that I was able to calibrate my DAQ on my MacBook Pro several times over the last month and then suddenly it stopped working and gave me NaN's.
> > > >
> > >
> > > Timing issues. Something slightly changed the timing of your machine, a software update or maybe plugging in a new type of device, or maybe some performance degradation of the system due to old age. A properly written DaqAIn function wouldn't be sensitive to that. I'll try to improve it a bit.
> > >
> > > > For the iMac(OSx) even if I delete the DaqPrefs.mat file and recalibrate using the suggested adjusted options.secs it just tells me 'Nothing Received' as before and matlab crashes on the second attempt at collecting data.
> > > >
> > >
> > > Is this a 32-Bit or 64-Bit Matlab on OSX?
> > >
> > > > > You mean bad electronic shielding of the audio card or other EM interference?
> > > >
> > > > Yes i think that's what it is. I get a bit of noise from the processing on the computer in my headphones. Its not a major issues, especially now since I can record data on the iMac with Linux.
> > > >
> > >
> > > Ok. The internet is full of howtos to eliminate/reduce such problems, also some specific to Ubuntu Linux. Dynamic power management activity in combination with low quality mainboards or power supplies can be one cause. Sometimes one can workaround such issues without the need to replace hardware with some changes in system settings if one can isolate what kind of activity causes the noise.
> > >
> > > Something that could help against bad shielding would be to run the "alsamixer" command line utility and mute or dial down all audio setting you don't need.
> > >
> > > > > What OSX version do you have? DAQ device enumeration is pretty broken on OSX. There's so far no robust way for us to detect interface #0 of the DAQ device thanks to Apple design brain damage, so we have to use rather fragile heuristics which frequently break thanks to even more Apple brain damage, like scrambling device ordering at each restart. Also they like to break our heuristic on every 2nd os update. These problems don't exist on Linux or Windows where we can detect which interface is which.
> > > >
> > > > The iMac is using 10.8.1 OSx. I solved the enumeration issue by not using DaqFind and setting daq = 8. Also inside DaqAInScan I adjusted the line 475 (InterfaceInds = strmatch(SN,AllSNs);) and put in:
> > > >
> > > > InterfaceInds = (2:8)';
> > > >
> > > > I checked the device ID's before hand to ensure that these values are correct and everything seems to work fine.
> > > >
> > >
> > > What is the output of devs = PsychHIDDAQS; Would be interesting to know why enumeration breaks that badly on your 10.8 system.
> > >
> > > -mario
> > >
> >
>

masondar123 · June 12, 2013, 12:23pm

> 64-Bit Matlab with 64-Bit Psychtoolbox? What is the output of calling the function:
>
> Is64Bit

Sorry that was a mistake my MacbookPro is 64bit system but I run 32bit Matlab, this was the only one that was available to me when I originally installed it (R2010a). I have the latest version of Psychtoolbox installed as well.

I upgraded to the new R2013a Matlab (64 bit) and this caused severe problems with DaqFind, it continually changed the ID (like on the iMac) and I couldn't collect any data at all so I resorted to using the older version of Matlab, R2010a, instead.

On this system everything has been working fine until I installed the PsychtoolboxKernelDriver. This caused problems, specifically synchronization errors such as receiving the large red warning sign at the start of my experiment. I managed to remove most of the sync errors by reducing the resolution of the screen but I still get the following error:

PTB-ERROR: Screen('Flip'); beamposition timestamping computed an *impossible stimulus onset value* of 2284.524061 secs, which would indicate that
PTB-ERROR: stimulus onset happened *before* it was actually requested! (Earliest theoretically possible 2284.528720 secs).

PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 2284.534550, scanline = 523
PTB-ERROR: Some more diagnostic values (only for experts): line_pre_swaprequest = 200, line_post_swaprequest = 208, time_post_swaprequest = 2284.528871
PTB-ERROR: Some more diagnostic values (only for experts): preflip_vblcount = 157, preflip_vbltimestamp = 2284.521415
PTB-ERROR: Some more diagnostic values (only for experts): postflip_vblcount = 0, postflip_vbltimestamp = -1.000000, vbltimestampquery_retrycount = 0

PTB-ERROR: I have enabled additional cross checking between beamposition based and kernel-level based timestamping.
PTB-ERROR: This should allow to get a better idea of what's going wrong if successive invocations of Screen('Flip');
PTB-ERROR: fail to deliver proper timestamps as well. It may even fix the problem if the culprit would be a bug in
PTB-ERROR: beamposition based high precision timestamping. We will see...

PTB-ERROR: An equally likely cause would be that Synchronization of stimulus onset (buffer swap) to the
PTB-ERROR: vertical blank interval VBL is not working properly.
PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing
PTB-ERROR: becomes quite futile. Also read 'help SyncTrouble' !
VBL timestamp deviation: precount=170 , postcount=171, delta = 1, postflip_vbltimestamp = 2284.720362 - beampos_vbltimestamp = 2284.707961 == Delta is = 0.012401

PTB-ERROR: Screen('Flip'); beamposition timestamping computed an *impossible stimulus onset value* of 2284.707961 secs, which would indicate that
PTB-ERROR: stimulus onset happened *before* it was actually requested! (Earliest theoretically possible 2284.716812 secs).

PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 2284.720052, scanline = 627
PTB-ERROR: Some more diagnostic values (only for experts): line_pre_swaprequest = 447, line_post_swaprequest = 456, time_post_swaprequest = 2284.716965
PTB-ERROR: Some more diagnostic values (only for experts): preflip_vblcount = 170, preflip_vbltimestamp = 2284.706953
PTB-ERROR: Some more diagnostic values (only for experts): postflip_vblcount = 171, postflip_vbltimestamp = 2284.720362, vbltimestampquery_retrycount = 0

PTB-ERROR: The most likely cause of this error (based on cross-check with kernel-level timestamping) is:
PTB-ERROR: Something may be broken in your systems beamposition timestamping. Read 'help SyncTrouble' !

PTB-ERROR: For the remainder of this session, i've switched to kernel based timestamping as a backup method.
PTB-ERROR: This method is slightly less accurate and higher overhead but should be similarly robust.
PTB-ERROR: A less likely cause could be that Synchronization of stimulus onset (buffer swap) to the
PTB-ERROR: vertical blank interval VBL is not working properly.
PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing
PTB-ERROR: becomes quite futile.

and every now and again i receive this error:

WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?

----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----

One or more internal checks (see Warnings above) indicate that synchronization
of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.

This will seriously impair proper stimulus presentation and stimulus presentation timing!
Please read 'help SyncTrouble' for information about how to solve or work-around the problem.
You can force Psychtoolbox to continue, despite the severe problems, by adding the command
Screen('Preference', 'SkipSyncTests', 1); at the top of your script, if you really know what you are doing.

??? Error using ==> Screen

Error in ==> stimuli_v15 at 41
[wPtr,screen_pixels]=Screen('OpenWindow',screenNum); % Opens an off screen window
??? WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?
|
Error: Unexpected MATLAB expression.

I presume its some bug in the Mac OSx that seems to only appear when this Kernel is installed. Without the kernal installed I get none of these errors. If everything is working fine without the kernel, i.e. timing seems very good, would it be safe to proceed without the kernel installed?

The iMac is definitely 64bit with R2013a 64 bit installed but i think you're right about the instillation I may have done something wrong. I'll try re-install it tomorrow and see if that fixes the unusual error message.

> > The iMac no longer produces any NaNs during the 5 iterations for the calibration but the crash still occurs during the second attempt to collect data. But I can now see data coming in during the first attempt to collect data, so the new code got rid of my 'Nothing Received' problem as well.
> >
>
> This is your iMac under 10.8 OSX with your hack of not using DaqFind and modifying DaqAInScan.m, right?

Yes that's correct.

thanks for your help,

Alan

mariokleiner · June 14, 2013, 6:25pm

The thread you're referring to is almost a year old without an update, since then there have been many driver updates. Also, one of my two test systems for Linux multi-display is a machine with 64-Bit Ubuntu 12.04 LTS (fully up to date software and os), NVidia Geforce 8800 and NVidia binary drivers. I've tested multi-display operations under Unity, KDE, GNOME-3, XFCE, LXDE and different recent NVidia driver versions only a few months ago, and apart from Unity having sync trouble and timing issues in multi-display mode, i don't remember any trouble or glitches. Also, it apparently works for other people. Therefore i'd assume it is either a bug very recently introduced, or something rather specific to your NVidia graphics card.

I use that system now with KDE by default, because it gives me both good timing and performance and well working dual-display operation, and still has a fancy modern 3d GUI. But XFCE, LXDE, GNOME-3 etc. worked equally well.

One thought i had wrt. your "system hangs during boot": How long did you wait? After installation of a new graphics driver or updates of the operating system kernel, due to security updates or fixes, parts of the NVidia driver need to be recompiled/adapted to the new setup, and that might take a bit of time, like maybe a minute or two on a modern fast machine. Could be that lack of visual feedback could look like a hang to you?

Another thing that makes single display setups quite useable, if you have KDE installed, is the PsychDebugWindowConfiguration command. It allows the see your stimulus display half-transparent, and at the same time your desktop, matlab editor etc., so while this does impair timing, it can make debugging on single display quite painless.

-mario

--- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@...> wrote:
>
> Apologies for the multiple posts on different messages but yes I managed to get Linux working with PTB and all most post were about the same system.
>
> I checked online and it appears to be a problem that currently has no real solution:
>
> http://ubuntuforums.org/showthread.php?t=1972628&page=2
>
> I'm going to install KDE now to give it a go and see if that allows me to access the separate x screens without any issues. I'm installing KDE full.
>
> As a last resort I'll try install Linux Mint Mate as the last post in the link above states that this allowed the NVIDIA driver to work fully with this OS and use of separate X Screens worked.
>
> The absolute coordinates is a setting in nvidia-settings, NVIDIA popped up and advised to to set one screen as absolue and the other screen as 'Left of' the absolute screen. I don't know why but that's what was suggested to do by NVIDIA in nvidia-settings.
>
> If all fails I'll probably resort to using my MacBook Pro since I have that setup working and I do require (would prefer) multiple displays for my experiment.
>
> thanks for your help,
>
> Alan
>
> > Sorry, i can't really help you much atm. I'm pretty sure that none of these hacks is neccessary, and following random rather outdated instructions on the web which try to address *different* problems sounds like you might break more stuff than you fix, but i'm not in the lab at the moment, so i can't look up what my setup (driver versions etc.) for dual-display Ubuntu 12.04 with NVidia is. I don't think i had any frozen cursor issues and once i switched away from Unity to KDE, XFCE or LXDE, stuff worked very well.
> >
> > I'm also somewhat confused about your installation issues reported in two different threads here at the forum? Are you referring to two different Linux setups with different problems, because info seems to be contradictory? Or are both now fixed and only the dual-display problem on one of the setups is left?
> >
> > Also i don't know what you refer to with the "absolute coordinates" you mentioned. I also seem to remember that during installation of Ubuntu it asks you if it should immediately install the proprietary NVidia drivers, but maybe that was for a later release of Ubuntu?
> >
> > Maybe someone with actual access to a working system can give you info about what Ubuntu flavor with which desktop and which NVidia driver version they are using atm?
> >
> > Or you setup your system as single display if dual-display isn't really needed for your experiments to keep going until i make it to the lab during one of the next days and can actually look at my setup.
> >
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > >
> > > Hi,
> > >
> > > I tried to install several different drivers using this step by step guide:
> > >
> > > http://italyherald.wordpress.com/2012/05/08/how-to-fix-ubuntu-12-04-nvidia-gt220-freezes-with-dual-monitor-and-hdmi-audio/
> > >
> > > Only the 304.88 managed to install correctly. Every other driver including the 304.43 and latest 319.17, installed and when I rebooted it got stuck in the boot where it loads each element in Ubuntu with the '[ok]' on the right hand side. Everything is an '[ok]' but it doesn't move from there at all. I;ve reinstalled several times today and I'm going to try reinstalled the nvidia drivers using additional drivers with XFCE again to see if I can get it working.
> > >
> > >
> > >
> > > --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > >
> > > > Hi,
> > > >
> > > > After installing XFCE I checked my screen settings in NVIDIA settings. They were already setup for separate x screens with Xinerama enables so I didn't change anything at first and tried it out. PTB only recognised one screen, Screen(0).
> > > >
> > > > So I adjusted the settings by disabling Xinerama and setting my CRT monitor to absolute coordinates and setting the LCD monitor as 'left of' X screen 0 (CRT). This caused similar errors that I experienced with the newest ubuntu Unity, mouse got stuck on the LCC screen, I could left and right click but had no access to the launcher although sometimes using tab I can access the CRT monitor.
> > > >
> > > > After a few reboots etc immediately after logging in I could use the mouse on the CRT but if I moved it across to the LCD screen it would get stuck there again. Also it changed the default XFCE background to the default Ubuntu Unity background but XFCE is definitely still running as the launcher is XFCE. I tried adjusting the settings again, enabling Xinerama and again I was restored to normal display functioning. Then I disabled it again, made CRT monitor absolute with LCD to the elft of X screen 0 and even adjusted the resolutions of both screens so that they were the same but still I had the same problems.
> > > >
> > > > To write this post I had to use the tab key as my curser is still locked in the LCD screen.
> > > >
> > > > I'm using a GeFroce GT 220, could it be a compatibility issue with the graphics card and ubunto?
> > > >
> > > > thanks,
> > > >
> > > > Alan
> > > >
> > > > --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> > > > >
> > > > >
> > > > >
> > > > > Yep. I think the current default Unity desktop of Ubuntu sadly has some problems with multi-display setups, although i can't remember the specifics at the moment.
> > > > >
> > > > > XFCE desktop is a good option for actual psychophysics testing:
> > > > >
> > > > > sudo apt-get install xfce4
> > > > >
> > > > > and then choose that desktop from the login menu. It's not as fancy as Unity, but also less resource hungry, which is good for an actual psychophysics testing machine. The XUbuntu distribution gives you that desktop environment by default.
> > > > >
> > > > > The KDE desktop also works very well and provides all the fancyness and beauty of a modern desktop. The KUbuntu distribution gives you that desktop by default. I can't remember from the top of my head which package you'd need to install on a existing Ubuntu system to get KDE.
> > > > >
> > > > > In any case you want to setup separate x-screens for the stimulus display(s) and the operator display, as you did. And iirc Xinerama should be off.
> > > > >
> > > > > Oh, and after each PTB update from NeuroDebian you should run the script PsychLinuxConfiguration once.
> > > > >
> > > > > I've just asked Yaroslav to update the NeuroDebian packages to the state of our current beta releases, as those also contain some convenience improvements for users of the DAQ toolbox, and fixes for the Matlab installation.
> > > > >
> > > > > -mario
> > > > >
> > > > > --- In psychtoolbox@yahoogroups.com, Andreas Widmann <widmann@> wrote:
> > > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > > > I have another question regarding linux on a PC. I've installed everything correctly with regards PTb and matlab and I have adjusted the Nvidia settings to create separate X Screens with Xinerama enabled but PTb still only detects my screen as on large horizontal monitor. If I disable xinerama then my second (lcd) screen becomes white while my main CRT monitor seems to work find except if I move my curser across to the LCD screen it gets locked in that screen and I cannot do much except right click and adjust the desktop settings.
> > > > > > Which Linux distribution/version are you using? We had exactly the same problems (white secondary screen, strange mouse behavior with disabled Xinerama on Nvidia card) with Ubuntu 12.04 with Unity desktop. This seems to be a bug in Nautilus affecting Unity and Gnome desktops. Could never solve the problem, but everything worked flawlessly almost out of the box with Xubuntu 12.04 and also Xubuntu 13.04 with Xfce desktop. We are using the binary Nvidia drivers.
> > > > > >
> > > > > > Best,
> > > > > > Andreas
> > > > > >
> > > > > > > Could this be an instillation issue with the driver for the graphics card?
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > Alan
> > > > > > >
> > > > > > > --- In psychtoolbox@yahoogroups.com, "Mario" <mario.kleiner@> wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> So your iMac, running under OSX 10.8 with Matlab R2013a 64-Bit and the latest version of 64-Bit Psychtoolbox ( Is64Bit returns 1 ) can not only calibrate, but also successfully run DaqAInScan for real data collection, after you applied your hacks?
> > > > > > >>
> > > > > > >> That would be the first successfull 64-Bit OSX setup to collect any data with DaqAInScan/Begin/Continue/End. That would be at least a first proof of the possibility to get it working.
> > > > > > >>
> > > > > > >>
> > > > > > >> Wrt. to sync trouble on the MacbookPro. You should use the kernel driver, as everything else is no longer reliable on OSX 10.7 and later. Unless you don't depend on millisecond level or frame accurate visual timing. We used to have an ok fallback until Apple broke it with OSX 10.7, the current fallback only works ok'ish on some systems sometimes, i wouldn't trust.
> > > > > > >>
> > > > > > >> For a classic CRT monitor, any resolution should work, but for digital flat panels and the internal flat panel you must run the display at native panel resolution - the highest supported resolution, without any display rotation applied. Everything else will fail. There are additional complications with Retina MacBookPro's, as described in other posts on the forum. PerceptualVBLSyncTest would be a good start to check if the display behaves as described in "help PerceptualVBLSyncTest".
> > > > > > >>
> > > > > > >> On a dual-display setup, also read "help DisplayOutputMappings"
> > > > > > >>
> > > > > > >> -mario
> > > > > > >>
> > > > > > >> --- In psychtoolbox@yahoogroups.com, "masondar123" <nalaarmstrong@> wrote:
> > > > > > >>>
> > > > > > >>>> 64-Bit Matlab with 64-Bit Psychtoolbox? What is the output of calling the function:
> > > > > > >>>>
> > > > > > >>>> Is64Bit
> > > > > > >>>
> > > > > > >>> Sorry that was a mistake my MacbookPro is 64bit system but I run 32bit Matlab, this was the only one that was available to me when I originally installed it (R2010a). I have the latest version of Psychtoolbox installed as well.
> > > > > > >>>
> > > > > > >>> I upgraded to the new R2013a Matlab (64 bit) and this caused severe problems with DaqFind, it continually changed the ID (like on the iMac) and I couldn't collect any data at all so I resorted to using the older version of Matlab, R2010a, instead.
> > > > > > >>>
> > > > > > >>> On this system everything has been working fine until I installed the PsychtoolboxKernelDriver. This caused problems, specifically synchronization errors such as receiving the large red warning sign at the start of my experiment. I managed to remove most of the sync errors by reducing the resolution of the screen but I still get the following error:
> > > > > > >>>
> > > > > > >>> PTB-ERROR: Screen('Flip'); beamposition timestamping computed an *impossible stimulus onset value* of 2284.524061 secs, which would indicate that
> > > > > > >>> PTB-ERROR: stimulus onset happened *before* it was actually requested! (Earliest theoretically possible 2284.528720 secs).
> > > > > > >>>
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 2284.534550, scanline = 523
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): line_pre_swaprequest = 200, line_post_swaprequest = 208, time_post_swaprequest = 2284.528871
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): preflip_vblcount = 157, preflip_vbltimestamp = 2284.521415
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): postflip_vblcount = 0, postflip_vbltimestamp = -1.000000, vbltimestampquery_retrycount = 0
> > > > > > >>>
> > > > > > >>> PTB-ERROR: I have enabled additional cross checking between beamposition based and kernel-level based timestamping.
> > > > > > >>> PTB-ERROR: This should allow to get a better idea of what's going wrong if successive invocations of Screen('Flip');
> > > > > > >>> PTB-ERROR: fail to deliver proper timestamps as well. It may even fix the problem if the culprit would be a bug in
> > > > > > >>> PTB-ERROR: beamposition based high precision timestamping. We will see...
> > > > > > >>>
> > > > > > >>> PTB-ERROR: An equally likely cause would be that Synchronization of stimulus onset (buffer swap) to the
> > > > > > >>> PTB-ERROR: vertical blank interval VBL is not working properly.
> > > > > > >>> PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing
> > > > > > >>> PTB-ERROR: becomes quite futile. Also read 'help SyncTrouble' !
> > > > > > >>> VBL timestamp deviation: precount=170 , postcount=171, delta = 1, postflip_vbltimestamp = 2284.720362 - beampos_vbltimestamp = 2284.707961 == Delta is = 0.012401
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> PTB-ERROR: Screen('Flip'); beamposition timestamping computed an *impossible stimulus onset value* of 2284.707961 secs, which would indicate that
> > > > > > >>> PTB-ERROR: stimulus onset happened *before* it was actually requested! (Earliest theoretically possible 2284.716812 secs).
> > > > > > >>>
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 2284.720052, scanline = 627
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): line_pre_swaprequest = 447, line_post_swaprequest = 456, time_post_swaprequest = 2284.716965
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): preflip_vblcount = 170, preflip_vbltimestamp = 2284.706953
> > > > > > >>> PTB-ERROR: Some more diagnostic values (only for experts): postflip_vblcount = 171, postflip_vbltimestamp = 2284.720362, vbltimestampquery_retrycount = 0
> > > > > > >>>
> > > > > > >>> PTB-ERROR: The most likely cause of this error (based on cross-check with kernel-level timestamping) is:
> > > > > > >>> PTB-ERROR: Something may be broken in your systems beamposition timestamping. Read 'help SyncTrouble' !
> > > > > > >>>
> > > > > > >>> PTB-ERROR: For the remainder of this session, i've switched to kernel based timestamping as a backup method.
> > > > > > >>> PTB-ERROR: This method is slightly less accurate and higher overhead but should be similarly robust.
> > > > > > >>> PTB-ERROR: A less likely cause could be that Synchronization of stimulus onset (buffer swap) to the
> > > > > > >>> PTB-ERROR: vertical blank interval VBL is not working properly.
> > > > > > >>> PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing
> > > > > > >>> PTB-ERROR: becomes quite futile.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> and every now and again i receive this error:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> ----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----
> > > > > > >>>
> > > > > > >>> One or more internal checks (see Warnings above) indicate that synchronization
> > > > > > >>> of Psychtoolbox to the vertical retrace (VBL) is not working on your setup.
> > > > > > >>>
> > > > > > >>> This will seriously impair proper stimulus presentation and stimulus presentation timing!
> > > > > > >>> Please read 'help SyncTrouble' for information about how to solve or work-around the problem.
> > > > > > >>> You can force Psychtoolbox to continue, despite the severe problems, by adding the command
> > > > > > >>> Screen('Preference', 'SkipSyncTests', 1); at the top of your script, if you really know what you are doing.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> ??? Error using ==> Screen
> > > > > > >>>
> > > > > > >>> Error in ==> stimuli_v15 at 41
> > > > > > >>> [wPtr,screen_pixels]=Screen('OpenWindow',screenNum); % Opens an off screen window
> > > > > > >>> ??? WARNING: Couldn't compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?
> > > > > > >>> |
> > > > > > >>> Error: Unexpected MATLAB expression.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> I presume its some bug in the Mac OSx that seems to only appear when this Kernel is installed. Without the kernal installed I get none of these errors. If everything is working fine without the kernel, i.e. timing seems very good, would it be safe to proceed without the kernel installed?
> > > > > > >>>
> > > > > > >>> The iMac is definitely 64bit with R2013a 64 bit installed but i think you're right about the instillation I may have done something wrong. I'll try re-install it tomorrow and see if that fixes the unusual error message.
> > > > > > >>>
> > > > > > >>>>> The iMac no longer produces any NaNs during the 5 iterations for the calibration but the crash still occurs during the second attempt to collect data. But I can now see data coming in during the first attempt to collect data, so the new code got rid of my 'Nothing Received' problem as well.
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>> This is your iMac under 10.8 OSX with your hack of not using DaqFind and modifying DaqAInScan.m, right?
> > > > > > >>>
> > > > > > >>> Yes that's correct.
> > > > > > >>>
> > > > > > >>> thanks for your help,
> > > > > > >>>
> > > > > > >>> Alan
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ------------------------------------
> > > > > > >
> > > > > > > Post your message to: psychtoolbox@yahoogroups.com
> > > > > > > Please indicate OS9, OSX, or WIN version, and include your full name.
> > > > > > > Denis Pelli, David Brainard, and Allen Ingling.
> > > > > > > http://psychtoolbox.org
> > > > > > > Yahoo! Groups Links
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Topic		Replies	Views
Daq Toolbox and multiprocessing	7	257	September 27, 2016
installation probs	5	833	January 8, 2013
response to 19610	4	331	September 19, 2016
Sampling frequency of analogue input Hardware linux , io	13	763	May 29, 2023
Error i get from Psychtool Box please help Programming Help	26	1427	April 16, 2021

DaqCalibrateAIn causes problem with channels

Related topics