Quick speed changes lead to loss of step generation

[akunadze]

First off, thank you for creating this wonderful project (and also for inadvertently introducing me to the Blue Pill!). I've been playing around with it for the past week or so and already I'm making plans to put it on my lathe with some simplified controls.

However, today I've discovered what could be a problem with step generation. I don't have the constant speed setup you've shown in the video, so I'm basically turning the encoder by hand when testing, turn-stop-turn-stop etc. If I do that cycle in rapid order, eventually the controller stops generating steps. Debugging the code revealed that TIM1 IRQ routine somehow detects change in direction (even though all the turns have been in the same direction). enc = 65534, range.next.count = 2 Unfortunately I'm new to debugging blue pill and I can't get it to break in that function for the second time (there's probably been another interrupt while I was in there). Pressing reset button doesn't bring it back to life, only power cycle.

At first glance it seems like it should not happen in real life, motors don't jiggle like that, but then I thought of a lathe operator jiggling the chuck with the power off, and suddenly it doesn't seem all that impossible.

Anyway, I hope you can find the reason for this. If I can help in any way, please let me know. I'm new to the microcontroller world, but I've been writing code for over 20 years now, so perhaps I can help with this project.

[prototypicall]

Thanks for the nice words. I am glad you found it useful. I just noticed this as Gmail decided to put the update under promotions and I just happened to check it.

Thanks for pointing this issue. I did a quick look and indeed I see a potential issue that I will prepare a fix for shortly. This may not be the cause of the issue but I see the potential that the encoder value might have gone one past the expected value due the latency of interrupt handling. The better way is to check the interrupt source to determine if there is a direction change.

For the reset issue, I am puzzled. Can you explain your setup? A picture would do.

[akunadze]

NW, I was not expecting instant response, if any at all. It's a hobby after all and I'm thankful for any support you're willing to provide.

Unfortunately I tore down the setup, but it was pretty simple. 5v from external USB going to the board, Nextion and encoder. Encoder A and B to pins A8 and A9. Nextion TX/RX to pins B6/B7. LED/resistor to B0 to see the step pulses.

I was a bit puzzled as to what was supposed to go A1 (3v only!) and A10, and where encoder index should be (if anywhere), so I left them unconnected.

I'm a little hazy on how reset button works, but I was very puzzled to see that it didn't seem to reset the board fully. Init code got executed, evidenced by the screen resetting, but step gen was still out of commission. Maybe

I'll try to recreate it and capture a small video of the setup and the problem, should make it more understandable. I'll add a link when I get it sorted out.

[prototypicall]

Thanks for the info. I just wanted rule out any possible wiring issues. I am glad I did because it is not mentioned anywhere but A10 should be connected to A1. This is for the smoothing operation - to measure the time between pulses. Sorry about that. This is probably the reason for the issue you are seeing. We don't need the encoder index signal so it can be left unconnected.

Please also note that the external 5K pullup resistors are highly recommended for electrical interference immunity. I did try and indeed get noisy signals (observed on the logic analyzer).

Re reset: Now that makes sense. I think what happened is that stepper motor is stalled so the driver could not move it. I think it might be a good idea to add a motor enable disable capability.

By the way I actually created myself some time to work on this project. I have created a dev branch just now :) I am intending to eliminate the Nextion display and actually switch to a new microcontroller as the Blue Pill boards with genuine STM32 chips are hard to get by now.

On the side I also want to create a fork of the Kvasir with a smaller scope but with the intent to generate a complete "board package" from the SVD files. If you are interested and have some time to spare, let me know.

Edit: Before the current motor driven encoder setup in the video I tested turning the encoder by hand as well. Quickly turning encoder back and forth you can indeed exceed the acceleration capability of the stepper if you go very quickly. In my case I had to really try.

[akunadze]

Thanks for clarifying A0-A10 connection, it makes sense now. I've connected it that way and also added 10K pull-up resistors to the encoder inputs. With all that done, it seems like it's harder to get it into the funk state, but still possible. To be clear, I don't have the actual stepper driver connected, just an LED on the step pulse pin, so stepper acceleration doesn't come into play here.

Here're two clips illustrating the problem. The first test I start fairly gently and it takes a while for the problem to surface. The second test I spin it pretty hard right after resetting the board, and it takes only two spins to put it into funk. It seems some init code is making it slow to warm up. https://youtu.be/uOj7SO3zULA https://youtu.be/uOj7SO3zULA

Re: reset issue. Reset works fine now, no idea what changed.

Re: Kvasir I'm probably not the best person to take part in this as I don't particularly like template-based coding. I'm more of an old-school class/object kinda guy :) Kvasir looked interesting at first, but then I tried to fool around with adding UI to your code and quickly got frustrated. It's just not natural to me to pass things like pin assignments as template params. I realize it is probably more efficient, especially in the embedded world, but still... I was actually toying around with the idea of porting Didge to Cube or maybe modm, but both of those seem to have their issues too. If you know of any other C++ HAL libs worth looking at I'd appreciate a pointer.

I'd be happy to help with Didge though as it is more application-centric project, so just let me know if you have any specific tasks you'd like to offload. Otherwise I'll continue to play around with it and hopefully get it actually installed on my lathe.

Actually, speaking of installing, there's one more setting that needs to be added. My lathe (10x27 Weiss clone) has a separate lever for feeding the tool vs. threading. It uses the same lead screw, but adds even more gearing in the apron. It's a pretty common setup, so there should probably be an extra setting to account for the different ratio and a UI way to switch between threading and feeding.

And lastly (this is getting long) I agree about the Blue Pills. When I ordered mine I got a 411 Black Pill as well and just started fiddling with it. Seems much more refined (not to mention faster). All the pins but two are 5v tolerant, extra timers, etc. Costs CAD10 here vs. CAD5 for the blue, still dirt cheap. Blue Pills I got seem real though, so I'm sure I'll find a use for them. Either one is light years ahead of Arduino which I've started with.

[prototypicall]

Thanks for the video (I think the second link is the same video ;p). They are not fast at all (compared to what I mention exceeding the stepper acceleration limits). That is not normal. I think you may indeed be hitting the issue I mentioned in my first reply. I've updated two files in the dev branch to address that. Please give that a shot. I was not able to test it (I did not bring the setup back together yet) but I am hoping it's not gonna break anything more :)

Please also note that most of the low cost encoders have a regulator in them that has some voltage dropout so they need to be ideally fed with 6-7 Volts. Power coming from the ST-Link is not really enough to operate them.

Re: Re: Kvasir I hear you about template metaprogramming stuff. It's ugly but it is quite powerful. Starting with C++20, things are changing for the better (i.e. you don't need to use the template syntax). It's going to be a long transition but C++2x is going to like a new language (think Python). Thanks for the feedback.

It's actually quite possible to create APIs like the digitalWrite(), etc which still use this compile time stuff to do the right bit operations and do them efficiently. I had a quick look at modm more than a year ago and was not satisfied at the time. Can't recommend anything else right now.

For Didge, yes I am indeed thinking about the STM32F4x1 for the next release for the reasons you mentioned. Yep, there's still room for the Blue Pills, also because there's code out there to use its USB. The F4s have a different USB device.

I've noted the on-the-fly gear configuration change feature. If you have any thoughts, suggestions about the UI that would be great as well.

[akunadze]

Sorry for the delay, been a crazy couple of days. Thanks for fixing it so quickly, I cannot make it crap out now! Feels rock solid now!

I've also hooked up an actual stepper to it. Seems to work well, although the driver specifies 5V, while STM32 outputs 3.3v. The pins are not even 5V-tolerant. How did you hook it up? I'm afraid noise would be an issue without a level converter of some kind. Would an open drain/pull up resistor work here? In fact, would it be possible to publish a reference schematic?

Also, when I first hooked it up it didn't work at all. It took some hunting to realize that the default ratio selected is 1:1, which resulted in harsh acceleration and a stall (I'm using closed-loop stepper, so the driver threw an alarm as well).

Re: UI I'm thinking of a similar interface to what Clough42 did, but with the addition of a rotary encoder to select threads/feeds quickly. Ideally I'd also like to replace the buttons with something more tactile, perhaps tumblers or substantial two-position switches. My reasoning is that when you actually use the thing at the lathe you want simple controls that you can operate mostly by touch, without having to look at the panel. This is especially true for feeds, as I tend to change them while observing the result on the cut. Changing threads should really be allowed only when the spindle is stopped. I don't think there's a use case for changing them mid-cut. Feeds are a different matter, but then they're not so fussy about spindle synchronization.

[akunadze]

One more question: is timer4 actually used for something? I found only one-line init for it in step gen code and assumed it was a left-over from an old experiment, but maybe I'm missing something?

[prototypicall]

Thanks for the update and I am glad it's working now.

The stepper driver I am using is OK with 3.3V logic outputs (and I am not using any inputs at the moment). Let me know which stepper driver you are hooking up and I can provide suggestions.

Yep the default ratio is set to 1:1 for the "finger test" :). Do you have the screen? It should be showing that.

Thanks for UI input. I agree on the thread chance and check mark on the rotary encoder for feed and also for UI navigation. For the buttons I think mechanical keyboard switches might a good option as there are various tactile options available. It's also possible to 3D print custom keycaps with different geometries. Food for thought.

I also want to have an analog device for variable speed the jogging (not implemented yet) and possibly UI navigation. Bought some joystick modules to start.

Re Timer4: Yep it probably is left there by accident as I moved pins around, thanks for noticing that.

[akunadze]

Driver is 2HSS57, one of those new driver/motor closed-loop combos. It's been working fine so far, but I've ordered a level shifter just to be safe.

I've implemented some basic UI with 8x 7seg LEDs and a rotary encoder knob. Works great and I've been able to try out the full range of threads with the stepper. It was doing find up until it got to 4tpi. There the drive locks up. I think it's probably too much acceleration. 6tpi is a little better, but it really doesn't like quick direction changes, again probably because it has to catch up after the pause in steps. I'm at 8 micro-steps so I don't think it's hitting the algorithm limits.

Jogging sounds interesting. I've heard of a few people trying to implement it. Looking forward to it!

[jayl85]

Hi, first I barely code and there is nothing I can contribute programming wise, but you asked about UI decisions and general input. I was looking at AtomicELS by Jon Bryan for some time as he has built an easy to understand ELS using an Arduino Mega 2560 and also a Nextion display. The thing wich is holding me back is first the nextion display and second that he built it for his particullar lathe. It works with other lathes, but some UI parts are with his lathe in mind. His code is very well documented and he thought about some extras like a warning, if a given pitch would exceed the steppers capability. I think it would be worth having a look at his project at ELS-Jon. (It's not properly set up, so you have to dowload the "AtomicELS_V1.zip" to get the code)

As you use a more powerful board, wouldn't it be possible to drop the nextion and just use a generic resistive touchscreen?

[prototypicall]

Driver is 2HSS57, one of those new driver/motor closed-loop combos. It's been working fine so far, but I've ordered a level shifter just to be safe.

Glad it's working for now. I will switch the timers to make sure that the step and dir pins are 5V tolerant ones for the final release.

I've implemented some basic UI with 8x 7seg LEDs and a rotary encoder knob. Works great and I've been able to try out the full range of threads with the stepper. It was doing find up until it got to 4tpi. There the drive locks up. I think it's probably too much acceleration. 6tpi is a little better, but it really doesn't like quick direction changes, again probably because it has to catch up after the pause in steps. I'm at 8 micro-steps so I don't think it's hitting the algorithm limits.

Please take a look at the verify_thread function in configuration.hpp. It checks if the thread is too small or too large for the current configuration. Current implementation is just taking an index to the thread list array but can be simply changed to check any arbitrary thread.

Jogging sounds interesting. I've heard of a few people trying to implement it. Looking forward to it!

Thanks.

[prototypicall]

Hi, first I barely code and there is nothing I can contribute programming wise, but you asked about UI decisions and general input. I was looking at AtomicELS by Jon Bryan for some time as he has built an easy to understand ELS using an Arduino Mega 2560 and also a Nextion display. The thing wich is holding me back is first the nextion display and second that he built it for his particullar lathe. It works with other lathes, but some UI parts are with his lathe in mind. His code is very well documented and he thought about some extras like a warning, if a given pitch would exceed the steppers capability. I think it would be worth having a look at his project at ELS-Jon. (It's not properly set up, so you have to dowload the "AtomicELS_V1.zip" to get the code)

As you use a more powerful board, wouldn't it be possible to drop the nextion and just use a generic resistive touchscreen?

Thanks for the input. My intention is to also eliminate the Nextion display but the GUI libraries use lots of flash memory which the Blue Pill does not have. So I will probably switch to a new board that has more flash available as discussed in earlier comments.