From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array, signal post processing

Solved!
Go to solution

Hi Everyone

i have 3 signals

1) GMR SENSOR signal (white colour pulse in image below)

2) encoder A pulse (720 ppr) (green colour)

3) encoder z index                 (red colour)

i have attached image of my signals below,

my problem is how to count number of encoder A (green color)signal pulses from 1st rising edge of GMR sensor signal(white color) to next rising edge?

one solution might be

as Encoder A and GMR sensor output maximum value = 4

so i moved data from excel to array in labview (file is attached below)

 then GMR sensor signal( array) value greater than 2 or 3 gives boolean indicator 

same for  Encoder A signal( array) value greater than 2 or 3 gives boolean indicator 

then how can i use this T/F boolean indicator to count number of encoder A signal pulses from 1st rising edge of GMR sensor signal to next rising edge?

0 Kudos
Message 1 of 12
(3,098 Views)

1. Direct answer:

Search GMR array for indices where boolean transitions F-->T.

Traverse EncA array between those indices while counting transitions of interest.

 

2. Impertinent questions:

Are you sure the encoder data was sampled fast enough?  It looks like you might have a sampling rate that's barely 2x the encoder pulse rate.  But it's *possible* you have a sample rate that's just about exactly 2/3 the encoder pulse rate and some of the encoder transitions aren't being captured.  (It appears you get 0.5 encoder cycles per sample, but you'd get a similar graph if you were getting 1.5 encoder cycles between samples.  Similar reasoning makes other possibilities emerge like 2.5, 3.5, 4.5, etc. encoder cycles between samples.)

 

Is there a good reason to do this via post-processing rather than doing this measurement directly?   You seem to have 5V digital signals here.  An encoder task that uses the GMR rising edge as a sample clock could make this pretty easy.  

 

 

-Kevin P

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 12
(3,083 Views)

Thanks Kevin P for you response

1)i haven't better understanding how to use "search 1D array" icon in my case. would you please make it possible by editing in my attached arrays file 

2) yes my sample rate is twice the encoder rate, is it good practice or not?

3) i am taking these signals from analog module of Cdaq.previously,  i had tried to synchronize z signal as analog, GMR signal as counter and pulse of A as counter  but failed to do this.would light up your idea how to do this? 

0 Kudos
Message 3 of 12
(3,068 Views)

"Traverse EncA array between those indices while counting transitions of interest."

would you elaborate it further? i can't get your point   

0 Kudos
Message 4 of 12
(3,052 Views)
Solution
Accepted by topic author sobansair

Below is one of many possible ways to approach this.  I first used the built-in Threshold Detector function to find indices for rising edge transitions of both GMR and EncA.  Then for each pair of consec GMR edges, I counted the # EncA rising edges.

 

The "In Range and Coerce" function returns True only for EncA indices that are between the pair of GMR indices.  The "Bool to 0,1" function converts from T/F to 1/0.  And the Summation function gives me a count of those EncA indices.

 

There are many other ways to do this post-processing, some of which will be more flexible if you need to consider falling edges, etc.

 

 

-Kevin P

 

count edges.png

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 12
(3,024 Views)

thanks kevin P

it is working accurately. how can we use Z index pulse to :

1)check number of GMR sensor pulses between two z index pulse 

2) similarly number of A pulse between two z index pulse

then we go for number of  A pulses from one rising edge to next rising edge of Gmr sensor in between to z index pulses 

0 Kudos
Message 6 of 12
(3,014 Views)

Um, it'd be the exact same processing, right?  Just change the roles played by the different signals as shown in the columns below.

 

as posted               #1                       #2      

    GMR                   Z                        Z

    encA                GMR                  encA

 

 

As you start asking more complicated questions (# enc A pulses between first 2 GMR pulses *after* a Z pulse), you may find that you should change algorithms from the not-so-flexible one I showed. 

 

 

-Kevin P

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 12
(3,012 Views)

yes,it is counting exact number of A pulses.

but i also want that it count no of encoder A pulses  between two consecutive edges of  GMR sensor pulses only in between z index pulse

as there are 10 encoder z pulses so my concerned data is in between them.

i have attached file with new raw data set

0 Kudos
Message 8 of 12
(3,002 Views)

Ok, so go ahead and start working on that...

 

(Meaning: I gave you some help to get you started, now you can use that help to learn, experiment, think and adapt.)

 

 

-Kevin P

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 9 of 12
(2,997 Views)

Reverting back to some early questions in the thread:

 

- if you continue with analog sampling, you should definitely sample the encoder at *much more* than 2x the encoder rate.  I'd go with something like the common rule of thumb that suggests 10-20x.

 

- Are pulse counts under different conditions what you *really* want to measure?  Or are you settling for counting because it seemed more manageable?

   Analog sampling will probably be sufficient if you only need to count pulses.  If you want *timing* information about signal edges, you should increase your sample rate to get better timing resolution.  (Switching over to counter-based tasks could give you sub-microsec timing resolution, but you should plan on a non-trivial learning curve.  Most people find it more intuitive to do high speed analog sampling and post-processing.)

 

 

-Kevin P

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? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 12
(2,994 Views)