Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

PXI-6682 + multiple Serie S & M cards cause timestamp delay

I'll try to give as much info as possible and hopefuly someone will have an answer to this problem.

 

Language: C++

Introduction:

1- I have (1) PXI-6682 (Timing card), (6) PXI-6143 (Serie S (8 analog inputs each)), and (2) PXI-6224 (serie M (8 analog inputs each))

2- Every card is a task (so that's 8 tasks

3- Every card is in sync (they give data equal...more or less... to one another

 

PROBLEM:

1- Timestamp is off by up to 200 ms (not drifting...simply off by a set number of ms)

2- Every call to niSync_ReadMultipleTriggerTimeStamp gives me a timestamp off by that much

 

I don't have any info on how the tester managed to know it was 200 ms off, my theory is he tested it with some older equipment to validate the new one

0 Kudos
Message 1 of 18
(5,964 Views)

Hi Sebastien,

Are all these cards in the PXI chassis? You mentioned “every card is in Sync”, does that mean you are sharing a hardware start trigger and sample clock for each card? What timestamp(s) are off by 200 ms?  Does each task have a timestamp and they are all different by up to 200 ms from each other? What signal are you time stamping?

Matt
Applications Engineer
National Instruments
0 Kudos
Message 2 of 18
(5,946 Views)
  1. Are all these cards in the PXI chassis?
    1. Yes they are in a 14 slot pxi 1044
  2. You mentioned “every card is in Sync”, does that mean you are sharing a hardware start trigger and sample clock for each card?
    1. yes, everyone is synced to the master card and share the master sample clock
  3. What timestamp(s) are off by 200 ms?
    1. From what I gathered, they are all constantly off by 200 ms (no drift...from what I heard)
  4. Does each task have a timestamp and they are all different by up to 200 ms from each other?
    1. There is only one timestamp....1 for all cards...so no
  5. What signal are you time stamping?
    1. A clock trigger made on the PXI-6682 (the signal used is made to change depending of some parameters...
    2. Maximum timestamping is 20 timestamps per seconds

 

0 Kudos
Message 3 of 18
(5,944 Views)

Hi Sebastien,

It’s still unclear to me what 200 ms difference you are observing. If all 8 DAQ cards are synchronized using a common start trigger (probably a Star trigger if it’s coming from a slot 2 timing card) and a sample clock (perhaps shared on a PXI trigger line) each task will have its own timestamp corresponding to when that task started. One thing that comes to mind it that each task, if the slave tasks are started before the master, will start at the same time in hardware but the Windows timestamps may differ slightly. This is due to how Windows processes those command for a time stamp and does not truly reflect the synchronization level. Can you elaborate on what difference you are actually observing and how? Your past posts: “From what I gathered, they are all constantly off by 200 ms (no drift...from what I heard)” and “I don't have any info on how the tester managed to know it was 200 ms off, my theory is he tested it with some older equipment to validate the new one” are unclear as to what is off. Your last post “a clock trigger made on the PXI-6682 (the signal used is made to change depending of some parameters...” is also unclear. Are you time stamping a sample clock? Can you post a reduced version of your code? Also, this may be something better suited to discuss with an engineer over the phone. Can you create a service request at ni.com/ask. Being able to discuss over the phone will most likely make things more clear and  ultimately lead a solution sooner.
Matt
Applications Engineer
National Instruments
0 Kudos
Message 4 of 18
(5,930 Views)

The trouble is that the project is closed and on warranty so the company will not leave me time to call, the forum on the other hand can be filled off normal working hours...

 

I know it is a bit hazy, but I don't know much myself

 

From what I gathered, it seems like they might be testing our product this way:

1) The client created a signal that would reach something like 5 volts (fictional value every seconds) that would make it time 0.

2) The client hooked the analog inputs of the NI cards to this signal

3) The client hooked some other devices (the ones they used before)

4) The client would log both inputs (from NI and from this other source) in 2 seperate files

5) The client would look at the difference of voltage from both files.

6) NI time would show every seconds as 200 ms off

 

As for what my software does in a nutshell is:

*) Find the most plausible master card (the card that would make a better master based on limitations)

*) Put every other tasks slaves to that master

    *) Make every slave start from the start trigger of the mast card (which is represented by the master task)

    *) Make every slave tasks use the master card's sample clock

*) Start every slave

*) Start the Master

 

Finaly, for the timing card

*) Create a clock that triggers every Xms

*) Create a timestamp input

*) Link the clock with the timestamp

*) Link the master task start trigger with the signal of the clock

 

 

As for when I get the timestamp:

*) Every N Samples, the timestamp is took from the fifo file of the timing card and sent to the file

*) The timestamp for every in-between sample is calculated using the basic formula: X+Y*DeltaTime where X is the current time calculated, Y is the sample index (from 0 to N-1) and DeltaTime is the time between timestamps.

 

Thank you for your patience, for now I'm mostly wondering HOW this happen, but there is so many variables.

0 Kudos
Message 5 of 18
(5,928 Views)

I'm beginning to think that maybe their *other* setup is at fault...

 

I see that you knew to start the slaves before the master as a necessary step to ensure sync.  That's a big one.  The only thing I'm not sure I understand in your approach is your talk about linking clocks and timestamps.  I know what *I* would mean in such a description, but am not sure it it's the same as what *you* mean.  So to get very specific:

 

1. Are your "timestamps" integer #'s of counts from counter hardware?  Or do they somehow involve the system time calls that provide date and time?

2. When you "link" the clock and the timestamp, what does that mean *exactly*?

 

 

-Kevin

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?
0 Kudos
Message 6 of 18
(5,923 Views)

Here is a bit more information

 

1) The timestamp that I get is in the format returned by :

niSync_ReadMultipleTriggertimestamp

I get the timestamp and turn it into a __int64 to be able to use system time to get the date (won't go in much details on how to convert UNIX date into FILE....can google it, pretty dull and copy pastable)

 

2) I create a clock (with a set high tick and low tick) and I connect the clock terminal to the timestamp terminal (since that terminal records timestamp only on a rising edge)

 

Hopefuly the info helps a bit.

0 Kudos
Message 7 of 18
(5,910 Views)

Hello there,

 

Kindly help me with DAQmx Time stamp related problem as described below.

 

Setup : PXI 6133 Qty 4 (Slot 3, 4, 5, 6)

PXI 6255 Qty 1 (Slot 2)

PXI 6255 doing a Continuous Acquisition at 1 mSec Sampling and 1000 samples/iteration.

PXI 6133 doing a Ref Triggered Acquisition at 1 uSec Sampling interval and Pre and Post Trigger samples of 100000 Samples each.

 

Test : PXI 6133 - Reference Trigger Configured on PFI 1 line of First PXI 6133 card.

                         input Signal given to AI 0 OF First PXI 6133 card.

                         All PXI 6133 cards are included in a single task.

PXI 6255 - Input given to Channel 0 AI

External Function generator - One Digital Trigger generated of width 50 mSec High Interval.

                                           Another signal generated for input to above cards. (Square wave of 10 mSec Period - 5 periods generated on the rising edge of trigger)

 

So It means When I acquire square wave in my waveform, I can consider rising edge of square wave as a rising edge of trigger (as both signals are generated aligned from external function generator)

I have attached Screenshots and programs I have used for that.

 

Problem: As both singal are generated at a same event, Both 6133 and 6255 should acquire that singnal at a same timestamp.

I have also read related documents about timestamp but I could not succeeded to find any link in this.

I am getting square wave 100 msec earlier in 6255 then of 6133.

If I used only single card of 6133 then that inaccuracy of 100 msec is shifted to 25 msec.

 

Please help me as soon as possible.

0 Kudos
Message 8 of 18
(5,080 Views)

Hi Jirav,

 

The problem is that you are not synchronizing your tasks. Please referrer to the example that you can find in the NI Example Finder » Hardware Input and Output » DAQmx » Synchronization » Multi-Device for more examples about this type of application.

 

Regards,

steve.bm
AE | NI
0 Kudos
Message 9 of 18
(5,054 Views)
Hi Steve, Thanks for your help. I have already checked those examples. but still i am confused as of below points. 1. I have One M Series cards and Four S Series cards, that wants to synchronize (Example finder helps us to synchronized same series cards) 2. In my test configuration, i need to configure Four S Series cards on Ref Trigger and M series cards on Continuous acquisition. So Ref Trigger in S Series cards can came at any instant after continuous acquisition starts in M series started. Kindly help me with any default examples for such application or any idea to implement.
0 Kudos
Message 10 of 18
(5,052 Views)