Automatic stop with limit switch

[t3kboi]

Turning to a shoulder confidently will be awesome!

Automatic Stop idea -

If we add a GPIO input to a touchprobe on a magnetic base - we might be able to set an automatic stop when the singlepoint enters the relief at the end of the thread.

• Connect probe (3.5mm audio jack)

  • Enable probe in UI - verify probe with touch led.

• Magnetic base on probe

  • Set probe on ways, touching the lathe carriage after manually driven to the proper location.

Concerns -

• Tip of probe should be lightly sprung to prevent damage when the carriage contacts the probe.
• Magnet/arm on probe needs to be rigid - but a mini-noga arm may be rigid enough, and widely available at low cost.

[clough42]

I changed the title to better reflect what I think this is.

I've thought about this quite a bit, and I think there are two variants:

1. Set a physical stop switch to prevent collisions
2. Automatically feed to a digitally-set stop point

Both introduce the difficulty of resynchronizing the leadscrew for subsequent passes. This is relatively easy if the halfnut stays engaged, but becomes much more difficult and requires additional inputs if you want to unlock the halfnut and rewind for subsequent threading passes.

[wrljet]

I know you're not interested in turning this into a CNC project, but one approach, of course, is to stop the spindle with braking.

[t3kboi]

I completely forgot about disengaging the half nuts! You are right - this opens a larger can of worms.

[gusosborne]

I really like this idea! - but unless I’m missing something obvious.. I would think the only logical thing would be to use a stop switch (or whatever trigger), which simply freezes turning of the leadscrew. This would just stop the cutter in (or create) a relief / gutter.

Retract, disengage and do your manual business- then hit a button to reset the state of the lead screw (back to feeding) and resume normal (manual) operations. I don’t believe it should be up to the ELS to keep track of the lead screw’s relative position (unless there was a second encoder on the lead screw, which I would love to do eventually). I see the issue with metric threads on a standard leadscrew, but this is nothing new to us.

This project is meant primarily to replace the gearbox after all. Keeping it simple and robust will set it apart from all of the others. Am I missing something? Thoughts..?

[clough42]

@gusosborne The only job of the ELS is to maintain the relative position of the leadscrew with the spindle. Any operation that involves stopping the leadscrew (independent of the spindle) will require somehow reestablishing this synchronization before further cutting. If you leave the leadscrew locked (i.e. hybrid threads) the position must be exact, with no lost rotations. For threads that allow unlocking the halfnuts, it is necessary to recover some of the lost rotations, depending on the thread being cut, the pitch of the screw and the number of teeth on the threading dial. The ELS probably has enough information to solve for this, but it's pretty complex.

[gusosborne]

Ok, sorry- I should have been more specific. I meant maintaining the relative position with regards to cutting metric threads on a standard lead screw (or vice versa). I do believe I am trying to say the same thing you are - keeping up with that would be nuts (but probably possible, especially with an encoder on the lead screw). Does that make more sense now?

My main point is: What’s the problem with just using the threading dial, like we already do?

[t3kboi]

There is another very valuable use case though, that has nothing to do with threading - which would be automatically turning to a shoulder, and then stopping.

The ELS still gives a much finer control over the feed rate, without using change gears.

[gusosborne]

There is another very valuable use case though, that has nothing to do with threading - which would be automatically turning to a shoulder, and then stopping.

The ELS still gives a much finer control over the feed rate, without using change gears.

Exactly! But why would the two cases need to be treated any differently, when using a threading dial?

[gusosborne]

Wait- uh oh, I think it just hit me..:( There does need to be a complete synchronization between spindle and leadscrew, irrespective of the threading dial. Sorry about that - feel pretty stupid now.

[gusosborne]

So I may just delete my previous comments if no objections in the next few seconds..:/

Question tho- how would one keep track of this without a servo, or an encoder on the leadscrew? Just take the steppers “word” for how many steps / rotations it’s made, and hope for no missed steps?

Again, I apologize for wasting everyone’s time with such a rudimentary misunderstanding.

[clough42]

No need to delete comments. It's always good to leave a trail for other people who might have the same confusion. This stuff is really subtle sometimes.

With a stepper, the microcontroller counts off the steps as it pulses the driver and assumes everything went to plan. (open loop)

A "real" servo uses a DC motor or a 3-phase brushless motor (often with gears) and an encoder. The software in the driver controls the motor power to drive to the desired encoder position. (closed loop)

In the case of the hybrid servo I'm using, it's really a stepper motor with an encoder added on and managed by the driver. The microcontroller treats it just like a stepper, except that there's a feedback wire for the driver to tell the microcontroller to panic if it can't keep up.

It would also be possible to add an encoder to the leadscrew and manage the stepper (or even a DC motor) myself. I decided against it just to make things simpler.

[gadjet]

What about when it's used for just power feed, not threading? an electronic stop or programmable distance would be useful, I would imagine the stop would be easier to implement maybe using the alarm input?

[clough42]

The stop would be much easier to implement for feeding only, since synchronization wouldn't be an issue. It would just be a matter of stopping the screw when the switch is triggered. I'll have to think about what might make sense in the code.

[gadjet]

Thanks, my idea is to have an inductive sensor like on a 3D printer on a adjustable mount to set to a fixed cut length or just as an emergency cutout just before the chuck.

[clough42]

Ahh...this should be possible, and the alarm input would be a reasonable place to do it.

The board is designed for an opto-isolated output from the servo driver connected between ALM+ and ALM-. In reality, though, ALM- is connected to logic ground and ALM+ is a open-collector input with a 10K pullup to 3V3. So I think you could connect the output of an NPN proximity sensor between ALM+ and ground (ALM-). If you configure the alarm output of your driver to switch ON during an alarm condition, it could be connected in parallel across the same pins and either would trigger the alarm condition.

It might be useful to reduce the value of R10 to increase the current in the loop, depending. 4K7, 2K2 or even 1K might be appropriate, depending how much current you need. Just don't drive anything above 3V3 into the ALM+ pin.

If the proximity sensor is ON when not sensing, you would put it in series with the servo output, configured for active-low triggering and reverse the pin logic in Configuration.h. Either way, you should be able to make it work.

Note that at this very moment, the alarm input doesn't do anything, but it will stop all step output and put a message on the display when I get around to coding it.

James

On Thu, Sep 26, 2019 at 3:38 PM Phil Grant notifications@github.com wrote:

Thanks, my idea is to have an inductive sensor like on a 3D printer on a adjustable mount to set to a fixed cut length or just as an emergency cutout just before the chuck.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/clough42/electronic-leadscrew/issues/10?email_source=notifications&email_token=AAZLSHF5ODBXX5NUXU3L7U3QLUTVLA5CNFSM4IOYPO5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7XBFTI#issuecomment-535696077, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZLSHDHN2TGOFBPUYOWAMDQLUTVLANCNFSM4IOYPO5A .

[gadjet]

Sounds great :-)

[vk7krj]

If the spindle encoder was of the type that had an indexing pulse., perhaps you could set up for the start of threading, but with the leadscrew motor not running, engage the half-nut, then press a button on the controller and the software waits for the next indexing pulse then starts the stepper to start cutting. Each time an indexing pulse comes round, save the number of steps. When the limit is tripped, the software stops the stepper, and saves the steps, You wind out the cross slide, push the button again, the software winds back the leadscrew the saved number of steps. Wind in the cross slide for the next cut, repeat. Of course, it's easy for me to suggest it- I don't have to do the programming.....

Great project James- I have everything ready except for the daughter board- the wait is killing me.

Ken.

[vk7krj]

A further thought, instead of saving the total steps, perhaps save the number of index pulses plus the step count from the last index pulse? On a long thread or cut, the number of steps could get quite large.

Ken.

[clough42]

The encoder has an index pulse, but I don't actually use it, since I'm keeping track of the large number of counts and steps, applying the correct ratio.

What you (and others) are suggesting is a higher-level thread planning system in the firmware. This is always something that could be added in the future, along with the additional buttons to control it. Aside from the increased complexity, the main challenge is calculating and planning acceleration at the start of the cut. You can't really start the stepper at full speed instantly, so the code will have to start early and accelerate to end up on speed and position at the same time. This planning layer doesn't exist in the code right now, but it's something I have thought about for the future.

[carneeki]

What would prevent one from simply wiring a limit switch to a relay that can both disconnect the step enable line and also pull the alarm pin?

Is there a danger of losing sync with this approach?

[carneeki]

Oh wait, automatically reversing the saddle back won't be possible because step enable is disconnected (and while this isn't an issue for the current project goals, it does limit options if those goals change). Also, the controller has no idea if an alarm has been fired because a shoulder was reached, or if something more serious has happened. Dedicated GPIO pins for that would be better.

[MaHoCNC]

Hi James, I also thought about this automatic stop idea. Maybe its an good approach to make to different modes: Feed mode ,Thread mode and Off. Choosable by a way a 3 way switch.

In Thread mode its essential to keep spindle and leadscrew synced. When the endstop is reached, (Soft-stop) The VFD should get stop command and the closed loop stepper/servo should fallow. I think a brake resistor is needed on the VFD with that. In this way you can make a thread without a the need of a gap to run out in too. Then you need 3 buttons extra. Start, Reverse and Stop Now the VFD and leadscrew is stopped. You can retract the cross slide, and press "Reverse" VFD wil get reverse command en the leadscrew will fallow. When you reached the beginning of your tread again you press stop. Set your cross slide to the next DOC and press "Start" and the cycle start again.

In Feed mode its not importent to sync up between cutting cycles. But the stepper needs to count his stop position for the soft-stop. So the half nut needs to be engaged all the time You can start the VFD by pressing "start". The leadscrew wil not move yet. Set your DOC, then press for the second time "start". The stepper accelerate and feed in to the workpiece. Then just before when the previously set soft-sop postion is reached the stepper needs to decelerate and stop exactly the soft-stop position. The spindle will keep on spinning meanwhile. If you want you can retract and then press "Reverse". The leadscrew wil reverse the carriage in rapid speed. Press "Stop"(spindel still spins, leadscrew decelerate and stop). Set your next DOC and press Start and the cycle starts again. By pressing 2 times everything will stop.

Off: ELS is not active

For setting the the Soft-stop: You disengage the half-nut. position the carriage and engage the half-nut again. Then press a "set stop" button (on control panel or separate button). this will home the stepper. This all will off course only work with a closed loop system.

Notes: For the threading mode we need no programmed acceleration/deceleration because it needs to stay synced with the spindle. Only the question is if the stepper can keep up with a VFD with a brake resistor.

The programmed acceleration/deceleration is a must within the feed mode. But i think its also desirable to have this in other cases, like with changing between feeds: issue 13

EM stop switch is a must in this case!

I didn't take a look at the code yet. Just got in my launchpad yesterday. Monday i should get your PCB. Maybe i can contribute a bit, I am in no way a code star, but i code some things for my CNC mill on Linuxcnc.

Mark

[clough42]

It's worth taking a look.

The code today is a very tight cycle, expressed as a ratio between the encoder and the step output. Keeping this loop tight and fast is key to success with threading. Keeping it simple is key to guaranteeing correctness. Real-time stuff like this is notoriously hard to debug, so keeping the code easy to inspect and understand fully is a key concern.

James

On Fri, Jan 10, 2020 at 2:05 AM MaHoCNC notifications@github.com wrote:

Hi James, I also thought about this automatic stop idea. Maybe its an good approach to make to different modes: Feed mode ,Thread mode and Off. Choosable by a way a 3 way switch.

In Thread mode its essential to keep spindle and leadscrew synced. When the endstop is reached, (Soft-stop) The VFD should get stop command and the closed loop stepper/servo should fallow. I think a brake resistor is needed on the VFD with that. In this way you can make a thread without a the need of a gap to run out in too. Then you need 3 buttons extra. Start, Reverse and Stop Now the VFD and leadscrew is stopped. You can retract the cross slide, and press "Reverse" VFD wil get reverse command en the leadscrew will fallow. When you reached the beginning of your tread again you press stop. Set your cross slide to the next DOC and press "Start" and the cycle start again.

In Feed mode its not importent to sync up between cutting cycles. But the stepper needs to count his stop position for the soft-stop. So the half nut needs to be engaged all the time You can start the VFD by pressing "start". The leadscrew wil not move yet. Set your DOC, then press for the second time "start". The stepper accelerate and feed in to the workpiece. Then just before when the previously set soft-sop postion is reached the stepper needs to decelerate and stop exactly the soft-stop position. The spindle will keep on spinning meanwhile. If you want you can retract and then press "Reverse". The leadscrew wil reverse the carriage in rapid speed. Press "Stop"(spindel still spins, leadscrew decelerate and stop). Set your next DOC and press Start and the cycle starts again. By pressing 2 times everything will stop.

Off: ELS is not active

For setting the the Soft-stop: You disengage the half-nut. position the carriage and engage the half-nut again. Then press a "set stop" button (on control panel or separate button). this will home the stepper. This all will off course only work with a closed loop system.

Notes: For the threading mode we need no programmed acceleration/deceleration because it needs to stay synced with the spindle. Only the question is if the stepper can keep up with a VFD with a brake resistor.

The programmed acceleration/deceleration is a must within the feed mode. But i think its also desirable to have this in other cases, like with changing between feeds: issue 13 https://github.com/clough42/electronic-leadscrew/issues/13

EM stop switch is a must in this case!

I didn't take a look at the code yet. Just got in my launchpad yesterday. Monday i should get your PCB. Maybe i can contribute a bit, I am in no way a code star, but i code some things for my CNC mill on Linuxcnc.

Mark

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/clough42/electronic-leadscrew/issues/10?email_source=notifications&email_token=AAZLSHEOTWZVCTJYOZH5E4DQ5A27BA5CNFSM4IOYPO5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEITF6QQ#issuecomment-572940098, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZLSHC2NY3L2BUYMBOE553Q5A27BANCNFSM4IOYPO5A .

[MaHoCNC]

I didnt really did much with the code yet. I am busy with fitting out my Myford Super 7 lathe with the ELS.

But... ...i did some thinking.... When i saw that you added second encoder support, maybe its an idea to connect my DRO on my lathe to the second encoder input. With the "set" button we can set the stop value for the lineair encoder. If then the lineair encoder comes close to the set stop position, the stepper should decelerate and stop on the correct position. When stopped we can disengage the halfnut and manually bring it to the start position again. What we can do is give the start command for the stepper when the lineair encoder is like 1mm away from the stop position. (at the correct side)

This should only be possible in "feed" mode. I think the stop in treading is complex, gives other risks, needs to control the VFD and needs a break-resistor on de VFD.

I think it should be possible read out the lineair encoder to just break in between the lineair encoder and the DRO unit. So we can the ELS and DRO are independent from each other.

We dont need extra IO pins or buttons with this idea. The things we need in my opinion are:

• code to set stop position.
• Accelerate/Decelerate code for the stepper.
• translate the lineair encoder counts to distance so the stepper can use this for Deceleration.
• Break-in between the lineair encoder and DRO unit.

Probably this is to much for me to implement with my code skills. So my hopes are on you. (or someone else)

Mark

[jrspruitt]

Hello, I was wondering, as far as the releasing the half nut goes. If you had an absolute start position for the carriage, like an indicator or carriage stop, and only started the stepper, when the z phase/indexer of the encoder triggered, from that point, would that keep everything lined up on the next cut? After releasing the half nut and wheeling the carriage back to that point.

Thank you for this project, I've been "playing along at home" with a spare micro I had, just having a hard time wrapping my head around this part of it.

-Jason

[Monchichack]

Another idea into the mix:

Wire up spare button on controller with jack connection output from controller to a touch pad or limit switch. Add ESD protection to protect circuit.

-Once limit is reached stop motor & hold in position. -Display shows 'Limit'. -Operator must stop machine. -Count up encoder movement whilst machine is stopping. -Flag up error if allocated memory for count is exceeded. -Operator retracts tool & switches lathe into reverse. -Count down encoder movement as spindle reverses & re-engage motor once re-synchronized. -Flag up error if reverse spindle speed exceeds a limit defined in Config file to prevent motor 'being left behind'.

[Coxworld]

Off topic - Mark I have just completed the installation on my Super 7 and done a full write up on my blog.

https://altrish.co.uk/2020/09/08/clough42-electronic-leadscrew-project-implementation-notes/

Alan

[gusosborne]

Off topic - Mark I have just completed the installation on my Super 7 and done a full write up on my blog.

https://altrish.co.uk/2020/09/08/clough42-electronic-leadscrew-project-implementation-notes/

Alan

Very nice write up and examples, love the cost table - thanks for sharing! Perhaps this could be linked from wiki..?

[MaHoCNC]

A really nice installation and integration. Mine is also done and working. Nice to see the differences. Soon i will make a small photo essay.

Mark

[LabRatJason]

So I'm new here... I have all necessary parts in hand except the encoder, which is still a few weeks out. But I wanted to get in on this conversation because it's something I think I'm going to need on my lathe: I have an import knock off of a Smithy Granite, but the catch is: I don't have half nuts, so I cannot disconnect the carriage from the leadscrew at all. In the past, it has simply been my habit to thread away from the chuck (I have a tool post on the back side, and I just run a left handed tool from there). But I would LOVE to be able to thread toward the chuck and just stop the carriage at the correct stopping point. Here are the things I think may be applicable to the problem, and might simplify it:

1) Assuming the operator doesn't disengage the half nuts, and 2) Assuming the operator intends to cut single start threads, and 3) Assuming the leadscrew doesn't move without command from the ELS, then 4) I believe the relation of the leadscrew to the chuck rotation is simply a problem of the phase or angle (not to be confused with phase angle) of the chuck, and no care need be taken to "unwind" all of the chuck rotation that occurs after the stop.

If this holds true, then when the carriage reaches the stop, we simply stop advancing the stepper, and allow the any buffered steps to complete. When we detect that the commanded travel direction reverses (called "feedDirection" in the code), then we await the correct chuck angle, and allow the commanded steps to resume. This should, in theory, keep everything in sync. To solve for phase angle, I believe angle = spindle_position modulo encoder_resolution.

I know some other requestors have proposed using the "set" button for other things such as leadscrew RPM, but I don't find that very compelling in my configuration. I would propose using the set button for the infeed stop, but also, I realize there is a free button hidden between the up and down arrows, and in my mind, I'm wondering if there is a way to get access to that button mechanically using a lever arm to relocate it above or below the arrows? Thoughts?

I'll caveat all of this by saying, I'm not new to coding, but I'm definitely new to embedded and realtime systems, so I may well but exhibiting some Dunning-Kruger tendencies here, but I guess that's why I'm posting, to see if this is close enough to reality that we could work through it, or if I'm so far off base as to be in the dugout. If successful, I'd be willing to make the code available (hopefully via an accepted pull request) to everyone.

I will hopefully have a working install in about a month or so, and I'd start developing and testing this theory some time after that.

[toycar]

LabRatJason, I noticed you comments on this and the automatic stop post. I have build a mechanical dog clutch for my lathe in the past so your ideas here seem stop on to me. I too would like to see the ELS have these features. So I've started some exploration of these ideas. Before I dig into it completely, I wanted to see if you had ever gotten anywhere with this idea?

[LabRatJason]

Yeah, I’ve still been working on it in my spare time. I was successful in getting it to accept the “set” button push to set a stop, then you can back away from the stop and run up to it again. It stops corrrectly. This works from either direction (the direction let moved before setting the stop dictates the direction the stop is effective at. I ran into issues with what happens when the encoder count wraps around. I fixed that. I have an issue right now with getting it to resync though. I don’t want to have to unwind all the forward motion before allowing it to move.

I went a little further and incorporated a Hall effect sensor I bought from Amazon(so I don’t need the set button). It’s a 5v unit that is normally used for 3D printing, so it works with the existing power supply. I’m hijacking the servo alarm port as it provides the 5v to 3v logic shift, and James hadn’t implemented anything on that port yet, but the correct permanent solution would be to build a separate 5v to 3v logic shifter and assign it to a separate IO pin.

The set button and the alarm port solutions both work but both suffer from the issues with sync. I could probably solve it for my machine but I keep getting wrapped around the axle trying to make sure it works for everyone. There are many issues to consider, such as if you have a 1:1 chuck to encoder ratio it’s easy to calculate but we must consider all ratios. Also, encoders that don’t divide evenly into the launchpad’s register size. Finally, I’m also using a 1:1 stepper to leadscrew ratio but others may be using different configurations, and I haven’t had time to think through the ramifications of all of this. Perhaps some of it doesn’t effect the solution but I don’t want to crash someone else’s lathe. I’m almost ready to break down and just save the encoder position and number of wraps (register wraps around to zero) and just allow it to unwind, but the risk of using that method is this: when re-synching, the chuck must accelerate from zero to whatever speed it’s going to go. This can be quick when the gearing makes the max rpm slow. And when gearing is high it will take several revolutions to get up to speed. Either way the chuck isn’t moving too fast at the first opportunity to sync. If you must unwind all the motion before allowing the leadscrew to start, you risk losing steps because of the initial mass needing to accelerate at a near instantaneous moment. I guess that’s a user beware thing to say don’t back away super fast. But if I can I’d really prefer to get sync working. I’ve got some time tomorrow to play with it. Maybe I’ll take another crack at it.

Sent from my iPhone

On May 14, 2022, at 11:41 AM, toycar @.***> wrote:

 LabRatJason, I noticed you comments on this and the automatic stop post. I have build a mechanical dog clutch for my lathe in the past so your ideas here seem stop on to me. I too would like to see the ELS have these features. So I've started some exploration of these ideas. Before I dig into it completely, I wanted to see if you had ever gotten anywhere with this idea?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[toycar]

Thank you for taking the time to reply and let people know what you have been working on. I understand wanting to make it work for everyone, just not always sure it's possible. Currently the basic functions work for everyone, but adding new, very specific features, may require extra hardware and not work for all lathe types. I personally think that is okay.

I had also originally though of using the Set button to "set" a stopping point. After more thinking, I felt it was really more issue prone than just having an stop sensor. What I've had on my lathe for the last few years is a Meek style Dog Clutch. The basic design I used was based on this: https://vimeo.com/84476330?embedded=true&source=vimeo_logo&owner=16213966 about 4 minutes in he explains some of how it works. But basically it is a single pickup point on the spindle for the change gear drive. So there is only one point per revolution of the spindle that drives the change gears. So as long as you keep the half nuts engaged, you can keep the spindle turning and shift the drive from forward to stopped to reverse and always pickup the drive at the same point on the spindle. With this and a retractable tool holder, you can thread very quickly like the video shows. I use it to thread both metric and imperial threads on an 8tpi leadscrew. It can be way faster than disengaging the halfnuts and manually cranking the carriage back. The only major change I made is to use all electronic stops in place of the all mechanical system he has. I think some Colchester lathe come like this.

So my thought on the ELS was to keep the forward and reverse electronic stops and use them to stop the ELS drive. When a step is triggered, the encoder reading is modulused with the ENCODER_RESOLUTION, and stored as the pickup point. Then you only re-engage the feed at that pickup point of rotation. It sounds like this is pretty much what you have done. By using the stops at both ends of the travel, you kind of lock the feed travel into the area you want to work in and don't have to unwind back to the starting point. And in my case with an ENCODER_RESOLUTION of 4096, I think the modulus of the encoder reading gets away from worrying about the wrap of the encode count. In my case the two sensors or wired together and go into the same input. Seeing that you know the direction you are feeding, you don't really need to know which of the stops was triggered, just that "a" stop was triggered.

As for the acceleration, it is a concern. But if you are using two stops, the cutter would typically be out of the cut when you need to accelerate at the start of feeding. So you have some time to sync the feed to the pickup point number. I haven't tried it yet, but I don't really think the acceleration code needs to be very complicated. The code already has the concept of being ahead or behind the desired step. I think you could just set a base number of steps per loop to start moving. In Marlin firmware I think they call this "jerk". Then some simple ram up of steps per loop. If Marlin can do this for two steppers simultaneously on an 8bit micro, it shouldn't be a computational issue for the ELS.

I do think as you say that part of this must be "a user beware thing". There are a untold number of ways to crash a lathe, in may ways the ELS doesn't make this less or more.

I started to put some code together yesterday to work out some of my ideas. I'll keep you up to date on where my work goes too.

Yeah, I’ve still been working on it in my spare time. I was successful in getting it to accept the “set” button push to set a stop, then you can back away from the stop and run up to it again. It stops corrrectly. This works from either direction (the direction let moved before setting the stop dictates the direction the stop is effective at. I ran into issues with what happens when the encoder count wraps around. I fixed that. I have an issue right now with getting it to resync though. I don’t want to have to unwind all the forward motion before allowing it to move. I went a little further and incorporated a Hall effect sensor I bought from Amazon(so I don’t need the set button). It’s a 5v unit that is normally used for 3D printing, so it works with the existing power supply. I’m hijacking the servo alarm port as it provides the 5v to 3v logic shift, and James hadn’t implemented anything on that port yet, but the correct permanent solution would be to build a separate 5v to 3v logic shifter and assign it to a separate IO pin. The set button and the alarm port solutions both work but both suffer from the issues with sync. I could probably solve it for my machine but I keep getting wrapped around the axle trying to make sure it works for everyone. There are many issues to consider, such as if you have a 1:1 chuck to encoder ratio it’s easy to calculate but we must consider all ratios. Also, encoders that don’t divide evenly into the launchpad’s register size. Finally, I’m also using a 1:1 stepper to leadscrew ratio but others may be using different configurations, and I haven’t had time to think through the ramifications of all of this. Perhaps some of it doesn’t effect the solution but I don’t want to crash someone else’s lathe. I’m almost ready to break down and just save the encoder position and number of wraps (register wraps around to zero) and just allow it to unwind, but the risk of using that method is this: when re-synching, the chuck must accelerate from zero to whatever speed it’s going to go. This can be quick when the gearing makes the max rpm slow. And when gearing is high it will take several revolutions to get up to speed. Either way the chuck isn’t moving too fast at the first opportunity to sync. If you must unwind all the motion before allowing the leadscrew to start, you risk losing steps because of the initial mass needing to accelerate at a near instantaneous moment. I guess that’s a user beware thing to say don’t back away super fast. But if I can I’d really prefer to get sync working. I’ve got some time tomorrow to play with it. Maybe I’ll take another crack at it. … Sent from my iPhone On May 14, 2022, at 11:41 AM, toycar @.***> wrote:  LabRatJason, I noticed you comments on this and the automatic stop post. I have build a mechanical dog clutch for my lathe in the past so your ideas here seem stop on to me. I too would like to see the ELS have these features. So I've started some exploration of these ideas. Before I dig into it completely, I wanted to see if you had ever gotten anywhere with this idea? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.