Sharing Timebase for 4 Boards

[digitalIO]

Hello, I am using 4 NI PCI cards connected with a RTSI bus:6013 -- dev16713 x 2  -- dev3 & dev46534 -- 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

[digitalIO]

Anyone? Here are some more details that might be helpful:NI 6534 Digital I/O is running at frequencies from 86k-340kHzAnalog output 6713 x 2 is running at 600-2400 HzAnalog 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

[tnek]

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. <a href="http://digital.ni.com/public.nsf/allkb/F2B1273160F9C9E7862572820058537F?OpenDocument" target="_blank">Here</a> is a example which shows how to share the timebase from the NI-6534. Another good resource for multi device synchronization can be found <a href="http://zone.ni.com/devzone/cda/tut/p/id/4322" target="_blank">here</a>. 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,KentApplications Engineer

[digitalIO]

Thanks for the reply, Kent. I was having problems with signal routing.&nbsp; I was getting the "Hardware does not support the route..." error.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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)?&nbsp; 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.&nbsp; I'm going to look into it more this morning.Thanks again for the help. Kevin

[digitalIO]

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).&nbsp; In order to get it to dev5, I exported the signal to RTSI1 and then to dev5/PFI3.&nbsp; 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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sourcedev3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dev1\20MHzTimebasedev4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dev1\20MHzTimebasedev5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dev5\PFI3When I wired the tasks in this way, I did not get any run-time errors.&nbsp; 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

[tnek]

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. <a href="http://digital.ni.com/public.nsf/allkb/F2B1273160F9C9E7862572820058537F?OpenDocument" target="_blank">This</a> article which I posted earlier shows the property node which you can use to accomplish this. Regards,KentApplications Engineer

[digitalIO]

Excellent. I'll give this a try. Any chance you could post a version of your example code in LabVIEW 7.1?&nbsp; I can't open the one on your post becuase it's 8.2... Thanks again for your help.Kevin

[digitalIO]

Kent, Here's the latest:&nbsp; I have set the source for the Master Timebase to "/Dev1/20MHzTimebase" using the property node DAQmx Timing&gt;&gt;More&gt;&gt;Master Timebase&gt;&gt;Source.&nbsp; I did this for all the tasks on devices 3, 4, and 5.&nbsp; 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.&nbsp; Here's what I have been using:Let's say I have a 2 second test.&nbsp; 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.&nbsp; 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.&nbsp; Is this expected? Also, I have an external volt box (set to 5v) that I switch on and off during the 2 second test.&nbsp; 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.&nbsp; 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.&nbsp; 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

[digitalIO]

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.&nbsp; I would only assume that it would continue to increase with a longer test.

[digitalIO]

Latest devlopments:I have tried using the 20MHzTimebase from the 6534 as the timebase for the other 3 boards (6713E, 6013 x2).&nbsp; 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

[tnek]

Hi Kevin, I just want to make sure that your start trigger is still being shared. Even though you are sharing the timebase, they will not all start at the same time especially since you are acquiring at different rates. Your test seems legitimate and if everything worked correctly, the signals should line up in time. If this still does not work, could you post a barebones version of your code which shows the necessary functions for the synchronization? Let me know how things go.Regards,KentApplications Engineer

[digitalIO]

Thanks again for the help. I am still sharing the start trigger.&nbsp; I have set up all the tasks except the Analog Input task to use a digital start trigger with "/dev1/AIStartTrigger" as the source.&nbsp; Then I start all the tasks in order with the AI task last.&nbsp; I think the trigger is working. I inserted a wait period between starting the triggered tasks and the AI task just to make sure that the other tasks were in fact waiting for the trigger to start.&nbsp; It seemed to be working as expected. I'll work on getting my code into a bare bones version so I can post it. Shouldn't take too long. Thanks,Kevin

[digitalIO]

Ok, so I managed to piece together the relavant functions of my code.&nbsp; The front panel is not well organized at all, but the block diagram should make some sense.&nbsp; Let me know if you don't understand anything. Kevin


AnalogIOSetupv2.vi:
http://forums.ni.com/attachments/ni/70/8757/1/AnalogIOSetupv2.vi


CardControlBare.vi:
http://forums.ni.com/attachments/ni/70/8757/2/CardControlBare.vi


DigitalIOSetupv4.vi:
http://forums.ni.com/attachments/ni/70/8757/3/DigitalIOSetupv4.vi

[tnek]

Hi Kevin,I took a look at your code and it seems fine. I could not run it since I don't have the same devices and the same configuration. Just out of curiosity, how are you measuring this time delay from the digital input to the analog input? Are you looking at the sample number and correlating that to a time or are you looking at a timestamp? The other thing I noticed was the large difference in sampling rate between the analog input and digital input. What happens when they are both set to the same sampling rate? Regards,KentApplications Engineer

[digitalIO]

Kent, Thanks for looking at my code.&nbsp; The way I'm looking at the time delay is by knowing the sampling time and assigning a time to each sample. I am doing in a post-processing block later in my code.&nbsp; I was playing around with this in Matlab and I think I may have found my problem.&nbsp; I am not using the actual sampling frequency from the card (obtained using a property node).&nbsp; It might be that the actual sampling frequency for the digital acquisition is slightly different than what was specified.&nbsp; If that were the case, I would see a small but increasing difference in the time-difference between the analog data (I use the actual acquisition frequency for the analog post-processing).&nbsp; I'm going to try this tomorrow and see what kind of results I get. I've got my fingers crossed! Thanks again,Kevin

[digitalIO]

At last -- I think I've found the root of the problem. After looking at the actual sample clock rate (vs. the specified sample clock rate), I found that there was a slight difference.&nbsp; I was specifying 345600 and only getting 344828.&nbsp; I'm not exactly sure why this was happening, but it is a big enough difference to matter when looking at sample times and such.&nbsp; After using the actual sample time, I was able to observe perfect synchronization between cards using the volt box switching to 5V. I call this the external test because the volt box is external to the system. However, the "internal" test, where I command the analog output to 5V, still shows some (smaller) synchronization errors, i.e. the digital line switches to HIGH about 50 microseconds before the analog input shows any change from 0V. I'm looking into this and I think I'll be able to find the problem, but I just wanted to let you know.&nbsp; I am noticing that the specified analog output rate is 2400 Hz but the actual rate on the card ends up being 2400.096 Hz. I have to think about it more, but this might be causing the "internal" test synchronization problems. Thanks again for your help. I appreciate it! Kevin

[tnek]

Hi Kevin, You're correct in using the actual sampling rate. This can be a bit confusing but the necessary since the sample clock is divided down from a master timebase on the card. The number to divide by needs to be an integer. <a href="http://digital.ni.com/public.nsf/allkb/5782F1B396474BAF86256A1D00572D6E?OpenDocument" target="_blank">Here</a> is an article with more information and a few examples showing how the actual sample rate is calculated. Regards,KentApplications Engineer