LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get external clock properties

Solved!
Go to solution

Hi,

 

I'm using an external clock for AI task.

 

CHAJ_1-1576081102427.png

as follow:

CHAJ_0-1576081030645.png

This is an AVL Encodeur with 360slits .

I perfectly get each AI measurement every degree. I would like to know the time between each slits from my external clock. Of course I would like it synchronised with the AI channel.

 

CHAJ_2-1576081555337.png

Ex 3.6k sample read.

0 Kudos
Message 1 of 18
(925 Views)

Some VI and Max configuration.

0 Kudos
Message 2 of 18
(911 Views)
Solution
Accepted by topic author CHAJ

To measure time intervals of a digital encoder signal, you'd want to set up a counter task.  I'll assume you have a multifunction device and an available counter because that's what you'll need.

 

1. Configure the counter task for edge counting.  When you call DAQmx Timing for that task, wire into the 'source' input the same terminal name you used when calling DAQmx Timing for you AI task.  Now you'll have a shared sample clock.

 

2. You'll also need to configure a DAQmx Channel property node on your counter task where you'll specify the signal whose edges you want to count in order to track time between the encoder edges.  Depending on your device, the best choice will probably be either 80MHzInternalTimebase or 100MHzInternalTimebase.  The higher the freq, the better the time resolution of your measurement.

 

3. Start your AI and counter tasks before the encoder is put into motion.  (There are probably workarounds if this isn't possible, but it's simpler if you *can* do it this way.)

 

3. Your counter task samples will represent "total # cycles of the internal timebase" from task start until the sample # in question.  The very 1st value is a likely meaningless offset that you can subtract off of all the count values (including the 1st, turning it into a 0.)   If you were to divide by the timebase freq you'd get an array of "timestamps" in units of seconds relative to 1st encoder edge.

 

4. There are a couple subtleties related to rollover of the 32-bit counter.  This is also referred to as the counter reaching terminal count.  If you run for as much as a minute or more, you'll encounter this.  (time of rollover = 2^32 / timebase_Hz).

    A nice feature of unsigned 32-bit math is that a finite difference of the raw u32 count values will end up compensating for this rollover effect.  The largest possible u32 value is (2^32-1).   Add 1 to it and you'll get 0.  Subtract 1 and you'll get (2^32-1) again.  For the same reason, a finite difference of consecutive values will be correct even if there was a 32-bit rollover between them.

 

5. If you need to accumulate these interval times, you'll need to convert to a datatype that can handle a bigger range of values.  You'll probably be fine going straight to DBL so you can work in units of seconds.  I usually hang around in integer world as long as possible by converting first to 64-bit ints.  It's mostly just a habit to avoid accumulation of floating-point roundoff error, but it probably usually isn't crucial.  It tends to take quite a bit of processing to become non-negligible.

 

 

-Kevin P

0 Kudos
Message 3 of 18
(840 Views)

Many thanks, It works weel

CHAJ_0-1576227707557.png

0 Kudos
Message 4 of 18
(627 Views)

Hi,

 

I have a new question the time ellapsed betwen pulse (dt), and the the analog input are not synchronized.

The data aquisition works very well.

 

Is there a solution to solve my problem?

 

I think that the start of counter and acquisition is not the same.

 

This is the 2 task I m using in max.

 

PFI 13 is  the big teeth on the encoder (one per rev)

PFI 12 is the 359 small teeth from the encoder

 

ni.jpg

 

Many thanks and best regards,

0 Kudos
Message 5 of 18
(165 Views)

Can you describe things in more detail?  I'm not really inclined to import your MAX config and risk messing up my own.  I've never really liked defining global tasks in MAX, I prefer to define them from scratch in code.  Then I can really know what I'm dealing with.

 

What *exactly* do you mean by "not synchronized?"  Start time?  Time of individual samples?  Both?

 

 

-Kevin P

Message 6 of 18
(161 Views)

Hi,

 

I think the start time for the both acquisition (counter and AI) are not the same.

Signal of the 2 task are correct but not at the same start time.

 

Attached the view of the max config to help understanding of what is defined.

 

Also Attached the VI. I created task with labview assistant with exactly same parameter i'm normaly running. I modified nothing to prevent...mistakes

 

Best regards,

Julien

0 Kudos
Message 7 of 18
(146 Views)

The real problem is that your code doesn't use hardware timing signals to sync your tasks.  You *can't* get reliable sync the way you're doing things.  Reread and try to follow the things I said last year in msg #3.

 

 

-Kevin P

0 Kudos
Message 8 of 18
(120 Views)

Sorry again for my misunderstanding and approximate english

 

Both task share the same hardware clock.--> ok 

 

the AI task start with the hardware trigger. Trigger is also used for reset interferometer material.-->ok

 

I don't know how to start the counter task with a shared trigger, with AI task.

 

Maybe my explanation is more clear,

 

thank you

0 Kudos
Message 9 of 18
(115 Views)

Well, I'm afraid you've bumped up against one of the reasons a lot of us old-timers basically NEVER use the DAQ Assistant.

 

Counter input tasks can only be triggered by configuring a unique-to-counters "Arm Start" trigger.  And the DAQ Assistant doesn't give you any access to it.  You can only do this kind of configuration with the regular DAQmx functions.

 

Search here for "Arm Start Trigger" and you'll be able to find some example code for how to configure it using regular DAQmx functions.

 

 

-Kevin P

Message 10 of 18
(90 Views)