Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-6341 Phase Measurements

I'm gonna guess that you start this program *before* the encoder is in motion to generate edges.  If you don't move the encoder soon enough or far enough to generate 1000 measurements before the DAQmx Read timeout (default value: 10 seconds), that would explain the warning message you see.

 

This could also be a *partial* clue about the very large 1st measurement value, but it doesn't explain things fully.   Period measurement has a subtle difference on X-series boards like yours compared to the way it always used to work on prior generations of counters.  (And I haven't been a fan of the change, see here for more detail.)   A very large 1st measurement might have made sense on an older board, especially if encoder motion started substantially *after* the program was run.  But I was counting on it not being able to happen any longer on an X-series board.

 

Actually, on 2nd thought, the value you display is the ratio of 2 distinct measurements: 360 * (2-edge separation) / (period).  So a huge value like that would mean that either the 1st measurement of 2-edge separation is unusually large or the 1st measurement of period is unusually small.  Can you make separate array indicators for those 2 distinct measurements, then report back on which one has the unusual 1st value?   Also, try to have the encoder in relatively constant speed motion before running the program.

 

You *are* still using the X-series USB-6341 as planned, right?

 

 

-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 11 of 14
(480 Views)

Yes I am using the USB-6341. I ran into an interesting issue when adding indicators for the separation and period in that they just stay zero for some reason. I added an array min max, since for some reason when you do operations with them they work, even if you can display the array. I am using a function generator right now, to ensure I am getting constant stable signals, and the the signals are being applied before running the VI. Both signals are setup for 10kHZ, so the max period of 0.001 and the min time difference 0.000025 are correct. The issue is that both the 1st separation measurement is large, and the 1 period is small.

 

I'm not sure what is causing the timeout issue, as I am still getting the issue today with the function generator. It will work fine one run, and the next time throw the message up.

 

Output.PNG

0 Kudos
Message 12 of 14
(475 Views)

The 0 values you see are almost definitely just a display property issue.  Right-click your indicators for separation and period, select "Display Format", then set it to scientific notation and at least 4 significant digits.  You've got numbers in there, but right now the display is showing them rounded to 2 decimal places.  That's only for the indicator display though, that's why calculations still work.

 

I'm inclined to treat the 200010 warning as a back-burner issue for now.  When that warning does pop up, be sure to check and see whether the program actually read all the requested samples.  (You can do an array size operation on the 2 data arrays to find out.)  If so, then let's just leave that as something to come back to. 

 

Now, on to the core problem.

 

Your Max & Mins help show that the problem is in the 2-edge separation measurement.  (The smaller period measurement is only smaller by 10 nanosec, which amounts to 1 count of the 100 MHz timebase on your board.  Such deviations of +/- 1 count often can't be avoided when using one clock signal to measure another.)

 

Comparing the "Phase" indicator from your most recent screenshot and the previous one, it appears that the size of the error in the 1st measurement isn't consistent.  Is that what you observe?  Once you fix the indicator display format, run 10 times or so and see whether the 1st measurement of 2-edge separation is consistent or whether it varies.   That should be a clue.

 

Beyond that, I'm kinda stuck.  I haven't used 2-edge separation measurement extensively and am not sure whether I've done it while also using an Arm Start trigger.   All I can do is have you try to repeat what worked on my end.  Here goes:

 

   For each of the 3 designated terminals (2 for separation, 1 for period), choose "Browse..." from the top of the drop down menu.  Scroll around and select 10MHzReferenceClock for each of them.  Set the starting edge as "Rising" and the ending edge as "Falling".

    When I do that here, I get perfectly consistent measurements from both counter tasks, nothing at all odd about the 1st measurement of separation.  What do you see there?

 

 

-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 13 of 14
(468 Views)

I'm not exactly sure why, but today when I went to test it everything was working perfectly. Wasn't getting a huge number for the first separation, and every phase was exactly what it should be. I didn't even get the warring about sampling. I haven't changed anything from yesterday, so it is a little interesting that it is working flawlessly now. I'll be using this as a subvi, and will be running it a lot, so will see if it starts to happen again. For now though it is doing exactly what it should be doing. Thanks for your help.

0 Kudos
Message 14 of 14
(461 Views)