LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

In NI Max, does setting the input terminal to a different PFI line disconnect the default terminal from the counter's gate?

Hey Fancy Folk

 

TLDR;

I have a PXIe 6363 that has an encoder on counter 0 and 1.  I have 3 halls of a motor that I want to measure their pulse width (PW) for.  The halls are running to counter 2's, A, B, and Z line.  If I were to create a new PW read task for ctr0 and set the "Input Terminal" to one of counter 2's lines (CTR A or B since the default PW read for CTR2 is Z), would I need to physically disconnect the encoder's signal going to ctr0's gate, or does that happen internally?

 

Background:

I am writing code for a test stand that uses different hardware for different tests.  I have a PXIe 6363 in my chassis with counters 0 and 1 wired to encoders, counter 2 reading a hall, and counter 3 being a sample clock.  When testing my code, I noticed that my PW (pulse width) read gave me "3 bands of PWs" (I am using the PW to calculate the motor's RPM).  I know my motor is 3 E revs per 1 M rev, so I decimated my data by 3 and plotted all 3 arrays on the same chart.  As I was expecting, each plot was one of the "3 bands of PWs" I was seeing on my raw data.  I believe this is due to the physical variation of the halls (motor's pole pairs) and my plan is to average 60 (I assume that will be enough, 20/"band") PW reads to get my "PW read".  See images below since pictures are worth 1000 words regarding the "bands".

 

Matt_AM_1-1737469348501.png

Raw PW Reads - shows 3 bands of calc RPM

 

 

Matt_AM_0-1737469328610.png

Decimated by 3 data - shows each motor pole has its own PW band

 

When I did my 60 sample average, my RPM was calculated to be ~7160 RPM.  However, when I strobed the UUT, it was ~ 7020 RPM.  Therefore, I figured to get a better estimation for the motors RPM, I could average the average of all 3 halls.  However, CTR 0 and 1 have the ENC wired to them (CTR 3 is being used as a sample clock).  In NI MAX, if I created a "PW read task for CTR0" then set my "Input Terminal" to PFI0 (CTR2 source/A), does the NI card disconnect pin 3 (PFI 9/CTR0 Gate/Z, which is the default pin for a ctr 0 PW read) from counter 0's gate and connected PFI0 to ctr 0's gate?  

 

According to the device routing, I should have direct connections between my PFI lines and the counter's gate.

Matt_AM_2-1737473421254.png

 

I ask because the ENCs run to line drivers, then the line drivers runs to ctr0/1 and I am unsure if (but assuming it does) the line driver would effect ctr0's PW read if I internally route PFI0 to ctr0 gate (pin 3) and pin 3 is still connected to ctr0's gate.  If the terminal is still connected when I internally route things, I can use a relay to disconnect the ENC line running to pin 3.

 

Side note, after some thought, I am planning on using a period measurement and summing 3 periods to try and anchor my time to a mechanical revolution vs doing a PW read which anchors it to a theoretical 180 E deg.  I believe that the 3 periods would abstract away the motor pole pair tolerances better than doing a PW measurement.  Digressing, this post was already written as I had that period vs PW thought and continued with the PW logic because I didn't want to rewrite the post 😅. The core concept of this post (does internally routing a signal on the PXIe 6363 disconnect the old terminal and connect only the new one to it) still holds true because I want to measure the period of all 3 halls instead of the PW.

 

Thanks,

Matt

0 Kudos
Message 1 of 6
(106 Views)

Fancy Folk,

 

I took a multimeter in continuity mode and checked arcos pins 3/11 (crt0 gate/PFI0) and pins 41/43 (ctr1 gate/PFI2) without the task started and there was no continuity.  I then started the tasks and checked again - no continuity.  The data I was reading makes sense and matches what I am seeing on ctr2's gate.

 

Therefore, I think I'm good to say that when connecting the PFI 0/2 to ctr0/1's gate, that the NI card disconnects the default pin (ctr0 = 3 and ctr1 = 41) and connects the desired pin (PFI0/2).

 

Matt

0 Kudos
Message 2 of 6
(84 Views)

This makes sense when it comes to routing *input* signals to the internal counter pins (such as gate, source, aux).  It would *need* to be true that no more than one external PFI terminal could be connected to, and thus "drive" the counter input pin.  After all, what if two were connected at once, one high one low?  Then what?

 

Note however that this kind of auto-disconnect may *not* happen when it comes to counter *output* pins.  There's a characteristic known as "lazy uncommit" that may cause a counter output signal to be routed to more than one PFI pin.  You can search that term here to learn more, meanwhile here's one particular explanation (the author was NI internal at the time he posted).

 

In general, I agree with your choice of periods over PW.  You get the same measurement rate (1 per sensor per revolution), but you smooth out some sources of variability.  Note however that it's quite possible that the PW "banding" was actually telling you something true, albeit maybe not interesting or useful for your purposes.  Not knowing your system, I can't rule out the possibility that there's a repeatable speed variation per rev, perhaps due to a repeatable load variation per rev.  If that were the case, it'd make sense that 3 distinct sensor positions would record distinct speed bands.

 

 

-Kevin P

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 6
(56 Views)

Kevin,

 

Strange that the outputs can get tied, but it makes sense regarding the "DI high/low" comment from your post.  I figured there was a mux or something that gets set when tasks are started to route thing properly.  Thanks for the heads up and link to the counter output page, I'll need to give that a read!

 

Everything below is relative to my project regarding the "PW/Period speed calculation".  It is not specifically relative to labview, but it may help someone who is running into this issue in the future, and I want to provide information to those searching the forums (like myself a lot of the time).  

 

Regarding the RPM calc using period vs PW, I made a wonderful MS paint drawing to help myself visualize what was going on (image below)

Matt_AM_0-1737556874440.png

 

The black circle is the stator, the brown X is the hall sensor, the red circle is the rotor, and the green/purple/blue are pole pairs.  As the rotor is spinning, Brown X is picking up G,B,P pole pairs.  Since there are 3 pole pairs, I should be expecting 3 PW returns.  The "bands" I was seeing in my initial PW read were due to the variation in tolerances of the magnetic pole pairs.

 

So after sitting down and thinking about it, it makes sense to me that I am seeing "3 bands" since I am picking up "3 unique pole pairs" and any variation in the pole pairs (magnet strength, physical dimensions of the magnets, physical placement of the magnets, etc.) will cause a variation in me reading my PW.  Therefore, if I wanted to anchor myself to a more "stationary point", such as "G -> G" period (or P->P/B->B), then I know that 1 full mechanical revolution has occurred in 3 consecutive period measurements (G -> B -> P -> G).

 

My new algorithm using the 3 consecutive period measurements and has given more accurate and repeatable speed calculations compared to my old "assumed PW = 180 E deg" calculations.  We got an older strobe and I my speed calculation is within 10 RPM of the strobe.  All of my "G->G/B->B/P->P" are around the same value (using 3 counters to read the period of all 3 halls) and I am seeing "1 speed range" and not "3 speed bands" (like I was for my PW algorithm).  Since "each unique pole pair" for a hall are similar calculated speeds, and, each of the 3 halls are giving similar calculated speeds, I believe the 3 consecutive period measurements = 1 mech rev is, for now based on the info I have, the best way to determine speed for my situation.

 

Matt

0 Kudos
Message 4 of 6
(49 Views)

@Matt_AM wrote:

Matt_AM_0-1737556874440.png

...I know that 1 full mechanical revolution has occurred in 3 consecutive period measurements (G -> B -> P -> G).

 

Isn't that just 1/2 rev?  Wouldn't you need to sum 6 consec periods for a full rev?

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 6
(23 Views)

Kevin,

 

Good point, I didn't state additional details.  For my system, the halls are 120 deg apart, so 3 consecutive reads give me 1 rev.  Additionally, my halls are only 2 states, 5V of 0 (if you ignore the noise and transition periods 😅)

 

However, I know some systems have 60 deg halls (see reference images below).  I am by no means a motor expert, and if you are following my previous "for future people" logic, make sure you are summing the correct number of periods for your system.

 

Matt_AM_0-1737663954798.png

Matt_AM_1-1737663983606.png

 

Thanks,

Matt

 

0 Kudos
Message 6 of 6
(16 Views)