Using discrete integrator block with embedded coder

Hello all,

Someone asked me today, "why don't we just use the built-in integrator block for our projects?" Short of saying, "Well, every project I've ever been invovled with has used its own home-grown integrator block." And that is true. No matter where I have worked, we always had a custom library block for integration in projects where the models are ultimately deployed in a target processor.

I have looked at the code output, and it seems reasonable. If you don't mind the autogenerated names, it's just fine.

I am not a fan of the "we always do it that way" answer. So, I'm curious, other than potential special customizations like personal preferences for anti-windup for example, why not use the Discrete integrator block?

Answer 1

[Jonas]

I also use 'my own' integrator blocks or implementations with Embedded Coder.

I work in an Export-Function model where it generates a function call for each task. This means that the blocks inside the Function-Call subsystems inherit the sample time from the HAL code which triggers the tasks. At the point of code generation, the blocks don't know which sample time they are going to work at, so the sample time cannot be inherited by a Discrete-Time Integrator block (Simulink will complain about this). The sample time can be filled in inside the Integrator block as a fixed value, but I use a Data Store block with Simulink.Signal object in the Data Dictionary for the sample time.

That's why I implemented an integrator block with the sample time as input, which I provide from a Data Store Read.

Probably a very specific reason not really answering your question, but I do have my reasons for implementing it. Same thing for PI controller blocks. It is quick and dirty to use the Library blocks, but usually it is preferred to implement local variants of it because of reasons of sampling time, anti-wind up, etc.

[John Fiaschetti]

You highlighted the part about passing in the step time for cases like function call trigger. That makes sense to me. I often use function-call triggers as a means to control execution order of reference models in a larger model. This is why I didn't do it in the past. In instances where this is not the case, does anyone else have a reason?