You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems really inconsistent which of the "mode" attributes get a "modes". Motors get stop_modes, but no run_modes, regulation_modes or position_modes, and Sensors get both mode and modes.
Is there a reason for this? Is it seen that stop_modes is necessary but other "modes" aren't?
The text was updated successfully, but these errors were encountered:
Any omissions were not intentional; were those added recently? Either way, I'll add those properties (and make sure that there aren't any more that I missed) tonight. Thanks for the tip!
linux-source-3.16.1-7-ev3dev (1) testing; urgency=medium
* Add new command and commands attributes to msensor class. This replaces
modes in some cases.
* [rhemel]: Rename dc-motor duty_cycle attribute to duty_cycle_sp and add new
duty_cycle attribute that returns current duty cycle.
linux-source-3.16.1-6-ev3dev (1) testing; urgency=medium
* tacho-motor class device are now named `motor<N>` instead of
`tacho-motor<N>`.
linux-source-3.16.1-5-ev3dev (1) testing; urgency=medium
* [rhempel] Fixed a number of tacho motor bugs
@G33kDude Thanks for the tip on those missing properties. I added them to our JSON spec, so they should show up for our next release once we get the libraries working off of it.
It seems really inconsistent which of the "mode" attributes get a "modes". Motors get
stop_modes
, but norun_modes
,regulation_modes
orposition_modes
, and Sensors get bothmode
andmodes
.Is there a reason for this? Is it seen that
stop_modes
is necessary but other "modes" aren't?The text was updated successfully, but these errors were encountered: