- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for PID component to accept symbolic parameters #231
base: main
Are you sure you want to change the base?
Conversation
Codecov Report
@@ 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
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
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 |
Maybe we could avoid breaking the interface by
That way we would never need any structural parameters, since the structure is determined by the user selecting the appropriate component out of Would this solve your problem? |
Yeah, I think this is the right way to go. |
fixes #203