[autogen] spec (incorrectly?) states that hold_pid/* have read access about ev3dev-lang HOT 8 CLOSED

Sorry for the noise, I did not look at the system names.

from ev3dev-lang.

It turns out the real problem is that the specification states that hold_pid/* properties have read access, but reading the properties results in an error:

cat /sys/class/tacho-motor/motor0/hold_pid/Kp
cat: /sys/class/tacho-motor/motor0/hold_pid/Kp: Operation not supported

from ev3dev-lang.

Don't the docs files that you linked to say that they support both read and write?

from ev3dev-lang.

The docs say so, but the properties are not readable on my ev3. This is probably an error in the driver, so I opened ev3dev/ev3dev#314 as well.

from ev3dev-lang.

If an attribute does not have read or write access, you will get a permission error (-EACCESS I think) rather than an operation not supported error (-EOPNOTSUPP). This is working as indented. Reading and writing the hold_pid parameters for the legoev3-motor driver is not implemented, thus the -EOPNOTSUPP error. When using the ms-nxtmmx driver, these attributes will actually do something.

from ev3dev-lang.

Ok, thanks for the explanation. This means that currently both ev3dev-lang-test.cpp and ev3dev-lang-demo.cpp should be edited manually after autogeneration (as I have done here).

I am thinking of adding a try/catch block to the generated text here and outputting something like 'not supported' when this exception is thrown. @WasabiFan, what do you think?

from ev3dev-lang.

I am thinking of adding a try/catch block to the generated text here and outputting something like 'not supported' when this exception is thrown. @WasabiFan, what do you think?

That sounds like it would not only mitigate the errors, but also provide useful information on the status and usage of the motors, so I'm happy with that plan. Just make sure that the message makes it clear that the error isn't actually a problem.

from ev3dev-lang.

Resolved by #55

from ev3dev-lang.