Closed camieac closed 8 years ago
And it is probably worth setting a limit on the number of read/write attempts, rather than looping until succesful.
If you are just looping until successful then that is why 0x73 is the only one erroring. If I remember rightly doesn't i2c REQUIRE a delay?
On Mon, Jan 11, 2016 at 6:27 PM, Cameron Craig notifications@github.com wrote:
And it is probably worth setting a limit on the number of read/write attempts, rather than looping until succesful.
— Reply to this email directly or view it on GitHub https://github.com/IonSystems/tiberius-robot/issues/22#issuecomment-170643084 .
I would make a module that extends the smbus library, then you can put in delays easily between each transaction
Yeah you're right about why it's only 0x73. Feel free to have a look at this with me tomorrow.
Shouldn't need delays (it has worked fine without them previously) , after closer inspection of the commit referenced above (9bb996b), there were never any delays. If anything the changes made have increased the delays ever so slightly.
The issue with the motors not stopping was caused by two of the motor drivers having an old firmware version (v7 rather than v15). The old firmware dealt with the direction register slightly differently, causing the weird issue. This has been fixed in Tiberius Junior (the one with all the broken axles), by replacing the old motor drivers with new ones.
We may run into this issue again if the old motor drivers need to be used on Tiberus III. But we will cross that bridge when we come to it. I have added some support functions (92d7cad46c45ffe5c5255881e654999540fea69d) to make it easy to deal with the old drivers when it comes to it.
Finding the root of the ultrasonics errors is next on the list.
I noticed an unmanageable amount of I2C errors tonight, while testing the control software. I think this is something to do with commit 9bb996b when I may have removed some important delays.
I will test on another installation at some point and see if there is still a problem.
Errors in logging:
I am also wandering why only device 0x73 is giving an error, this could show a hardware issue.