Input Overrange Results In No Data

[astrasel]

When I apply an out-of-range differential input to the X3-10M, our app reports 'input overranged' via the 'OnInputOverrange' event, however it does not get the associated A/D samples. If I adjust the level of the input signal to be in range, A/D samples are received on time without problem.

I believe we are using v1.02 of the X3-10M SDK.

I would rather receive the A/D samples in the out-of-range case also; perhaps instead of the 'OnInputOverrange' event signal. Is there an option I'm missing or something that would allow this?

(I tried just not registering for the OnInputOverrange event, but that didn't work - still no A/D samples.)

[dmclane]

We will run a test to look at this phenomena and have the results by the end of this week.

[gmiller]

This is a software issue. What is happening is the callback function in the application is being called by this error many times. The printing on the screen of this message is overrunning the CPU. If you trap this message once in the callback function you can then turn off this callback until the over range is corrected. The callback function could also stop the data flow by disabling the clock until this is corrected or you can just not enable the message with the check box.

I tested this with the over range condition and it just filled the message box with so many lines my computer could not unfreeze itself. This would have been better by just signaling a light on the application then stopping to over range call back until the input was corrected.

Respectfully Gary

[astrasel]

I revised my original message after you may have first read it - at first I put 'perhaps I just need to not register for this event?', then I put 'not registering for the event did not help' because I tried this after the original post.

Therefore, I believe I tried what you mentioned, even when my app is not registered for the 'OnOverrange' event callback, I don't get A/D samples. It doesn't sound like you tried not registering for the callback (to avoid the assoicated extra callback and eventually receive the A/D samples)?

Just to make it clear, I am not using the sample apps that come with the SDK. We have our own app that is using the SDK libraries and based on the sample apps.

My concern is this: If the input is 100% out of range and we don't get A/D samples, that is somewhat OK. I can understand and deal with this. I'd rather be able to configure the card to not report out of range and still get the samples (as I mentioned - not registering for the event did not make this happen). But what about when it is occasionally out of range? Do I still get the A/D samples? The behavior of when it is 100% out of range makes me wonder.

My guess is that what you are saying is basically correct, that for each sample that is out of range a callback is occuring, but it sounds like the callback (or something) is executing even if I don't register for the associated event. It seems to me that there needs to be a way to disable this test of out of range to avoid the extra associated processing, so that the host will always get the samples and can do their own out of range checking.

I think this is critical, because there are going to be times where we still want to get the data even if it is out of range. Right now, I could be running along smoothly, then have a spurious loud signal for a short time, and my app would stop receiving A/D samples and have fifo overflow or time out, even though it could have processed right through the event if this extra processing had not occurred.

[jhenderson]

Unhooking the software event isn't the same as disabling the alert. Have you tried the latter? When the overrange alert is disabled, the HW will not even generate an over-range message to the host, which should eliminate the symptoms you're experiencing.

Of course, with that alert disabled, you will not receive notification about over-range conditions. But, the firmware merely traps the full scale condition and sends an alert. So, this same behaviour can be coded in your application software if you wish to take action when an over-range is underway.

[astrasel]

That was the answer I needed:

m_board.Alerts().AlertEnable(IUsesX3Alerts::alertInputOverrange, false);

solved the problem. Not only was the answer in the manual, the source code header file but also in my code! I was enabling this alert when I cut and pasted the code from the sample app. If I disable it (with the above) I get my data.

I did exactly what I hate my users to do - ask directly for an answer instead of reading the manual! Sorry for the wild goose chase.