-
-
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
Start to Translational library with both Velocity and Position based connectors #114
Conversation
Codecov Report
@@ Coverage Diff @@
## main #114 +/- ##
==========================================
- Coverage 69.06% 65.13% -3.93%
==========================================
Files 25 32 +7
Lines 1225 1394 +169
==========================================
+ Hits 846 908 +62
- Misses 379 486 +107
📣 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.
Is it intentional to have both s0
and s_0
?
I see this in the sensor component, I've changed to |
About connector naming...there is a problem: when defining a block that combines domains, such as a hydrualic actuator that needs hydraulic and mechanical connectors, we will need to be able to distinguish connectors. For example function actuator()
@named H_a = HydraulicPort()
@named H_b = HydraulicPort()
@named MT = TranslationalPort()
eqs = [
(H_a.p - H_b.p)*area ~ MT.f
...
]
end
@named act = actuator()
# when making connections we can easily see what like domains are being connected...
eqs = [
connect(act.H_a, pump.H)
connect(mass.MT, act.MT)
] If we decided on a naming scheme now then we can use consistent connector names throughout the Standard Library. Here is my recommended naming, I am in favor of using capital letters for connectors because they are different from variables, it makes it much easier to read.
|
What about |
I think the |
Will stick with |
Closes #109