Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

08-18-2014 08:19 PM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

08-19-2014 06:36 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions

Unofficial Forum Rules and Guidelines

08-19-2014 11:43 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

08-19-2014 01:31 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

08-19-2014 02:18 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

08-19-2014 02:29 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

08-19-2014 03:53 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

08-19-2014 04:26 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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

08-19-2014 04:55 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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.

08-19-2014 08:11 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

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