Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
DSA 4472: Data Clipping above 1 volt input
fdasdfsadf
Member
06-18-2003 03:07 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Recently received DSA 4472 boards.
Require to read continuously at
1024 s/sec.
Several problems:
Using signal generator to input sinewaves.
1. Below 1 volt input amplitude
Sinewave is slightly distorted.
Looks like buffer problem. Using
double buffering with Scan_***.
See similar effect in Test Panel.
2 Above approx 1 volt input signal is clipped. Same in test panel. Expected +/- 10V input range.
3. Any programming errors e.g wrong buffer size or ending program before clearing device causes computer to Power OFF !!
Please find attached the code I'm using. It has been rearranged to give a synopsis.
Require to read continuously at
1024 s/sec.
Several problems:
Using signal generator to input sinewaves.
1. Below 1 volt input amplitude
Sinewave is slightly distorted.
Looks like buffer problem. Using
double buffering with Scan_***.
See similar effect in Test Panel.
2 Above approx 1 volt input signal is clipped. Same in test panel. Expected +/- 10V input range.
3. Any programming errors e.g wrong buffer size or ending program before clearing device causes computer to Power OFF !!
Please find attached the code I'm using. It has been rearranged to give a synopsis.
Bryan F
Member
06-19-2003 11:20 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello --
In response to questions #1 and #2 (fidelity of the signal acquisition), this is almost certainly a hardware problem. One possibility could be a ground loop on the negative side of your 4472 input channel. The signal connected to the negastive (i.e. cable shield) side of each input channel should not differ from chassis ground by more than +/- 2.5 V. If your function generator is a floating source, this should not be a problem, but it can easily become an issue if you are using a grounded/referenced source. If you are not sure about the grounding configuration of your source, I would recommend trying a 9 V battery (certainly floating). If you cannot read this voltage correctly, I'd suggest sending the board in for repair.
As for the second issu
e (spontaneous reboots), my recommendation is to include a feature in your code that will allow the user to stop an acquisition in progress and clear the acquisition properly. An acquisition requires resources from both user and kernel memory spaces. If you stop an acquisition in progress (such as forcing an exit from the debugger) without making a call to DAQ_Clear to stop it, you sever the user connection but the DMA and kernel portions continue on their own. If this happens, the aquisition may continue overwriting kernel memory indefinitely, eventually corrupting something important in the application or the OS, resulting in an ungraceful reboot. Unfortunately this isn't a very nice behavior, but the real solution is to try to build the capability for a clean exit into your application as quickly as possible.
Hope this helps!
In response to questions #1 and #2 (fidelity of the signal acquisition), this is almost certainly a hardware problem. One possibility could be a ground loop on the negative side of your 4472 input channel. The signal connected to the negastive (i.e. cable shield) side of each input channel should not differ from chassis ground by more than +/- 2.5 V. If your function generator is a floating source, this should not be a problem, but it can easily become an issue if you are using a grounded/referenced source. If you are not sure about the grounding configuration of your source, I would recommend trying a 9 V battery (certainly floating). If you cannot read this voltage correctly, I'd suggest sending the board in for repair.
As for the second issu
e (spontaneous reboots), my recommendation is to include a feature in your code that will allow the user to stop an acquisition in progress and clear the acquisition properly. An acquisition requires resources from both user and kernel memory spaces. If you stop an acquisition in progress (such as forcing an exit from the debugger) without making a call to DAQ_Clear to stop it, you sever the user connection but the DMA and kernel portions continue on their own. If this happens, the aquisition may continue overwriting kernel memory indefinitely, eventually corrupting something important in the application or the OS, resulting in an ungraceful reboot. Unfortunately this isn't a very nice behavior, but the real solution is to try to build the capability for a clean exit into your application as quickly as possible.
Hope this helps!
06-20-2003 09:05 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Bryan,
thanks for your response. You are correct about #1 and #2. It seems I have a hardware problem
with two of my PCI slots. Moving the board to a third
slot solved all problems (except the rebooot issue).
On this issue I will take your advice. Fortuneately
this behavious does not seem to be exhibited in the release version, if for instance someone ends the program from task manager while acquiring data.
Mike
thanks for your response. You are correct about #1 and #2. It seems I have a hardware problem
with two of my PCI slots. Moving the board to a third
slot solved all problems (except the rebooot issue).
On this issue I will take your advice. Fortuneately
this behavious does not seem to be exhibited in the release version, if for instance someone ends the program from task manager while acquiring data.
Mike
