Softmotion PLL not locking

[Jagwa00]

Hi, I am wondering if anybody else has had this problem.

I cannot get the softmotion PLL to lock correctly. I have tried playing with the gains but it does not seem to help. I am sampling 3 phase 50 Hz analog signals which gets sent through to the fpga. The fpga loop runs at the same rate as the sampling speed so that the fpga will see the waveforms as 50 Hz. The PLL takes in abc and returns the frequency but it never quite "locks". It will hover between 45 and 55 and occasionally veer completely off course. Do I need to filter the values?

Any input or possible solutions are welcome.

[User002]

Jagwa00,

What chassis and the module are you using?  And do you have any customizations you have made to the code on the FPGA, or is it unmodified?

[Jagwa00]

Chassis: PXIe - 1062Q

FPGA Module: 7813R

I have made absolutely no modifications to the pll code.

[User002]

Are you using the 3-phase PLL VI, like the one found here?

https://decibel.ni.com/content/docs/DOC-19229

Did you base your code on an example code?  Which example might that be?

[Jagwa00]

That pll you mentioned is the correct one.

My code is attached.

[User002]

If I understand your code correctly, you are creating the sine waves on the RT, then passing them to the FPGA.  My thought is, why don't we do this all on the FPGA?  Is this to simulate a measurement taken somewhere else, or will it eventually be some signal that is dynamically generated?

I just ask to take a look at undestanding your application as a whole.  I wonder if that PLL VI is the right way to go.  

[Jagwa00]

I was simulating measurements taken somewhere else. I could build my own phase lock loop on the fpga but I was hoping to be able to use this VI as it is already done.

[User002]

I am looking into what might make this VI not lock.  With such a pristine vector, I would think it would work without a hitch.

While I look into that, we should consider other possibilities.  Have you benchmarked the timing on the FPGA, to make sure it is executing at the correct speed?  I also think it is worth looking at the speed at which the data from the RT system makes it to the FPGA, since the FPGA will be executing faster than the RT system can poll.  It could be that we need to pass down more points at a time.

I have looked through internal documentation for this VI and did see that it has been highly optimized for the FPGA, so I would be hesitant in reccommending reimplementing it just yet.  I will let you know what more I can find out.

[Jagwa00]

Thank you very much for the help, I appreciate it.

[User002]

After looking over your code again with another engineer, we seem to both feel that the timing is likely not happening how it is set up.  

The RT code passes one element down each iteration, and will likely not complete a full cycle every 1 MHz, depending on the controller.  And the timeouts on the FPGA FIFO reads on the FPGA are set to -1, so they will wait for the data to arrive.  What is likely happening is the FPGA is slowing down to wait for the RT system to pass it data each time, and that is throwing the timing of the operations off.  I would add timing instruments to check tick counts and see what your actual performance is.  That may go a long way towards getting the PLL outputs to be more in line with the actual data.