Open IhorNehrutsa opened 3 years ago
Maybe it's something that's set up wrong with the timer? @xerootg you seem to know the most, did I mess something up in setup?
I do notice that the error seems to increase the more steps. I really think that this is an overflow issue. It's only off by one or two steps over several thousand. Can you reproduce the issue while staying only inside the band of the timer range (0-65555, I think)?
Maybe it's something that's set up wrong with the timer?
I don't see the error. I tried to increase the filter value to 0xff, the error was much. https://github.com/CAP1Sup/Intellistep/blob/3aacf125ba690466871f3f0dcadfef3ee0ec7211/src/hardware/motor.cpp#L30
Can you reproduce the issue while staying only inside the band of the timer range (0-65555, I think)?
Yes, the last three images illustrate the error inside the range 0-65535
Did you try decreasing the filter value? Maybe that would help? Just ping-ponging ideas
The deviation may appear after one revolution of the shaft, but may not appear.
Did you try decreasing the filter value?
Yes, I tried 0 and 1. The same result.
Hmm... we'll have to look into why this is happening. Obviously we can get it to work, BTT did. So the deviation has the possibility of occurring after a full revolution of the shaft?
Try disabling all interrupts besides the step interrupt. Maybe that's the issue
I have commented out the __disable_irq() in timers.cpp
void disableInterrupts() {
// Disable the interrupts if this is the first block
if (interruptBlockCount == 0) {
//__disable_irq();
syncInstructions();
}
I looked at the BTT timer config. It similar to Intellistep. https://github.com/CAP1Sup/Intellistep/blob/master/legacy/Close_loop/src/Hardware/time.c
Hmmm... Is this related to some sort of clock rate issue? It seems unlikely that the hardware clock would loose steps of a clean square wave with the right filter and clock. I'm not doubting that the reported value is wrong, but I tend to trust hardware over polling within loops, otherwise it would be all over the internet that the stm32f1xx can't count. Or maybe checking out if there's a libopencm3 clock implementation notes would help, cause they seem to work around all kinds of strange hardware issues.
On Thu, Aug 12, 2021, 02:48 IhorNehrutsa @.***> wrote:
This PR not for merge. Bad news. I've been doing a series of experiments on the dev branch. The motor speed was constant from the 60-300 rpm range (not as fast as possible). I first used a hardware step counter (#define USE_HARDWARE_STEP_CNT) When I tried to turn the motor 100-500 rpm, I noticed that Err: increases over time. [image: P10811-121824] https://user-images.githubusercontent.com/70886343/129174587-70b4469b-3e0b-4942-8aaf-a2ddfd9e6327.jpg [image: P10811-122301] https://user-images.githubusercontent.com/70886343/129174596-e88eb2ad-b485-42b6-ad96-157ec7062740.jpg [image: P10811-124617] https://user-images.githubusercontent.com/70886343/129174507-5004cae0-df51-409e-a614-4748685a234e.jpg When I used a software step counter, Err: does not increase over time. It was weird. In this PR I modified the source code to compare hard and soft counters. It looks like the hard counter sometimes loses pulses (not every time the generator is run). I was unable to identify a pattern. I think this is not an overflow or a bad form of signals. Here photos after motor stop. The sStp: is software counter, the hStp: is hardware counter. [image: P10812-111117] https://user-images.githubusercontent.com/70886343/129174744-12707993-950b-4dc0-8b89-384604930127.jpg [image: P10812-120128] https://user-images.githubusercontent.com/70886343/129175098-afd0a97a-9063-4ca1-ade0-185e7f46be1b.jpg [image: P10812-124011] https://user-images.githubusercontent.com/70886343/129175555-5f221cf7-341a-4ee0-b7cd-53559669416b.jpg [image: P10812-124027] https://user-images.githubusercontent.com/70886343/129175574-9edc3506-9b1f-4e10-8043-215779a49160.jpg [image: P10812-123936] https://user-images.githubusercontent.com/70886343/129175590-8db74d90-ec47-4221-84c2-f74b50021f02.jpg
You can view, comment on, or merge this pull request online at:
https://github.com/CAP1Sup/Intellistep/pull/101 Commit Summary
- Invert singn of error according to BT
- Update pins.h
- USE_SOFTWARE_STEP_CNT
- middle button on the PCB
- Merge branch 'invert_error' into USE_SOFTWARE_STEP_CNT
- Update motor.cpp
File Changes
- M src/config/config.h https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-392ea7095ea687beffed4eafe26ffab8ef535bceb2dbf01e89f490b4e832d688 (2)
- M src/config/config_adv.h https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-1dcb451c9b0ffdfc2ca9ea6a465535ce7d33ac76f239d1a3745e9e59883a9eda (3)
- M src/config/pins.h https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-a189500100fca9b395a52dfe565fd7542b047d3b6638f40d531c024bf84c910d (6)
- M src/hardware/motor.cpp https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-1bbedad1136ec23a7a794babe3a2bc972b8458656b66f717c8a12da66553a3a7 (48)
- M src/hardware/motor.h https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-f63873c490635ce36db59e90bfe32959237484c8bcd5f7e4e83618c96a3ae4b2 (5)
- M src/hardware/oled.cpp https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-67da48fbd2d783e4332f6d8524a9f8e8b2c2865ce63b08499ee3144c096c9629 (14)
- M src/hardware/timers.cpp https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-eb8cc01938c886fa4eecfd2bfffce0a3da42b5a153f313a54cb14995a8a061d5 (18)
- M src/main/main.cpp https://github.com/CAP1Sup/Intellistep/pull/101/files#diff-bc096c261807d048952d917f83c7d04b1f95d65ce1d8289b06ec20e5ae59c938 (8)
Patch Links:
- https://github.com/CAP1Sup/Intellistep/pull/101.patch
- https://github.com/CAP1Sup/Intellistep/pull/101.diff
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CAP1Sup/Intellistep/pull/101, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6STG4UCM6FLEH6APKUTT4OKIBANCNFSM5CAXYR5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
WTF!!! Now if one of counters is disabled then error will slide towards negative values. When hardware step counter is disabled, then error will slide towards negative values. When software step counter is disabled, then error will slide too. When both step counter is enabled, then error will stable.
#define USE_HARDWARE_STEP_CNT
#define USE_SOFTWARE_STEP_CNT
WTF!!!
WORSE!!! After last commit the error slides towards negative values always.
Maybe try rolling back a couple of commits, starting from there?
I do not see a crime in last commit, it is not large
@CAP1Sup Could you test this on your equipment? It may be a hardware issue.
@CAP1Sup Could you test this on your equipment? It may be a hardware issue.
Unfortunately I cannot, I'm away on vacation. @xerootg could you assist here?
Or maybe @GhostlyCrowd ?
What does setting the NVIC do @IhorNehrutsa ?
My gear is packed up, I'm in the middle of moving. Sorry guys.
On Sat, Aug 14, 2021, 10:13 IhorNehrutsa @.***> wrote:
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CAP1Sup/Intellistep/pull/101#issuecomment-898932122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6SX4MO3JKXAK22C756LT42P5DANCNFSM5CAXYR5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
I knew about what you were doing, I just didn't know why you were setting the priority? What are you trying to adjust?
My gear is packed up, I'm in the middle of moving. Sorry guys.
On Sat, Aug 14, 2021, 10:13 IhorNehrutsa @.***> wrote:
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CAP1Sup/Intellistep/pull/101#issuecomment-898932122, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6SX4MO3JKXAK22C756LT42P5DANCNFSM5CAXYR5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
No problem, no problem at all. Thanks for letting us know. We'll have to get it tested soon. Unfortunately, I'm on vacation now, so we're all fairly occupied for the time being
I think that hardware step counting is definitely the way to go. With my most recent changes, the hardware step counter is almost 100% accurate. I think that there's still work to be done but in general it's looking like hardware step counting is the best option
This PR not for merge. Bad news. I've been doing a series of experiments on the dev branch. The motor speed was constant from the 60-300 rpm range (not as fast as possible). I first used a hardware step counter (#define USE_HARDWARE_STEP_CNT) When I tried to turn the motor 100-500 rpm, I noticed that Err: increases over time. When I used a software step counter, Err: does not increase over time. It was weird. In this PR I modified the source code to compare hard and soft counters. It looks like the hard counter sometimes loses pulses (not every time the generator is run). I was unable to identify a pattern. I think this is not an overflow or a bad form of signals. Here photos after motor stop. The sStp: is software counter, the hStp: is hardware counter.