Issue in Sync of angle derived from AI and Encoder

[padhu_1]

Hi All,

I am using USB 6353 for my application.

I need to find the angular position (Degree) of the motor when it rotates. I have two encoders (No 1) Incremental Quadrature Encoder which gives A/B/Z signal (used as reference), (No 2) Another encoder which gives sine and cosine values.

The (No1) encoder is a incremental encoder which gives digital pulse of 5V and 5000 pulses per rotation.

The (No 2) encoder gives sine (4 waves) and cosine (4 waves) for one complete 360°, which means 1 sine and 1 cosine wave for rotation of 90°. These sine and cosine values are acquired using 2 Analog input channels (AI0 & AI1) and then are converted to angle.

In the code attached (AI_Encod Sync Capture.vi) am trying to capture the AI and encoder signal simultaneously. I have used the Analog start trigger for the sample clock of encoder and configured with same sampling rate and no of samples. But when i capture and see the result, the angles are not synchronized. (Check compared result of the array Inc Angle and All mech Deg Array).

Check the data from Column 9110 onwards, where the motor starts rotating. The encoder reading are started from 0° for (No1) encoder and 35.10° (No2) encoder, which means when motor rotates and acquisition started this 35 degree offset to be maintained which confirms the acquisition of the AI and encoder happens at same rate.

I compared the results and found the the AI samples captured and buffers with more accurate samples than the encoder sampled data. Because i could see the rate of change of degree in (No1) encoder is more comparative with (No2) encoder (refer the attached image on comparison of data). For the change of 1° in Encoder only 0.2° has been changed in AI, this variation is also not similar.

Is this because AI is sampling more accurate data than the encoder data. how to correct this issues. Any suggestions please.

[Kevin_Price]

I'm going to suggest several small changes which should collectively get you a lot closer.  But I first want to recognize that you've done a substantial number of things unusually well for a first-time poster.  Don't be discouraged by the following "critique", it's only meant to help.  My main emphasis is: Nice work!

1. Dataflow.  The diagram disable structure around the AI config forces the AI task to start before the CTR (encoder) task finishes its config and starts.  This is the opposite order you want when the CTR task is set to be triggered by the AI task.  The CTR task should be started (so it's armed and waiting for its trigger) *before* the AI task.

2. Arm Start.  Good job finding out about this relatively obscure (but sometimes crucial) setting.   Two problems here:

A. it doesn't actually take effect unless you also set the Arm Start property "trigger type" to be "Digital Edge".  I have a past memory that makes me think this should be the first property you set, but a recent forum thread called that into question.  But in any event...

B. you don't really *need* it in your situation anyway (probably).  The shared sample clock from the AI task is sufficient to maintain sync.  The only additional advantage of the Arm Start trigger is to set the instant when the task will start tracking motion from 0.

3. Z-index.  Your front panel shows that you've enabled Z-index reset with a value of 1 degree.  If you're going to enable Z-index reset, I would think you'd want a value of 0.

4. Subtracting exactly 2.5 from each of your Sine and Cosine channels strikes me as "theoretical and optimistic".  I assume your analog signals must be alleged to range from 0-5 V with a nominal center at 2.5.  I would advise you to be dubious of this allegation until / unless you check it out carefully.

5. There's an atan2 function available that will give you an unambiguous 4-quadrant atan instead of the 2-quadrant version you're using.

6. I didn't try to decipher every aspect of your code.  But it doesn't appear that you've fully accounted for the following inherent issue:

    Your analog encoder is somewhat of an absolute encoder.  The sine and cosine values give you an absolute placement within 1/4 rev.   When you start the task, the analog values will give you some kind of atan2 angle from 0-360 which map to a real physical angle from 0-90.  And it will almost *never* be exactly 0.

    On the other hand, the encoder task *will* start from a count / position of exactly 0.  So you should *expect* to see a fixed offset between the analog and encoder angles.  It isn't an error or a problem, it's just a consequence.

7.  Using Z-indexing for your encoder task and also using the "wrap angle" function for your analog angle measurement makes things trickier.  Maybe you have a good reason to stick with doing things this way, but let me describe how I'd *want* to approach things, if allowable.

    First, extract and retain the very first angle measurement for both the encoder and analog tasks.  Subtract them from all subsequent data so that both results are forced to "start from 0".  Second, no Z-indexing for the encoder task so it can increase (or decrease) continously.  Third, use the 4-quadrant atan2() function for the analog task to place you unambiguously within a particular physical 90 degrees.  Fourth, use the "unwrap phase" function on your analog angle so it can increase (or decrease) continuously like the encoder angle.

-Kevin P

[padhu_1]

Hi Kevin_Prince,

First of all Thanks for going through my complete statement issue. There is noting to get discouraged by the comments and I take its all for good improvement. I tried and studied many ways to implement this logic for AI and CTR synchronized due to which i was able to provide many data in my first post.

Reply for 1: You are correct. I kept the diagram disable structure around AI sometime before for some other testing and i forgot to remove. Yes there also could be a reason for not synchronized start for AI and CTR. I will remove and check.

Reply for 2: You mean to say when we maintain the same sample clock for AI and CTR this Arm trigger is not required?

However, i will try to include the the "Trigger type" and test the same.

Reply for 3: Yes, the Z-Indexing value suppose to be '0' instead of '1'. But for some reason i changed it to '1', but i dont remember. I will re-check the same.

Reply for 4: Yes, the sine and cosine voltage range is 1.5V - 3.5V with 2.5V center. Subtracting with 2.5V to bring it down +1v to -1V with 0V as center. For display and angle conversion purpose.

Reply for 5: I have and compared with atan2 function for angle conversion and tried to understand it. So using atan2 function eliminates the below section of code which converts the angle from 90 to -90 as 0 to 360.the actan2 directly converts to 0-360. Hope my understanding is correct. attached the experimental code for reference.

Reply for 6: Yes. sine and cosine are from absolute encoder and 0-360 degree is equal to mechanical (Physical) 0-90 degree. Measuring the initial offset between the CTR and AI and keeping this as a fixed offset for all the values.

Reply for 7: The wrap angle in the AI is used in order to convert the values from Radians to Degree.

Let me try to check the way you proposed.

Thanks.

[padhu_1]

Hi,

Further to the analyze made on the AI and Encoder Issue. The acquisition by the hardware are happening in a synchronized manner, however the start acquisition is not happening simultaneously. Attached the test data which shows that the AI and Encoder is synchronized, but then the initial start has not happened on the same time and that's why the expected encoder Zero and AI Zero is not available in same index and the Analog angle is shifted by few samples based on the RPM.

I tried few methods like keeping start task of both AI and Encoder in a sequence structure, tried using analog ai trigger for the encoder. but nothing results in good.

Is there any method for synchronized starts. Also attaching the test VI for reference

[GerdW]

Hi padhu,

---

@padhu_1 wrote:

Is there any method for synchronized starts.

---

When you want to start several DAQmx tasks synchronously then you should learn about DAQmx StartTriggers.

There should be example VIs in the example finder on this topic…