07-08-2009 02:52 PM
I am using a NI-6552 card (actually this system will eventually use 7, so I'm trying to get my head wrapped around triggering events).
I am using Dynamic Generation to generate a binary pattern on pins 0-15.
I am routing the start trigger to RTSI6.
I am using a software trigger.
On the reading side, I'm using Dynamic Acquisition. The start trigger is triggered off of RTSI6.
Everything works exactly like it's supposed to. I'm getting the binary pattern back, BUT
The read function is advanced EXACTLY 50 clock cycles. So I get a "0" reading from the channel lines for 50 cycles before the binary pattern appears in my read waveform.
I suspected that this has something to do with the reference trigger, so I tried to set the reference trigger source to RTSI6 also, with a 0 sample delay, and I get a timeout.
I'm so close, but I'd like to figure out why I'm getting a 50 cycle preread buffer even though I haven't specified one...
-Mike
Solved! Go to Solution.
07-09-2009 08:42 AM
Mike,
Re-exporting a trigger is an asynchronous occurance. Exporting the start trigger as an event to RTSI will not necessarily occcur on the first sample of the waveform. Instead, there is a "Data Active" event that is a level based event that is active when the data is valid. Basically you end up with an edge at the first sample of your waveform. If the generation pauses or stops, the event deasserts.
Additionally, there is round trip delay between the signal being exported, routing to RTSI, bouncing back and being received by the acquisition start trigger. The RTD should be deterministic which is way you see the same number of samples off each time.
The data active will give you a synchronous event, but you'll still have a round trip delay issue to contend with. Are you trying to sample the channels on which you are generating? If so, you may have better results routing the data active to PFI since they have a data path that is more consistent with the data.
07-14-2009 02:53 PM
OK, I got a breakout box for the 68 pin output cable so I could actually watch the output from the DIO card. I am still mystified why there is a 50 sample delay when I tell the card to output my waveform. The waveform I'm generating is a simple square wave (bit 0 of a binary count). I have attached two images that show the "problem". The yellow waveform is the start trigger exported on PFI1, and the blue is the waveform. The first image is the waveform run at 20 KHz, and the second is the same waveform run at 2Mhz. Obviously it's not an electronic delay, it's something I'm doing wrong, but I'll be dipped if I can figure out what.
07-15-2009 08:56 AM
yellow is the start trigger for the generation?
A start trigger for generation is an asynchronous occurance. It takes some analog time and a number of clock cycles to get sampled into the firmware, consumed by the state machines, and trigger the data stream. We actually specify that time as "Delay from trigger to digital data output" on page 20 of the specs. For the 655x its 32 sample clock cycles + 160ns.
07-15-2009 09:49 AM
OK, I understand. I exported the data ready event on PFI2, and connected that to PFI3, which I then use as the start trigger for my dynamic read. That cause the data to line up on a single card.
My next question is regarding using two cards. I have both cards connected using an RTSI cable. I'm exporting the software trigger on RTSI6, and using that on the other card to trigger the dynamic generation event. I also export the clock on RTSI7, and use that on the slave card as the reference clock.
Now when I generate the software start signal, both cards spit out the waveform, but unfortunately they're not synchronized. This is what I'm seeing.
Yellow is data ready on card 1, blue is the data on card 1, green is the data on card 2. Running this test repeatedly causes the waveform to line up differently, obviously that's not going to work for running these two cards on the same device.
I'm going to try to find as much information on synchronizing these cards as I can, but if someone can point me in the right direction in the meantime, I'd sure appreciate it.
07-15-2009
12:30 PM
- last edited on
05-28-2024
10:00 AM
by
Content Cleaner
CCITest,
If you are looking to synchronize multiple 6552 boards, you will want to use TCLK. NI TCLK is the synchronization scheme built into all National Instruments Synchronization and Memory Core (SMC) based products. More information can be found on the details behind this techonology inside the HSDIO help document (Start >> Programs >> National Instruments >> NI-HSDIO >> Documentation >> NI Digital Waveform Generator-Analyzer Help). Inside this help document a good starting place is under Programming >> References >> NI-TClk Synchronization Help >> NI-TClk Overview.
NI-TClk will allow you to start multiple boards at the same time. From your post I am not sure if you are using a PCI-6552 or a PXI-6552, however when using a PCI version the RTSI cable allows up to 5 boards to be connected. Using PXI, you can fill the chassis and synchronize your 7 boards. There are several examples that show how to use NI-TClk. These examples can be found under Start >> Programs >> National Instruments >> NI-HSDIO >> Example. Next pick your preferred lanugage and select either synchronization.llb or the synchronization folder.
07-16-2009 10:43 AM
Jesse,
I am using a PCI chassis, the cards are connected via an RTSI cable, and the cable is defined in MAX, with the devices connected listed.
I am using VB.NET to get at the calls for nihsdio.dll and nstclk.dll. That part all seems to be workiing. When I use TClk to call synchronize, I'm getting this error:
+++++++++++++++++++++++++
NI-TClk invoked a call on a session, and the instrument driver reported an error.
Session index (starts at zero): 1
Error reported by the instrument driver:
The session didn't receive a sync pulse it was expecting.
Make sure signals are properly connected. If appropriate, use NI-TClk attributes Sync Pulse Output Terminal and Sync Pulse Source to specify the routing.
Status Code: -219001
Status Code: -25004
+++++++++++++++++++++++++
Here is an outline of the TClk code:
With SyncTClock
.ConfigureForHomogeneousTriggers(2, viSessions)
.Synchronize(2, viSessions, 0.025)
.Initiate(2, viSessions)
.WaitUntilDone(2, viSessions, 2.0)
End With
It fails on the synchronize call.
-Mike
07-16-2009
06:36 PM
- last edited on
05-28-2024
10:01 AM
by
Content Cleaner
Hi Mike,
This error has come up in another forum located here. You might check all of your signal connections and rtsi connections to make sure they are all properly connected. This might be from a poor connection or degraded signal.
07-17-2009 09:45 AM
Jim,
Thank you! That was enough of a hint that I got it. I had constructed an RTSI cable with 7 connectors on it for the eventual 7 cards that are going to be in this system. That was causing that error, as soon as I constructed an inch-long cable with just two connectors it fired right off, and works good! The pulse trains coming out of the two cards are synched now. I did end up having to write a wrapper for the nitclk.dll to get it to work, since the TClk .NET class uses incompatible parameters (and it isn't documented that I can find) for passing sessions into the TClk engine.
That just leaves the RTSI cable issue. I am going to have to find a solution for that. I'm going to start a separate post and hopefully find out if it's really limited to 5 and why, or if I just constructed this cable poorly.
-Mike
03-29-2013 11:55 PM
Hello Mike,
I am using a PXI 6562 card and trying to do a loopback in test labview. As you mentioned you were generating a pattern and try to acquire those pattern even I am trying to do the same but I am not getting the acquired pattern. For looping back from one channel to another channel I am using SMA male to SMA male 50ohm impedance cable. As my break out box for the card is 2164 which has SMA connectors.
Can you suggest what could be going wrong? I am able to see the pattern generated on the CRO & it looks fine but I am not getting the acquired pattern in LabVIEW. The pattern generated has voltage peak to peak of 800 mV approx. Can you throw some light on it.
Thanks & Regards
Rohit