From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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
Trigger problem with PXI-6052e when reading an SCXI-1520
Chad_M._Carr
Member
06-27-2005 06:31 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Found a 'feature' that, despite a few days of exploring, I have yet to resolve. The software involved is LV 7.1, using traditional NIDAQ. The hardware setup is as follows:
In a PXI 1010 chassis, I have a 6608 counter in slot 2, with its high stability oscillator driving the RTSI clock. Slot 8 contains the 6052E, and the board clock signal is sourced by the RTSI clock. The signal conditioning portion of the rack has two SCXI-1102B's and one 1520.
I am routing IRIG DCLS to the 6608, and having given up on the NI driver for synchronizing to IRIG, wrote my own. As part of that, I have GPCTR0_OUT configured to provide a 10ms pulse to trigger the start of acquisition at the beginning of an IRIG second. During development, I externally wired the 6608 GPCTR0_OUT (Pin 5) to TRIG1 (pin 11) on the 6052E, and the system triggers flawlessly.
But when I route the signal internally (route GPCTR0_OUT onto RTSI 1, set AI Start to "trigger A" and source of RTSI 1, rising edge), the system still triggers, but *only* when I am scanning the 1102 card, and not trying to scan the 1520 card!
The vi I am scanning with is AI SingleScan (binary array).vi, and I am not buffering any data. The particular error is -10800, "The operation could not complete within the time limit."
I have verified (with an o-scope, by routing RTSI 1 to GPCTR0_OUT on the 6052e)) that the trigger pulse makes it to the 6052 card in all four cases (internal and external routing, 1102 and 1520 signal conditioning).
I also routed the startscan signal to GPCTR0_OUT on the 6052 and watched it with the scope, and in all but the error case I get the expected pulse every scan. For the internally clocked case with the 1520, there are *no* startscan pulses, so it never even succeeds in a single read.
To paraphrase the problem:
Scanning an SCXI-1102b voltage card with a PXI-6052e card triggered by a pulse from a 6608 counter output works whether I route the signal externally via the I/O connectors, or internally via RTSI.
Scanning an SCXI-1520 bridge card with the same PXI-6052e, triggered with the same 6608, works *only* when the trigger is routed externally. Routing the trigger internally generates an error.
If any of you fine folks can explain how an SCXI module can tell (or care) how it's parent DAQ card is triggered, I would be most appreciative.
Chad
In a PXI 1010 chassis, I have a 6608 counter in slot 2, with its high stability oscillator driving the RTSI clock. Slot 8 contains the 6052E, and the board clock signal is sourced by the RTSI clock. The signal conditioning portion of the rack has two SCXI-1102B's and one 1520.
I am routing IRIG DCLS to the 6608, and having given up on the NI driver for synchronizing to IRIG, wrote my own. As part of that, I have GPCTR0_OUT configured to provide a 10ms pulse to trigger the start of acquisition at the beginning of an IRIG second. During development, I externally wired the 6608 GPCTR0_OUT (Pin 5) to TRIG1 (pin 11) on the 6052E, and the system triggers flawlessly.
But when I route the signal internally (route GPCTR0_OUT onto RTSI 1, set AI Start to "trigger A" and source of RTSI 1, rising edge), the system still triggers, but *only* when I am scanning the 1102 card, and not trying to scan the 1520 card!
The vi I am scanning with is AI SingleScan (binary array).vi, and I am not buffering any data. The particular error is -10800, "The operation could not complete within the time limit."
I have verified (with an o-scope, by routing RTSI 1 to GPCTR0_OUT on the 6052e)) that the trigger pulse makes it to the 6052 card in all four cases (internal and external routing, 1102 and 1520 signal conditioning).
I also routed the startscan signal to GPCTR0_OUT on the 6052 and watched it with the scope, and in all but the error case I get the expected pulse every scan. For the internally clocked case with the 1520, there are *no* startscan pulses, so it never even succeeds in a single read.
To paraphrase the problem:
Scanning an SCXI-1102b voltage card with a PXI-6052e card triggered by a pulse from a 6608 counter output works whether I route the signal externally via the I/O connectors, or internally via RTSI.
Scanning an SCXI-1520 bridge card with the same PXI-6052e, triggered with the same 6608, works *only* when the trigger is routed externally. Routing the trigger internally generates an error.
If any of you fine folks can explain how an SCXI module can tell (or care) how it's parent DAQ card is triggered, I would be most appreciative.
Chad
Marni
NI Employee (retired)
06-29-2005 11:00 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello Chad,
I don't know why a SCXI-1520 would prevent triggering from the RTSI bus and a SCXI-1102 wouldn't. Do you have this problem in DAQmx as well? Have a great day!
Sincerely,
Marni S.
I don't know why a SCXI-1520 would prevent triggering from the RTSI bus and a SCXI-1102 wouldn't. Do you have this problem in DAQmx as well? Have a great day!
Sincerely,
Marni S.
