Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Sharing Timebase for 4 Boards

Hello,

I am using 4 NI PCI cards connected with a RTSI bus:
6013 -- dev1
6713 x 2  -- dev3 & dev4
6534 -- dev5
 
I'm programming using DAQmx and LabVIEW 7.1.

I need them to be synchronized for my application.  I have them all using the same (digital) start trigger (dev1/startTrigger), but I think there is some drift due to clock differences between the different boards.  I have attemped using one of the cards' 20MHzTimebase as the source for all the others, but I get errors.  I have also tried exporting to the RTSI bus without success.  Are there attributes of these cards that I'm not aware of that will prevent me from sharing the timebase?  Does anyone know how to do it?

I appreciate the help.  Let me know if more information is needed about my setup.

Thanks!

Kevin
0 Kudos
Message 1 of 17
(3,367 Views)
Anyone?

Here are some more details that might be helpful:

NI 6534 Digital I/O is running at frequencies from 86k-340kHz
Analog output 6713 x 2 is running at 600-2400 Hz
Analog input 6013 is running at 1k-5kHz.


I simply need them all to start at the same time and all to stay synchronized for the duration of the test (anywhere from 5s to 30s).


Any ideas?
Kevin
0 Kudos
Message 2 of 17
(3,334 Views)
Hi Kevin,

I was wondering where you are encountering trouble with this process. You should be able to have your 4 tasks running at different rates. They can be synchronized by sharing one of the timebases with the other cards and then sharing a start trigger. There are good examples which show how to synchronize the different devices in the Example Finder. The Example Finder can be accessed through the Help menu. These DAQmx examples can be found browsing by task under Hardware Input and Output » DAQmx » Synchronization » Multi-Device. Here is a example which shows how to share the timebase from the NI-6534. Another good resource for multi device
synchronization can be found here. It seems like you have the right idea. Use these examples as a starting point. Let me know if you run into any specific problems.

Regards,
Kent
Applications Engineer
0 Kudos
Message 3 of 17
(3,321 Views)
Thanks for the reply, Kent.

I was having problems with signal routing.  I was getting the "Hardware does not support the route..." error.  I didn't know if I needed to follow certain rules as to which device would be the master and which would be the slaves.  Also, I didn't know if I had to route the signal to certain PFI lines or RTSI lines in order to use it as the time base for each board.

For example, I routed the 20MHzTimeBase from dev1 to RTSI0.  I then routed dev5/RTSI0 to dev5/PFI3 and set PFI3 as the source for the sample clock for the digital input and output tasks.  Is the order in which I run the signal routing blocks and task setup important, i.e. do I have to make sure the dev1 task is created before I setup dev5 to have a sample clock based on dev5/PFI3 (which is routed from dev1/RTSI0)?  That's probably a confusing question, and I think I know the anwser, I was just curious.

I managed to get the signal routing errors to go away, but I'm not sure my boards are functioning correctly even though I'm not getting any run-time errors. The boards did not behave like they were supposed to.  I'm going to look into it more this morning.

Thanks again for the help.

Kevin
0 Kudos
Message 4 of 17
(3,306 Views)
Ok, so I've done some more testing today and here's what I'm getting:

I tried using dev1/20MHzTimebase as the source for the other cards (dev3, dev4, and dev5).  In order to get it to dev5, I exported the signal to RTSI1 and then to dev5/PFI3.  For each of the tasks, I setup the clock using the "DAQmx Timing (Sample Clock)" block with the terminal for source wired as follows:
Card          Source
dev3           dev1\20MHzTimebase
dev4           dev1\20MHzTimebase
dev5           dev5\PFI3

When I wired the tasks in this way, I did not get any run-time errors.  However, the cards did not perform their functions. That is, the analog output card (dev3) did not output the waveform that it was supposed to write. The output was 0V for the duration of the test. Also, the digital input and output were constant 0V throughout the entire test.

I reverted back to each card using its onboard clock, and everything worked as it used to (with previously observed small amounts of clock drift).

Any ideas as to why this would happen? Need more info?

Kevin
0 Kudos
Message 5 of 17
(3,292 Views)
Hi Kevin,

I would think there should be an error when you use the 20MHz timebase as the source in the DAQmx Timing VI and specify a different rate. Regardless, try setting the master timebase rather than the sample clock. This will allow each card to derive their own sample clock from the same timebase. This article which I posted earlier shows the property node which you can use to accomplish this.

Regards,
Kent
Applications Engineer
0 Kudos
Message 6 of 17
(3,279 Views)
Excellent. I'll give this a try. Any chance you could post a version of your example code in LabVIEW 7.1?  I can't open the one on your post becuase it's 8.2...

Thanks again for your help.
Kevin
0 Kudos
Message 7 of 17
(3,274 Views)
Kent,

Here's the latest:  I have set the source for the Master Timebase to "/Dev1/20MHzTimebase" using the property node DAQmx Timing>>More>>Master Timebase>>Source.  I did this for all the tasks on devices 3, 4, and 5.  I then left the "Source" pin unwired for all the "DAQmx Timing (Sample Clock)" blocks and specified the different rates for the different tasks.

With this configuration, everything runs with no errors. I think I'm definitely on the right track.

However, I'm trying to determine if there's a way I can be certain of the synchronization.  Here's what I have been using:

Let's say I have a 2 second test.  I command the Analog Output task to 5V from 1s to 1.4s, 0V otherwise. I have this output connected to both the analog input and digital input.  I should see the analog input and digital input change at the same intstant in time, right? I'm seeing the digital input change states from 0 to 1 before the analog input reports any change.  Is this expected?

Also, I have an external volt box (set to 5v) that I switch on and off during the 2 second test.  This signal is connected to both the analog and digital inputs. When looking at the data from these channels, I see the same behavior with the digital line changing state before the analog line begins to move from 0V.  The difference is anywhere from 1ms to 2.5 ms. It seems as though the amount of time difference between the analog and digital increases over the course of test.  I understood this to be clock drift from the two boards, but now that should be eliminated, right?

I'm sure this is confusing. Please let me know your thoughts, especially if there is a better way to establish confidence in the synchronization.

Many thanks,
Kevin
0 Kudos
Message 8 of 17
(3,263 Views)
I'll put some numbers on the timing differences.

Over the course of the 2 second test, the amount of time that the digital input appears to be "ahead" of the analog input increases from 0.7 ms to 4.2 ms.  I would only assume that it would continue to increase with a longer test.
0 Kudos
Message 9 of 17
(3,258 Views)
Latest devlopments:

I have tried using the 20MHzTimebase from the 6534 as the timebase for the other 3 boards (6713E, 6013 x2).  This yielded the same results. I didn't really think this would change anything, but I gave it a shot.

At this point I'm wondering whether my test method is flawed or I'm assuming something that shouldn't be assumd -- whenever things are working after much thought, I usually have to check my assumptions...

I guess the thing that bothers me is that the time difference between the boards seems to be changing over time.

Any ideas?



Message Edited by digitalIO on 04-25-2008 01:24 PM
0 Kudos
Message 10 of 17
(3,248 Views)