Closed va3wam closed 3 years ago
modified my board so that DRV1 fault pin (also known as Vdd due to backwards compatible drivers) now connects to cpu physical pin 5, gpio 26. To enable correct symbol redefinitions, define the symbol avoidEspLed in the line before the huzzah32 include statement. (huzzah file has also been modified.) no longer getting any fault counters. Maybe it's my imagination, but the motors seem smoother.
Will use motor command to do a 10 minute test, then will change Vref to 1.1 to see if I can induce faults. But first I do a git merge, which will include some updates docs.
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
This is some fantastic detective work. You really got to the bottom of the issue and found a solid solution backed up with reproducible tests to prove what was happening. Thanks to you we now know that the voltage settings of the dvr8825 and the use of gpio13 on the Huzzah32 were Causing us problems that made balancing problematic. Very cool. Are you free on Monday during the day to do a zoom session with me to guide me through making the board fixes I need to make? I think I need to do both the red LED fix as well as the motor driver fix to my robots board.
Andrew
On Jan 15, 2021, at 11:43 PM, Doug Elliott VA3DAE notifications@github.com wrote:
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
The detective work was needed due to a problem I caused. Once we decided to go with a two sided board, I should have reviewed all the compromises I made to route on a single sided board, including using GPIO 13. At least I noted in various places that using it was risky.
I'm currently open all day Monday. However, one of my dental caps came off yesterday, and I hope to get in to the dentist quickly after I call him on Monday morning. Suggest we start at 9AM on Monday, since he'll likely book me Monday afternoon at the earliest. I'm working on MQTT messaging and documentation in the meantime. Except on Sunday, when I'm baking chocolate Babka...
[image: image.png]
On Sat, Jan 16, 2021 at 8:56 PM va3wam notifications@github.com wrote:
This is some fantastic detective work. You really got to the bottom of the issue and found a solid solution backed up with reproducible tests to prove what was happening. Thanks to you we now know that the voltage settings of the dvr8825 and the use of gpio13 on the Huzzah32 were Causing us problems that made balancing problematic. Very cool. Are you free on Monday during the day to do a zoom session with me to guide me through making the board fixes I need to make? I think I need to do both the red LED fix as well as the motor driver fix to my robots board.
Andrew
On Jan 15, 2021, at 11:43 PM, Doug Elliott VA3DAE < notifications@github.com> wrote:
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/va3wam/TWIPe/issues/104#issuecomment-761714479, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZJYQ4MPUFFELW4YBYJT3S2I7VNANCNFSM4WE3BWPA .
Sounds great let’s shoot for 9:00am Monday. By the way. I notice that many of your emails to me include a guy named Author, Andrew on the cc line. Not sure if that is on purpose or who that is.
Andrew
On Jan 16, 2021, at 9:19 PM, Doug Elliott VA3DAE notifications@github.com wrote:
The detective work was needed due to a problem I caused. Once we decided to go with a two sided board, I should have reviewed all the compromises I made to route on a single sided board, including using GPIO 13. At least I noted in various places that using it was risky.
I'm currently open all day Monday. However, one of my dental caps came off yesterday, and I hope to get in to the dentist quickly after I call him on Monday morning. Suggest we start at 9AM on Monday, since he'll likely book me Monday afternoon at the earliest. I'm working on MQTT messaging and documentation in the meantime. Except on Sunday, when I'm baking chocolate Babka...
[image: image.png]
- Doug Elliott / VA3DAE / canoe.eh@gmail.com
On Sat, Jan 16, 2021 at 8:56 PM va3wam notifications@github.com wrote:
This is some fantastic detective work. You really got to the bottom of the issue and found a solid solution backed up with reproducible tests to prove what was happening. Thanks to you we now know that the voltage settings of the dvr8825 and the use of gpio13 on the Huzzah32 were Causing us problems that made balancing problematic. Very cool. Are you free on Monday during the day to do a zoom session with me to guide me through making the board fixes I need to make? I think I need to do both the red LED fix as well as the motor driver fix to my robots board.
Andrew
On Jan 15, 2021, at 11:43 PM, Doug Elliott VA3DAE < notifications@github.com> wrote:
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/va3wam/TWIPe/issues/104#issuecomment-761714479, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZJYQ4MPUFFELW4YBYJT3S2I7VNANCNFSM4WE3BWPA .
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I Before I forget about it, I'll send you a link for a Zoom meeting for Monday at 9:00 .
'm not copying "Author, Andrew" intentionally. I wonder if that happens when I reply to an email that is actually coming from Github, rather than from you.
This email is a test case, as I'm replying to a msg which has these addressing fields:
sent by: notifications@github.com
and the reply-to field is va3wam/TWIPe reply@reply.github.com
and the original to field is: va3wam/TWIPe TWIPe@noreply.github.com
and the original CC field is Doug Elliott VA3DAE canoe.eh@gmail.com, Assign assign@noreply.github.com
On Sat, Jan 16, 2021 at 10:17 PM va3wam notifications@github.com wrote:
Sounds great let’s shoot for 9:00am Monday. By the way. I notice that many of your emails to me include a guy named Author, Andrew on the cc line. Not sure if that is on purpose or who that is.
Andrew
On Jan 16, 2021, at 9:19 PM, Doug Elliott VA3DAE < notifications@github.com> wrote:
The detective work was needed due to a problem I caused. Once we decided to go with a two sided board, I should have reviewed all the compromises I made to route on a single sided board, including using GPIO 13. At least I noted in various places that using it was risky.
I'm currently open all day Monday. However, one of my dental caps came off yesterday, and I hope to get in to the dentist quickly after I call him on Monday morning. Suggest we start at 9AM on Monday, since he'll likely book me Monday afternoon at the earliest. I'm working on MQTT messaging and documentation in the meantime. Except on Sunday, when I'm baking chocolate Babka...
[image: image.png]
- Doug Elliott / VA3DAE / canoe.eh@gmail.com
On Sat, Jan 16, 2021 at 8:56 PM va3wam notifications@github.com wrote:
This is some fantastic detective work. You really got to the bottom of the issue and found a solid solution backed up with reproducible tests to prove what was happening. Thanks to you we now know that the voltage settings of the dvr8825 and the use of gpio13 on the Huzzah32 were Causing us problems that made balancing problematic. Very cool. Are you free on Monday during the day to do a zoom session with me to guide me through making the board fixes I need to make? I think I need to do both the red LED fix as well as the motor driver fix to my robots board.
Andrew
On Jan 15, 2021, at 11:43 PM, Doug Elliott VA3DAE < notifications@github.com> wrote:
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/va3wam/TWIPe/issues/104#issuecomment-761714479, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACOZJYQ4MPUFFELW4YBYJT3S2I7VNANCNFSM4WE3BWPA
.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/va3wam/TWIPe/issues/104#issuecomment-761724103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZJYVT7ZYWDHSV5VJYQDLS2JJDRANCNFSM4WE3BWPA .
I looked up the GPIO13 pin and here is what is says...
13 - This is GPIO #13 and also an analog input A12 on ADC #2. It's also connected to the red LED next to the USB port
My memory recalled the bit about next to the USB port and I muddled that into thinking it was doing some USB stuff, which is wrong. So I cannot see what using this Pin does that could cause us grief. Clearly it does, I just wish I knew why!
Andrew
On Jan 16, 2021, at 9:19 PM, Doug Elliott VA3DAE notifications@github.com wrote:
The detective work was needed due to a problem I caused. Once we decided to go with a two sided board, I should have reviewed all the compromises I made to route on a single sided board, including using GPIO 13. At least I noted in various places that using it was risky.
I'm currently open all day Monday. However, one of my dental caps came off yesterday, and I hope to get in to the dentist quickly after I call him on Monday morning. Suggest we start at 9AM on Monday, since he'll likely book me Monday afternoon at the earliest. I'm working on MQTT messaging and documentation in the meantime. Except on Sunday, when I'm baking chocolate Babka...
[image: image.png]
- Doug Elliott / VA3DAE / canoe.eh@gmail.com
On Sat, Jan 16, 2021 at 8:56 PM va3wam notifications@github.com wrote:
This is some fantastic detective work. You really got to the bottom of the issue and found a solid solution backed up with reproducible tests to prove what was happening. Thanks to you we now know that the voltage settings of the dvr8825 and the use of gpio13 on the Huzzah32 were Causing us problems that made balancing problematic. Very cool. Are you free on Monday during the day to do a zoom session with me to guide me through making the board fixes I need to make? I think I need to do both the red LED fix as well as the motor driver fix to my robots board.
Andrew
On Jan 15, 2021, at 11:43 PM, Doug Elliott VA3DAE < notifications@github.com> wrote:
ran following tests, with DRV1 fault on gpio26, and Vref = 0.85 15 min, both motors at 300 10 min, both motors at 250 10 min, both motors at 200
no hiccups, no fault counts displayed, and motors barely got warm
changed Vref to 1.1 on both DRV's ran both motors at 300, and first one, then a minute later the second started stuttering with corresponding increments to fault counters. neither one made it to 4 minute mark. I think this proves our fault counters are now working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/va3wam/TWIPe/issues/104#issuecomment-761714479, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOZJYQ4MPUFFELW4YBYJT3S2I7VNANCNFSM4WE3BWPA .
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
The right side DRV fault counter seems to increment whenever there is activity on either motor. I've verified Vref is 0.85 on both DRV's, swapped them and get same result: faults being counted for the right side DRV when either motor is activated. Need to verify the associations between DRV 1 & 2, left and right, and physical and GPIO pin numbers used for fault interrupts.
From circuit board silkscreen info, and continuity testing on the board:
DRV2 is the one closest to a corner of the circuit board DRV2 connects to the motor on TWIPe's left (same as amber pushbutton) (above are correctly documented in SB7D-stepper-wiring.odg) DRV2's fault pin connects to GPIO pin 32, physical pin 20 on the CPU DRV1's fault pin connects to GPIO pin 13, physical pin 25 on the CPU (above is correct in huzzah32_pins.h) (I've added more info to sb7D-pinouts-CPU.ods) reviewing the source code
the gp_DRV2_FAULT gpio pin is attached to the leftDRV8825fault ISR, which is correct that ISR correctly increments health.leftDRVfault above is correct for the DRV1 / right as well the right eye display routine (actually in updateLED() ) outputs 3 numbers on the 4th line, separated by stars: percent time in MQTT routines, health.leftDRVfault, health.rightDRVfault it's the last number that's incrementing, i.e. the one for DRV1, right side, GPIO pin 13, physical pin 25 So, the faults don't follow the physical DRV chip, but are always reported for DRV1. I don't see any software bugs that would cause incorrect fault counting. Thus I turn to hardware causes, and I see notations in several places that using GPIO 13 may conflict in some way with the onboard LED. I think 13 was used due to circuit board layout constraints before we started using a double-sided layout.
I'll investigate possible board mods to move the DRV1 fault line to a different CPU pin. Candidates are: GPIO 26, physical 5 GPIO 34, physical 7 (input only pin, but that's OK) GPIO 36, physical 9 (input only pin, but that's OK)