Open nicksauerwein opened 7 years ago
That is indeed a strange behaviour. Given the way the bytes are packed when sending over the bus I cant imagine its an overflow issue on our end... it must be some wraparound behaviour internal to the controller module.
The issue with limiting these input values within the python library is that different TMCM modules have different velocity limits... for example, the TMCM-300 range is indeed limited 0-2047
but the TMCM-100 range can accept values 0-8191
I guess i could add velocity_limit
kwarg to the get_motor
method. Seems a bit of an unsustainable approach in the long run though - until the library becomes opinionated on the module version it is communicating with I feel this range validation is best left to the consuming code.
After re-reading the docs, it seems that the TMCM-100 is the only module that has a different max velocity_limit
... given that, i feel the best approach for the library will be to have an optional kwarg on the Motor constructor to allow overriding the default value of 2047.
That way an assert can be included to avoid accidental motor reversal.
Ok, did you change this?
Not in the public repo yet. I'm working on a full v2 bump that will address this and other issues. Would be obliged if you could test it out when i release an alpha (I haven't got any trinamics to test on at the moment)
Hey,
when I do rotate left, like
motor.rotate_left(num)
wherenum
is in [0,2048] the motor rotates left. If I put in values above that it starts turning right. There seems to be a bug with the bytes. Just add an assert.