Minor missed counts using the hardware step counter

[CAP1Sup]

Just as the title says, there is minor drift with the hardware step counter. Ever so often, not frequently, it will lose a step or gain one (typically lose one). It's not that major on short prints, but over time the error could build. This is obviously the highest priority to fix. @IhorNehrutsa do you have any suggestions for how to fix this? I think that we're getting really close to being able to have a viable firmware, albeit without step correction during the first release, but better, more consistent movement and overall better user experience.

[CAP1Sup]

From my testing today:

• Counts are always missed. There are never extra (like a double count on pulse)
• Using the step pin as an INPUT_PULLDOWN seems to reduce the counting errors significantly
• Tried tuning the IC1 (step pin) filter, but unsuccessful at improving counting. Extreme values (closer to limits) do worse job of counting.

[CAP1Sup]

BTT used the STEP pin as an interrupt and an external clock source, then processed the counting direction in the interrupt by reading the DIR pin and setting the counter's direction. I have implemented the same exact thing, just with newer functions (the old don't exist in this project, everything is configured exactly the same). I still didn't have any luck.

[CAP1Sup]

I also checked if the timer was being affected by the 128MHz overclock, both theoretically and realistically. Even though the HCLK (main clock) is at 128MHz when it should be max 72MHz, the AHB1 clock (feeds timer 2, the one used for counting) is scaled with a prescalar of 4. It's clock is 32MHz, which is under the rated 36MHz max. No clear improvements, so the issue is likely not caused by the clock speed.

[CAP1Sup]

I ran a print last night with Intellistep S42V2s and there's still some minor shifting. It's not really anything major, but you can see it on the part surface, which is unacceptable. I'm going to take a look at https://github.com/makerbase-mks/MKS-SERVO42B/tree/master/firmware/src/BSP over the weekend. Hopefully that should have some better clues than the BTT code as to how to best count steps.

[CAP1Sup]

I was thinking about the minor shifting and realized that it's probably due to unprocessed interrupts. When the encoder is being read, the motor can't be updated. Therefore, the "step" is still counted by the hardware counter, but the motor itself isn't moved. Therefore, the current "open loop" code needs to be re-written so that all step commands are respected. This can be done by counting the number of steps moved in software and running a correctional loop if the software count doesn't match the hardware count. This should eliminate a large amount of the layer shift as the hardware counter only has very very minor losses, not like those observed in the part.

[CAP1Sup]

I wrote the code that should handle the actual vs handled step correction using the old softStepCNT. I completely stripped the concept of soft counting as a method of input step counting. The hardware version is not only better but more efficient and easier to use. I repurposed the step correction timer so that any unhandled steps are automatically processed. How that will eventually fit in encoder based skipped steps detection and correction is not really a concern right now, although it's going to need a check over later. I'm not commiting today, as I need to check if the code works on a board and don't have testing time tonight. I will try to fix the issue with unhandled steps this weekend, although no promises. Once that is done, Intellistep will at least be viable and I can start to focus on features such as the encoder skipped steps correction and dynamic current that will eventually push the project to be better than BTT's original code.

[CAP1Sup]

Commit 85af1ff implements the changes previously discussed. Now I only need to fix the missed step counts yet. Release 0.1.0 should be coming soon!

[CAP1Sup]

Missed steps still occurring, even with the MKS setup implemented in 37e736f. Original encoder setup is still better, so it's still the default.

[xerootg]

So your saying that even the positional correction implementation is leading to missed steps?

…

On Sat, Dec 11, 2021, 17:27 Christian Piper ***@***.***> wrote: Missed steps still occurring, even with the MKS setup implemented in 37e736f <37e736f>. Original encoder setup is still better, so it's still the default. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6S6STNNW5JUZCKRNEPM5TUQPT7XANCNFSM5IP2M4CA> . 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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[CAP1Sup]

So your saying that even the positional correction implementation is
leading to missed steps?

On Sat, Dec 11, 2021, 17:27 Christian Piper @.***>
wrote:

Missed steps still occurring, even with the MKS setup implemented in
37e736f
37e736f.
Original encoder setup is still better, so it's still the default.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#111 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA6S6STNNW5JUZCKRNEPM5TUQPT7XANCNFSM5IP2M4CA
.
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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Very rarely, the step pulses aren't being counted by the hardware timer. I know that it's miscounting because I have my testing setup configured so that it's set with 80 steps/mm. Occasionally the step count on the board will be wrong with what it should be according to the mainboard.

[xerootg]

Hmmm... I wonder if there's something in the lovely interrupt documentation about how to detect missed interrupts, it would be interesting to see if this missed step is still in code, or maybe something we could atleast detect. On Sat, Dec 11, 2021, 18:53 Christian Piper ***@***.***> wrote:

…

So your saying that even the positional correction implementation is leading to missed steps? On Sat, Dec 11, 2021, 17:27 Christian Piper *@*.***> wrote: Missed steps still occurring, even with the MKS setup implemented in 37e736f <37e736f> 37e736f <37e736f> . Original encoder setup is still better, so it's still the default. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub #111 (comment) <#111 (comment)> , or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6S6STNNW5JUZCKRNEPM5TUQPT7XANCNFSM5IP2M4CA . 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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . Very rarely, the step pulses aren't being counted by the hardware timer. I know that it's miscounting because I have my testing setup configured so that it's set with 80 steps/mm. Occasionally the step count on the board will be wrong with what it should be according to the mainboard. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6S6SQAPCHXCRNPIUT3DRDUQP6CPANCNFSM5IP2M4CA> . 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&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[CAP1Sup]

I don't know if there is a way to detect it. I've tried adjusting the clock filter, but I haven't really seen consistent behavior. And as for documentation... it's really bad for the encoder mode. I don't even think that the encoder mode was originally ever thought of for this use case anyway. All that I know at this point is that there's still missed steps, which is the last thing holding back the basic functionality of the board. After the issue of missed steps is resolved, the boards will be fully functional, just like an A4988 or similar stepper chip. Then I can start to work on more complicated features that would really make this board worthwhile. It's really frustrating that there's so little documentation on this board and it's respective functions. It's also really nice how there's around 3 different versions of the library and most tutorials don't use the one Arduino uses. Anyways, like I said, I really want to get this resolved ASAP so that I can release 0.1.0 and begin work on skipped step detection. If you have any ideas please let me know, I've kinda hit a roadblock here and I've been avoiding it for the time being by fixing other issues, such as the enabling, but now it's the last major issue remaining. Thanks for you interest in the project!

[IhorNehrutsa]

Have you tried looking at the oscilloscope for the STEP(STP_IN) waveform before and after U3 (pin2 and pin6)? Are your motherboard to driver cables too long?

[CAP1Sup]

I don't think that my motherboard cables are too long. I'm using the ones that BTT provides and they're away from anything that could introduce interference. I unfortunately don't have an oscilloscope, so I have no way of measuring to check if the correct step pulses are going out. Considering that I'm using Marlin on the test mainboard, I think that the stepper board is likely the issue.

[CAP1Sup]

I think that removing the overclock fixes the counting issues. I need to confirm this with testing, but as discussed in PR #113, reducing the SYSCLK_FREQ from its default 128 to 72 (the spec of the processor) seems to fix the counting issues. More comments later

[CAP1Sup]

Well.. it does seem as though reducing the clock frequency down does help to reduce miscounts. The problem still exists, although I think that it might be small enough to be neglected in the overall scheme of things. I will leave this issue open as it's still a problem. Hopefully with the 0.1.0 release the interest will draw enough attention so that someone is able to figure out how to fix the miscounting issue.