LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Softmotion PLL not locking

Okay.

 

I have now included timing measurements in the fpga code. The result is that the loop does seem to stray from 100us but very rarely. I then set the timeout to 0 so that it doesnt wait. The result is that the loop executes at the desired 100us every time.

 

This did not solve the problem of the PLL though and it is still not co-operating,

 

New code is attached.

Download All
0 Kudos
Message 11 of 19
(591 Views)

That looks good.  I'm glad we got the code timing execution locked down.

 

 

The next possibility is that elements are not being written into the FIFO at the speed that they are being read out.  It would be a good idea to see if a value is undefined, and if so, turn on an indicator.  I suspect that the software latency will not be able to keep perfect timing with the FPGA, and that more than one element should be written to it at a time from the RT side.

 

Latching on the indicator is a good way to see if an error happened, since the execution is so fast (see step 5):

 

http://www.ni.com/white-paper/11406/en

 

 

 

0 Kudos
Message 12 of 19
(581 Views)

I have attached my updated code with the latch for errors. I check for both a timeout and an NaN value.

Only the timeout latch ever gets triggered.

 

 

 

Download All
0 Kudos
Message 13 of 19
(575 Views)

I dont think sending more than one sample of each phase at a time is viable since they will only be available from the DAC one at a time when the system is running.

0 Kudos
Message 14 of 19
(569 Views)

How is your DAC system set up -- Will the data be coming from another place on the FPGA, or somewhere not on board the cRIO?

 

The thing to worry about in the latter case is software latency and jitter.  If we send one point at a time, then the communication bus (USB or ethernet) as well as the software stack must perform perfectly each iteration, or data will be lost. A rate of 0.1ms per data point is fast for most operating systems to poll that kind of data in that way, given the latencies involved.

 

If the signal can be read onboard the cRIO, then software can be cut out of the loop, and things can be much more steady from a timing perspective.  

 

As far as the sampling rate, have you taken into account the pipelining in the PLL VI?  In order to conserve FPGA resources, it takes pipelines operations over several iterations.   Current result are available only after several iterations.  This may have an impact on the turnaround after an operation.  I just want to make sure that this possible issue is addressed and taken into account in your design, as well.

0 Kudos
Message 15 of 19
(565 Views)

The hardware is a PXI running a Real Time Operating System and not a cRIO. The DAC module is a seperate module from the FPGA module and the sampled data will be sent in a similar way to the current coding (The data is not sent over usb or ethernet). I'm not familiar with the term pipelining but it sounds like it delays the data somehow. That is fine as long as all three waveform values that are being used are from the same sampling instant. The pll should still be able to output a constant frequency. This is a bit of a niggly problem, I even tried to implement a pll of my own with no success.

0 Kudos
Message 16 of 19
(562 Views)

My apologies about the cRIO/ PXI mixup.

 

Your latency in this case would be considerably less than if there were another bus were involved.  Still, depending on the controller, that level of consistency at that speed may be hard to achieve, if possible.  What controller do you have?

 

If we sent the data from the DAC module in chunks of, say, 10 at a time, and it cleaned up the FIFO issues, would that cause any problems in your application?

 

In fact, if you were to tell me a little bit more about your application, I may be able to help more.  Are these PLLs for power switching, or for motor control, by chance?

0 Kudos
Message 17 of 19
(557 Views)

The application is a grid connected inverter. I am measuring the three-phase grid voltages and synchronising my converter output with the measured waveforms. I don't think I would be able to send more than one value at a time because the fpga loop needs to be running at the same rate as the sampling time of the DAC in order for the FPGA to see a 50Hz signal. I am not near the hardware but im pretty sure the controller is the NI PXIe-8108 Core 2 Duo 2.53 GHz.

0 Kudos
Message 18 of 19
(553 Views)

I see now.  I have a few suggestions.

 

First of all, the main advantage of the FPGA in this application is that we can put all of our calculations on it and eliminate software latency from the loop.  The fastest, lowest latency system would likely have that capability.

 

As your FPGA has no analog input channels, that may not be directly possible without getting new hardware.  If you wish to use your current hardware, I would sample as fast as you can with your DAC card, and send the buffered acquisition (multiple points) to the FPGA on the RT controller.  On the FPGA, run the loop at the same speed as the acquisition.  Then it will be going as fast as possible, with the least latency that your hardware can provide.

 

The potential problem with this is that the system still has software latency, as it is dependent on the software on the RT controller to take the values from the DAC and send them to the FPGA FIFO.  With some benchmarking, you could determine the delay and phase difference, and see if it falls within the needed specifications.

 

We have some more resources at ni.com/powerdev

 

There, we also have info about our new General Purpose Inverter Controller, which is meant for this kind of application.  Its FPGA has analog inputs so all of the control can be implemented on the FPGA, cutting software latency out of the system.

0 Kudos
Message 19 of 19
(531 Views)