LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

fpga PID require more than 16 bits for data type

Hi,

 

So i am using Fpga PID block for a control task taht needs to be run at 1000hz. The problem I am having is that the FPGA PID block only accepts data types of 16bit length. This does not give me the range and accuracy that i require for the task. At a minimum i feel i would need 32 bits.

 

Is there some way to achieve this; maybe dynamic scaling? custom blocks, some other operation? or a completely different control alternative?

 

Any suggestions would be most welcome.

 

 

0 Kudos
Message 1 of 12
(3,638 Views)

You could make your own.  Start with the PID express VI, right-click on it and select "Open Front Panel".  This will cause a conversion to a standard VI.  Save this VI somewhere in your project and edit as needed.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(3,601 Views)

Why do you feel that 16 bits is insufficient? How many bits in your process variable and your output? Most of the NI modules have at most 16-bit inputs and outputs, so additional precision in the PID math won't have any effect on the actual output. You can scale your inputs or outputs to maximize use of the 16-bit range of the PID loop.

Message 3 of 12
(3,582 Views)

for two reasons.

one is that some input modules are more than 16 bits, even the 16 bit inputs on FPGA are represented as 20 bit fixed point numbers.

two is that the intermediate results, spefically the integrator typically require more bits than the process variable or output exspecially at higher rates.

Stu
Message 4 of 12
(3,572 Views)

Saturating the integrator is not necessarily a bad thing; limiting the integrator helps avoid excessive integral windup. The integrator does two things: gets you to the setpoint faster, and eliminates offset. In neither case is it advantageous for the integrator to store a larger value than the maximum possible output.

 

Even if the input is a 20-bit value, if it only has 16-bit of precision then the extra 4 bits are just a convenience for the programmer to do math.

 

I'm not trying to tell you definitely that you don't need a higher-precision version of the PID loop, but you should think about it carefully. You wrote "at a minimum I feel I would need 32 bits" with no justification. This should not be a "feel" issue - approach it scientifically and figure out what you need. More bits on an FPGA translates directly to greater use of FPGA resources and in some cases slower maximum loop rate.

Message 5 of 12
(3,565 Views)

the integrator max value is not the issue.  rather it is the smallest value that can be added to the integrator.  without enough precision, the integrator never integrates depending on the coefficient.

 

your comment about the extra 4 bits of the 20 bit number are not correct.  if you choose the calibrated method of input, the value is 20.5 voltage and not counts.  how would you propose to use that value on a 16 bit PID input?

 

Stu
0 Kudos
Message 6 of 12
(3,558 Views)

The input to the FPGA PID is a 16-bit fixed-point value. You can represent 20.5 exactly in fixed point. I don't remember the exact format (number of integer bits) of the PID input and don't have the FPGA toolkit on this computer, but you can scale as necessary to make the input range match the fixed-point range.

 

The coefficient (I assume you mean integral gain) has no bearing on whether or not it integrates, because the integration is done prior to multiplication by the gain. I understand your concern about the minimum you can integrate but I think in practice it turns out not to matter, if your input and output have the same precision (for example both 16-bit). You can pick your scaling and gains such that you need several counts of integrated error to get a one-count change in output if that's what you want.

0 Kudos
Message 7 of 12
(3,542 Views)

In practice i know it matters a lot.  if you have a low value of an integrator and a high loop rate, then the integration accumulator never grows unless it has enough bits of resolution.  maybe this has not occured for you but it has happened with real use cases for me.

I know this because i use closed loop control all the time.  if your suggestions revolve around "you can scale it so it doesn't matter" i would suggest that using the appropriate PID algorithm is even easier to do than figuring out how to use a poor algorithm.


@nathand wrote:

The input to the FPGA PID is a 16-bit fixed-point value. You can represent 20.5 exactly in fixed point. I don't remember the exact format (number of integer bits) of the PID input and don't have the FPGA toolkit on this computer, but you can scale as necessary to make the input range match the fixed-point range.

 

The coefficient (I assume you mean integral gain) has no bearing on whether or not it integrates, because the integration is done prior to multiplication by the gain. I understand your concern about the minimum you can integrate but I think in practice it turns out not to matter, if your input and output have the same precision (for example both 16-bit). You can pick your scaling and gains such that you need several counts of integrated error to get a one-count change in output if that's what you want.


 

Stu
0 Kudos
Message 8 of 12
(3,534 Views)

Just wondering, are you the original poster using a different login, or are we horribly off track?

 

The PID that comes with the FPGA toolkit has advantages and disadvantages. The major advantage is it's known to work and is heavily optimized for the FPGA, so it can handle a high loop rate in a reasonable amount of FPGA logic. For me that's made it worth working around the limitations of the the input and output format; it may not be the right tradeoff for you. But regardless, on an FPGA where there are limited resources, I think it's important to make decisions about data widths based on math when possible, and not a "feel" for what's needed.

 

That said, yes, you're correct that if the integral gain is less than 1, you will need an accumulator with more bits than the output if you want the integral component to be able to drive the output to the maximum value (which may not actually be desirable). I've even written such an algorithm in C for an embedded project (the processor had special-purpose 40-bit accumulators). I don't know how the FPGA PID is implemented internally nor whether it does something like that.

0 Kudos
Message 9 of 12
(3,525 Views)

no, i am not the orginal poster.

I have had a similar gripe about the NI PID.  the first answer above, code your own is about right whether you start with NIs PID or not.  I was responding to your answer regarding 16 bits and it's limitations.

I don't think most users of FPGA really understand fixed point and the limitations of FPGA algorithms.

as to NIs PID being optimized, I do not consider it optimized very well for FPGA.  we have improved it for both speed and space while using more appropriately sized arguments.  we have found this to be true for most of the FPGA IP that is shipped with LabVIEW.  there is a lot of masking of functionality going on that unless you look at the implemenation in detail, it might not be doing what you think it is doing.

Stu
0 Kudos
Message 10 of 12
(3,507 Views)