Skip to content
This repository has been archived by the owner on Nov 3, 2024. It is now read-only.

WIP: soft vs hard CNT #101

Open
wants to merge 13 commits into
base: dev
Choose a base branch
from
Open

WIP: soft vs hard CNT #101

wants to merge 13 commits into from

Conversation

IhorNehrutsa
Copy link

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
Copy link
Owner

CAP1Sup commented Aug 12, 2021

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 CAP1Sup added the bug Something isn't working label Aug 12, 2021
@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 12, 2021 •
edited
Loading

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
Copy link
Author

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.

Intellistep/src/hardware/motor.cpp

Line 30 in 3aacf12

tim2ClkConfig.ClockFilter = 7;

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
Copy link
Owner

CAP1Sup commented Aug 12, 2021

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

@IhorNehrutsa
Copy link
Author

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

@IhorNehrutsa
Copy link
Author

Did you try decreasing the filter value?

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

@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 12, 2021

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
Copy link
Owner

CAP1Sup commented Aug 12, 2021

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

@IhorNehrutsa
Copy link
Author

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
Copy link
Author

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
Copy link

xerootg commented Aug 13, 2021 via email

@IhorNehrutsa
Copy link
Author

IhorNehrutsa commented Aug 13, 2021 •
edited
Loading

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
Copy link
Author

IhorNehrutsa commented Aug 13, 2021 •
edited
Loading

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

@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 13, 2021

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

@IhorNehrutsa
Copy link
Author

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

@IhorNehrutsa
Copy link
Author

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

@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 13, 2021

@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
Copy link
Owner

CAP1Sup commented Aug 13, 2021

Or maybe @GhostlyCrowd ?

@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 14, 2021

What does setting the NVIC do @IhorNehrutsa ?

@IhorNehrutsa
Copy link
Author

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

@xerootg
Copy link

xerootg commented Aug 15, 2021 via email

@CAP1Sup
Copy link
Owner

CAP1Sup commented Aug 15, 2021

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
Copy link
Owner

CAP1Sup commented Aug 15, 2021

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
#101 (comment),
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
Copy link
Owner

CAP1Sup commented Nov 22, 2021

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@IhorNehrutsa @CAP1Sup @xerootg