CAP1Sup / Intellistep

A rework of the terribly coded firmware from the BTT S42B v2 boards
GNU General Public License v3.0
45 stars 10 forks source link

WIP: soft vs hard CNT #101

Open IhorNehrutsa opened 3 years ago

IhorNehrutsa commented 3 years ago

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. P10811-121824 P10811-122301 P10811-124617 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. P10812-111117 P10812-120128 P10812-124011 P10812-124027 P10812-123936

CAP1Sup commented 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?

CAP1Sup commented 3 years ago

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)?

IhorNehrutsa commented 3 years ago

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

CAP1Sup commented 3 years ago

Did you try decreasing the filter value? Maybe that would help? Just ping-ponging ideas

IhorNehrutsa commented 3 years ago

The deviation may appear after one revolution of the shaft, but may not appear.

IhorNehrutsa commented 3 years ago

Did you try decreasing the filter value?

Yes, I tried 0 and 1. The same result.

CAP1Sup commented 3 years ago

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?

CAP1Sup commented 3 years ago

Try disabling all interrupts besides the step interrupt. Maybe that's the issue

IhorNehrutsa commented 3 years ago

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();
    }
IhorNehrutsa commented 3 years ago

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

xerootg commented 3 years ago

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

Patch Links:

— 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 .

IhorNehrutsa commented 3 years ago

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!!!

IhorNehrutsa commented 3 years ago

WORSE!!! After last commit the error slides towards negative values always.

CAP1Sup commented 3 years ago

Maybe try rolling back a couple of commits, starting from there?

IhorNehrutsa commented 3 years ago

I do not see a crime in last commit, it is not large

IhorNehrutsa commented 3 years ago

@CAP1Sup Could you test this on your equipment? It may be a hardware issue.

CAP1Sup commented 3 years ago

@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?

CAP1Sup commented 3 years ago

Or maybe @GhostlyCrowd ?

CAP1Sup commented 3 years ago

What does setting the NVIC do @IhorNehrutsa ?

IhorNehrutsa commented 3 years ago

https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities

xerootg commented 3 years ago

My gear is packed up, I'm in the middle of moving. Sorry guys.

On Sat, Aug 14, 2021, 10:13 IhorNehrutsa @.***> wrote:

https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities

— 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 .

CAP1Sup commented 3 years ago

https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities

I knew about what you were doing, I just didn't know why you were setting the priority? What are you trying to adjust?

CAP1Sup commented 3 years ago

My gear is packed up, I'm in the middle of moving. Sorry guys.

On Sat, Aug 14, 2021, 10:13 IhorNehrutsa @.***> wrote:

https://community.arm.com/developer/ip-products/system/b/embedded-blog/posts/cutting-through-the-confusion-with-arm-cortex-m-interrupt-priorities

— 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

CAP1Sup commented 2 years ago

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