Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

NI 9514 servo control jitter free

Solved!
Go to solution

Hi, I have a Question since I still don't understand something about my program. First of all I'm using a cRIO 9022 and a NI 9514 module with an AKD Analog servo Drive to control my motor. I already have a VI using scan mode interface and the SoftMotion function blocks and it works OK. The problem is that, according to what I understand, this scan mode is using the scan engine clock, where the minimum scan period is 5 ms. I'm running my motor between 500 and 2000 rpm and the "only" thing I need is to send a TTL output signal at a given position that I'm using as a control variable. (I'm using a NI 9401 for that hooked up to the Position Compare function block). As I said, this works but not very precise and there are only 2 options, either the control loop is too slow or there's jitter in the other system that I'm using (I can take images at the rotor and see with high accuracy the angle, and 1 or 2 degrees is a big error for me, and that means only 0.5 ms in time, if I use 720 rpm for example. I'm getting now 5 to 6 degrees of error).

 

If my control is the problem, how can I make sure it's the VI the problem and is there anything I can do to solve this issue? I read here https://forums.ni.com/t5/LabVIEW/NI-9514-FPGA-and-SoftMotion/m-p/2173030#M699003 that even if I use FPGA with my NI 9514 I still can't remove the scan engine.

 

 

 

Thanks a lot!

 

 

Italo

0 Kudos
Message 1 of 11
(7,086 Views)

Hi Italo,

 

From what I am understanding of your application, we have a rotary motor with an encoder value reporting the current position of the motor.  At a certain point in the rotation, we want to generate a digital output.

 

If you're analysis code that calculates the position of the encoder to generate the digital trigger is running in Real Time, it probably won't be fast enough to get the time resolution you are looking for, as it sounds like you have noticed already.  One solution to this might be to do your positional analysis on the encoder in FPGA, but I am not certain that this is ideal.  I am going to look into this a bit further and will let you know once I have more information.

Andrew T.
National Instruments
0 Kudos
Message 2 of 11
(7,060 Views)

Hi Andrew,

 

That's correct, it's exactly what I want. Any solutions will be much appreciate.

 

 

Thanks!

 

 

Italo

0 Kudos
Message 3 of 11
(7,055 Views)

Hi Andrew, any news about it?

0 Kudos
Message 4 of 11
(7,036 Views)

Hi Italo,

 

Are you using some of our example code to accomplish this?  If so, which example from the NI Example Finder are you using?  If not, could you post the code you are using to do this so that I can take a look at your methodology?

Andrew T.
National Instruments
0 Kudos
Message 5 of 11
(7,012 Views)

Hi Andrew,

 

I attach 2 images of my codes, the first one is the simplest one that I pretty much copied from the example (Position compare). The second one is without the position compare function block, so I'm reading the position and applying the in range and coerce function (And also I added a period control so I can fire the signal every certain period specified). I log the data after that and I realized that the second method is more constant than the Position compare one. Anyways the problem is this is in scan mode, so I'm limited by the scan engine.

 

 

Italo 

 

 

Download All
0 Kudos
Message 6 of 11
(6,998 Views)

Hi Italo,

 

The best way to get the digital trigger value you are looking for is going to be through the Position Compare pin on the 9514.  When we associate the Position Compare function in your block diagram to the axis connected to your 9514, the function will automatically route the position compare done value to this pin.  The pin can be accessed by using the terminal block connection linked below:

 

https://www.ni.com/docs/en-US/bundle/372153e/resource/372153e.pdf

 

As you can see in the terminal block's manual linked above on page 2-13, the pin in the upper right is Position Compare.  This output will be hardware timed, and will allow you to bypass the scan engine which is limiting the resolution of your 9401 output.

 

 

Andrew T.
National Instruments
0 Kudos
Message 7 of 11
(6,974 Views)

Hi Andrew,

 

I was reading your answer and I have some questions:

 

- I already have this cable http://sine.ni.com/nips/cds/view/p/lang/en/nid/209129, so I'm not entirely sure if I need the block connection you mentioned, because in this cable there's a 20 pin block,   apparently corresponding to the MRD connector, which has the position compare pin.

 

- Do I have to wire that pin directly to the NI 9401 or is that output already a 5V TTL signal that I can access and send it to the software I'm using?

 

- Can I keep my scan interface program to control the motor or do I have to use FPGA instead?

 

 

Thanks a lot!

 

 

Italo

0 Kudos
Message 8 of 11
(6,966 Views)
Solution
Accepted by italo.franchini

Hi Italo,

 

Here are some answers to your questions:

 

- If you can access the Position Compare pin, then you should be fine without the hardware connector I mentioned in my previous post.

 

- The output of the position compare pin is a 5V TTL signal that you can access and use as your digital trigger.  This will be generated at a much more reliable rate than the digital trigger you were generating through the 9401 using the scan engine.

 

- Your scan interface program should continue to work fine.  The program you are using is capable of controlling the motor at the rates you were hoping for, the only trouble is that we were relying on the scan engine for the digital trigger on the 9401, which was not giving you the trigger resolution you needed.  Using the Position Compare pin from the 9514 addresses this concern for us.

 

Andrew T.
National Instruments
0 Kudos
Message 9 of 11
(6,948 Views)

Hi Andrew,

 

Thanks for your answers, that must certainly solve the issue. Before I accept your answer as a solution, I have a final question. I have, as I showed you before, 2 programms for controlling my motor. The first one, with the function block, triggers the position compare only once. The second one triggers the position periodically by reading the position and updating the position to be compared again. I did this because I could never make it work with the "Periodic position compare" that comes with the function block. Even when I tried the example "Periodic position compare" I never had the expected result, since I need a signal that triggers at a certain position and then goes back off until the next position occurred. 

 

So now I also need to trigger this periodically but since my second programm is not accesing the function block, I'm going to have the same problem. My question is how can I make the periodic position compare work so I can, for example, trigger a signal at a certain position (let´s say 20°), then that signal goes off and triggers it again at 20° but after 3 complete revolutions of the rotor? (That is, tirggering the position compare every 3 full rev).

 

I´m using the labview 2009 sp1.

 

 

Thanks again for solving my other problem!

 

 

Italo 

0 Kudos
Message 10 of 11
(6,940 Views)