Fix for PID component to accept symbolic parameters

[bradcarman]

fixes #203

[codecov]

Codecov Report

Merging #231 (1aaef71) into main (0fbd414) will decrease coverage by 0.20%.
The diff coverage is 60.86%.

@@            Coverage Diff             @@
##             main     #231      +/-   ##
==========================================
- Coverage   55.31%   55.12%   -0.20%     
==========================================
  Files          48       48              
  Lines        1609     1620      +11     
==========================================
+ Hits          890      893       +3     
- Misses        719      727       +8     

Files	Coverage Δ
src/Blocks/Blocks.jl	100.00% <ø> (ø)
src/Blocks/continuous.jl	86.11% <60.86%> (-4.87%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[baggepinnen]

Thanks for fixing with the parameters :)

I'm not sure if I like the new syntax though

@named pid_controller = PID("PI"; k = 3, Ti)

If you want a PI controller, why don't you call PI instead of PID? Using strings as arguments to select options is rather uncommon in Julia.

This is also a breaking change since you have changed the method to turn I and D off from passing false for their respective parameters to passing with_I etc., and I am strictly against breaking changes unless they are extremely well motivated and accompanied by a major version bump (which itself is associated with a large amount of extra work for everyone).

[bradcarman]

I see this has unfortunately breaking changes. However, this is something that needs to get fixed. Currently it's not possible to build a controller system that owns the parameters that are fed to the PID since currently the inputs for Ti and Td need to be strictly numeric values and not @parameters. I'm not a fan of the proposed interface, but it's the best I could come up with since we are forced to separate with_I and with_D from the actual inputs of Ti and Td. I wish there was a better way, maybe a new ModelingToolkit.jl feature could allow for the original interface.

[baggepinnen]

Maybe we could avoid breaking the interface by

1. Letting PID work exactly the same if the provided parameters are numeric
2. Have a separate PD component to handle the case where there is no integrator. We already have PI.
3. Let PID always be PID if parameters are symbolic.

That way we would never need any structural parameters, since the structure is determined by the user selecting the appropriate component out of PI, PD, PID.

Would this solve your problem?

[bradcarman]

Yeah, I think this is the right way to go.