Problem with detecting changes using PCI-6527 with NI-DAQmx

[kovalenkov]

Hi!

I am using Visual Studio .NET 2003 framework and C++ compiler. I am also using Managed extensions for implementation of DAQmx in C++. The problem is as follows:
In files ripped in attached .zip file, are crutial cpp and header files for my test project.
I am using change detection. It works OK first time around, but after that it just top responding on input changes. If somebody ha sgot any idea, please let me know.

Previous topic was located at the link below. It includes more thorough reading.
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000010C40000&UCATEGORY_0=_48_%24_7_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=kovalenkov&USEARCHCONTEXT_QUESTION_
S=0

[David Mc]

Hello kovalenkov,

I wanted to take a look at your code, but the file DiomxHandler.cpp in your zipfile appears to be corrupted... Also, if you're trying to send a C++ .NET class based on CDialog, you will need to package all the resource files for this dialog in order for me to be able to load it.

David McClelland
NI Applications Engineering

[kovalenkov]

Hi. Sorry about that. Anyway, I packed all cpp + h files in new zip file. I also included whole res folder. I didn't include NationalInstruments.DAQmx.dll file, since it is about 750KB large.

[TonyH]

Sorry I slipped on your original thread. I've been on vacation for a couple of weeks.

I noticed that you are opening multiple message boxes in your OnDataReady function. What is the last one that you actually see?

OnDataReady will be called in another thread and you are not catching exceptions in OnDataReady, so it is possible that EndRead is throwing an exception that describes a hardware or acquisition problem that is preventing your task from running. Because the exception occurs in a non-MFC thread, it will not automatically be reported to you. In that case, OnDataReady would be called only once in order to notify your program of the problem and then your task would stop. Put the EndRead call in a try-catch block, catch DaqException
, and look at the Message on the DaqException for more information.

Hopefully this will shed some light on your problem. Let me know how it turns out.

Tony H.
Measurement Studio

[kovalenkov]

Hi!
I get the one Saying: "Yes Yes". Then it seems like EndReadSingleSampleMultiLine doesn't work properly in my program. I tried to catch exeptions, but none were occuring. I thought it was odd, but still.
Anyhow there seems to be another problem. Every once in a while, onDataReady gets called without any signal put in. It just runs itself every couple of seconds.
The test board works OK, since it workes with Traditional NI-DAQ without any problems or strange coincidences.

[kovalenkov]

Anybody found out what seems to be wrong?

[Tiptop]

Hey Kovalenkov,

One thing that we can take a look at is that everything is working within specifications of the 6527 board. Due to some hardware limitations, there is a limit to what the board can detect. As a test, could you wire in a clock signal less then 300 Hz on whichever line you are monitoring and see if maybe this will fix the problem. It is possible that you are supplying a signal that is too fast for the software to take care of.

This is just a guess, but I think it is worth a try. Let us know if this works.

Best regards,

Justin T.
National Instruments

[TonyH]

I still think you are getting an exception that is causing your task to stop. Could you please post the code for how you were catching the exception so that I can verify that it catches the managed exceptions coming from our DAQmx .NET API?

Thanks,
Tony H.
Measurement Studio

[kovalenkov]

I just used simple try catch sentance:
'try
{
dataArray = reader->EndReadSingleSampleMultiLine (result);
}
catch (DaqException *exep)
{
AfxMessageBox ("Exception");
}'

And it never even mentioned an exeption in the first place.

[TonyH]

Ok, I got a chance to sit down and inspect your code. You are getting an exception, but it is not a DaqException. The code as written will cause an access violation. In ThunkClass::Thunk, you have

CDiomxHandler* pThis = (CDiomxHandler*)AfxGetMainWnd ();
pThis->OnDataReady (ar);

CDiomxHandler is not a CWnd-derived class and is not your main window. The c-style cast succeeds as a dangerous reinterpret_cast (you should have gotten a warning C4669) and executes OnDataReady with an invalid this pointer. You see the first dialog box in OnDataReady because you have not yet attempted to access any members on the invalid this pointer. When you attempt to get the reader pointer to call EndReadS
ingleSampleMultiLine, you get an access violation.

If you rewrite the code to pass the pointer to your CDiomxHandler as the "AsyncState" when you begin your asynchronous read, you can retrieve it from the IAsyncResult and get your CDiomxHandler pointer. (AsyncState exists for precisely this purpose). I've attached a simplified version of your program that does this. This example uses a small amount of advanced .NET interop code to package the CDaqHandler pointer into a managed Object* and unpackage it in the thunk. This is just one way to do it, there certainly are other ways.

Good luck!

Tony H
Measurement Studio