Overspeed Error Detection | Lathe Electronic Leadscrew - Part 21
Вставка
- Опубліковано 25 сер 2024
- A viewer recently reported an odd behavior from the Electronic Leadscrew when running fast with a large-pitch thread selected. Today we're investigating the issue and fixing it.
GitHub project: bit.ly/elsgithub
ELS Video Playlist: bit.ly/els-play...
Logic Analyzer: www.saleae.com
Raw Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
creativecommons...
I'm a PLC programmer by trade. When I first started programming I had a project that had 5 buttons on the panel (keeping this simple). There was no reason that all 5 buttons should ever be pressed and it was physically impossible for one person to push all 5 at the same time. One day I got a call that went something like this.
Customer: Hey man, we need you to come fix something.
Me: Ok, what is the problem
Customer: When I pressed all 5 buttons at the same time the system did "insert lots of things that wouldn't make sense to the reader here"
Me (to myself): WTF???
Me: Why did you push all 5 buttons?
Customer: I wanted to see what it would do.
Me: Ok... HOW did you push all five buttons at the same time?
Customer: Oh... I got the truck driver to help me
Me: I'll be there tomorrow.
Hands down... the strangest non-problem I've ever had. If it can be done, they will do it, even if there is no reason for it.
It is a good practice to catch nearly all cases in the software, even the "strange" or "impossible" one's.
I would call it "bad code" if there are "undefined" cases. Undefined behaviour should never exist. In the end the ability to think about all this possible cases an handle them, makes the difference between an amateur and a pro. Sorry for saying this: But code as u wrote, is bad code. It might be less possible anyone would push many buttons at once, but you simply never considered faulty switches for example. Hardware can fail. So number one rule is: Think about what can go wrong.
Handling this wrong might lead to damaged data on a PC or even worth a dead person in or on a machine. So if the break on you car decides to fail because someone opened the door on the same time, it would be your fault if someone came to death. It doesn't matter if this situation is nonsense. It is unwanted unexpected behavior.
@@matthiash.4670 What PLC platform are you familiar with? How did you get access to my ladder logic and structured text? Where was the PLC physically located? What was it's function? What kind of IO did it use? Was there any serial IO? Did it have an HMI?
@@MichaelLloyd it doesn't matter, my comment was in general, no matter if you "program" a PLC (I wouldn't really call this programming anyway, but it doesn't matter), designing a physical logic hardware, programming a FPGA or just creating "real" software in any relevant language. I did all of this. You? Finally it's bad design to malfunction on misuse. No matter if this is a pencil, hammer, PLC or ECU of a car. That's the point. So your question is not related to this fact in any way. It's just a try to excuse. But there is no excuse.
@@matthiash.4670 Go away... you have no idea what you're talking about
@@MichaelLloyd this is a even more bad excuse for "bad design". So hopefully you learned something...
This is the golden standard of how an open source project is supposed to be done. I'm developing embedded firmware for 15 years and I think ELS code is absolutely beautiful - it puts tears on my eyes.
you should see my ELS code, it will also bring tears to your eyes... but not in the same way
On Windows?
The reason I love this channel is you bring nerdy stuff together. Machining + Electronics + Software = SuperNerdy!! Another great video, thank you for all your effort.
That could be quite the serious flaw, run away carriage would be really bad, glad to see you took it as seriously as you did, as you said someone could be running a high reduction set up and this could be a real issue, nice to see someone take this much pride in their work and fix it.
I ran the floor of a small production machine shop for a while. One thing I noticed about half of the guys that got hired in is that taking pride in their work was something they were never taught. Sure, they were high volume, simple parts with a large tolerance(.010"), but they still needed to be made properly.
Thank you for digging into the software a bit. I really enjoyed seeing under the hood, and the logic analyzer output was a great way to simplify that. It made it accessible to a wider audience than just going through code. Great job!
Some idle speculation:
You've got the lathe on a VFD to control speed. You now have (as a side effect of the ELS) a tachometer. In principle, you could now close the loop on spindle speed and electronically set a target speed, and drive the VFD to maintain it. You could then use that mechanism to cap spindle RPMs depending on your ELS settings to avoid saturation.
fantastic video. one suggestion if you are interested... when you code up a function or a variable to be used in an "if" check like that, consider naming the function so that you can tell what a true or false value means. For example "if (steps_too_far_behind())" or "if (stepper_in_panic())" makes it easier to know what the return value of the function indicates and which way the logic should point in the if check. Again, great video. Love learning from your channel.
This is an excellent suggestion. Naming the predicate explicitly is usually the best option. In this case, the function has a side effect of actually putting the driver into a panic state, which is also problematic, given the name. There's another subtle issue here that contributes to my mental disorganization. The best place to check the difference is in the driver ISR that runs every 5us. Unfortunately, the long subtraction adds enough to the execution time to get me up above 40% of the CPU time spent in the ISR, so I put it in the ~20ms UI loop instead. When I get around to putting in some speed limits, those will also need to be outside the ISR, and I'll probably refactor all of the decision-making logic out of the driver and it will become a clean predicate to check the backlog, and a separate method to control the enable state.
@@Clough42 sounds like you already have in mind, then, the thing I was thinking of: some sort of “warning” state (and alternating display message - like what you have for your two mode error, but with one mode still showing live data), that triggers when someone is _approaching_ saturation... so if they’re dialing up the speed on a variable control like you’ve got, there’s at least some hope they might get warned to stop speeding up before they trash their part... yes? :)
You just keep making everything reachable. Stay safe. You and your family.
Hi James. Thank you for the ongoing maintenance support. Great commitment to your viewers. Stopping the lead screw is the right decision - the alternative folks is a possible carriage crash into the chuck or tailstock. I've got a compact encoder/motor installation on my lathe, much as you mention, but still have the electronics on a breadboard. It's next on the list after the mill DRO. Cheers. BobUK.
The best way to make somthing permanent is to call it a “temporary fix”
That goes for software and hardware 🤣
And declaring something a permanent fix virtually guarantees it will need to be revisited. :)
@@Clough42 Users always think of clever ways to break stuff.
true,when i do"temporary fixes" on our costumers trucks its the same,to good to get it done the right way after :)
James, What a great explanation that even this newbie could understand, as well as an elegant fix for this unusual situation. Thanks for sharing!
Thanks for keeping this project on your sights as we all know you have a lot going on!
Good fix! If the leadscrew is lagging the spindle then the thread is already scrap, so an "all stop" is the best option. Definitely an edge case though, 8tpi at 2700rpm classifies as an extreme sport!
Wow... just finishing up the video... you have got to be the most generous YT creator (or any maker for that matter) out there. You put a lot of detailed info out there.
That was best option for a bad but unlikely situation. Excellent job explaining that!
I am using this comment section to convey my thanks and appreciation for your design. After a number of weeks intermittent effort, I have finally finished my implementation of your ELS system. To coin one of your favourite phrases - "I could not be more pleased with the result"! The ELS boost PCB and associated printed products were superb and, despite frying one Launchpad board, I got it to work more or less straight away with the replacement. Thanks, again.
Regards,
John
It really shows your dedication to your work. I really like the way you do your work and presentation. Thanks again James
Even though we didn't hear any rhymes....that was the most excellent in rhyme and reason. Thoroughly enjoyed watching the cause and effect process to logic and finding the unforeseen. That logic analyzer is so nice to see it in real time. It's one element of the magic to compensate for the issue in the most sensible way without creating another issue.
Thanks for making Idahome proud James!
Got my kit and the TI board.
If you mount the booster pcb in the wrong direction, it does not work, of course, but it does not kill anything.
As someone I know from youTube would put it, "Ask me how I know!" ;-)
I had some cold sweat once I realized.
I am waiting for the encoder to arrive, I am very excited with this project. It will go on a Chinese mini-Lathe. More later.
This is such an interesting project. On one hand it simplifies so much, making it much easier and faster to set up the lathe for a job. On the other hand it complicates things, and introduces novel new ways to mess up and for things to fail. All in all I think it's a great improvement.
On seeing the title I was pretty sure what the problem would be. Though I was not certain if the problem would turn out to be the decoding of the encoder or in the drive of the lead screw motor, though my money was on the later as it's a mechanical component and that makes physics rear it's ugly head at the most "interesting" times. Also not having followed this series of videos closely I wasn't aware how the controller program worked out the desired location of the leadscrew depending on the position of the spindle.
My first instinctive thought was that you would just have the program calculate the required stepping for the leadscrew motor, probably using a small buffer and just have the controller throw a fit flashing warnings and what ever if/when the leadscrew motor wasn't able to keep up and the buffer overflowed.
Turns out you keep virtual tracking on the leadscrew position and compares the current position to the desired position to see if the lead screw motor should receive a pulse. And that's what bit you in the ass with this edge case scenario. But unless you are working to a deadline over engineering is often the way to go as it's relatively easy to scale things down and impose limitations while doing it the other way around often means you have to invent the wheel yet again, and again, and again as people come up with ideas for new and improved functionality that "can easily be implemented"...
I was aware of the theoretical limitation, but hadn't encountered a setup with enough resolution to cause it to occur, so it hadn't come up as a limitation. You are right about people constantly coming up with functionality that "can easily be implemented". I haven't read through all the comments yet, but there will most likely be some. :)
Good call on the panic stop. I'd rather break my part - or even a toolbit - than possibly crash into the chuck. 👍❤
The long term solution would be to link the spindle speed control back to the firmware. When the lead screw control loop can limit the (desired) spindle speed, you can maintain the speed ratio constant.
Thanks, James - Good that the safety features have been considered and implemented.
A useful refinement to the "panic" stop might also be a means of dropping the main motor contactor to stop the lathe spindle. This could also be done through an E-stop on a VFD.
I was getting frustrated that you would even tend to this "problem" as you were explaining it, but about 9:35 I found out patience is a virtue. LOL
I'll be buying one of your kits soon for my mini lathe. This is a very cool idea with tons of potential in it for more functions!!!
***
My lathe has no threading dial and I have to reverse the lathe to remain on track for threading. It's not a huge problem and works exactly the same regardless of the thread pitch or SAE/metric. I don't have to know anything about my lead screw being metric or SAE. This is a pretty common situation with many mini lathes.
***
I do have a few ideas that are all software:
1. It would be cool if the + and - buttons could be used in combination with another button or by turning something on and off to run the lead screw forward or backwards for powered/manual movement. It would need to account for Items 2 and 3.
2. This controller could act as a carriage stop in feed mode or threading mode. You know where your inward position towards the spindle should be by looking at where you want the carriage to stop. Add an option that records that position with a button press. All movement inward or outward is then tracked from that position as long as the half nut or thread nut is engaged. For threading and lathes like mine that lack a thread dial, this would work superbly for threading.
3. With multiple programmable carriage stops, the lead screw could be used to position the carriage any where along the bed to perform some operation in a selected area of the work piece.
4. Items 2 and 3 are potentially quirky since people can and will disengage the lead screw. Add a limit switch feature so the motor stops at maximum inner and outer limits to avoid crashes or jamming the carriage at its travel limits.
5. You already have the micro-controller, controller and servo in place. Make the software accept external input that is common to CNC lathe controllers. Now the motor/lead screw drive can be one of the 3 axis for CNC machining. Turn off/on some option and it operates in "Stand alone" or CNC mode.
6. This is silk screening and software. There are the decimal points in the 7 segment displays that could be used to indicate that the above features (and others) are turned on. The front cover silk screening would need to be changed right under the led "dots". Label them appropriately for what each LED dot indicates. Items 2 and 3 could be labeled MEM1, MEM2, MEM3 and MEM4. Item 1 could be labeled "DRV" or "Drive" or "PW-DRV". Item 4 could be labeled "LIMIT". Item 5 could be "CNC". The RPM and FEED silk screening would need to be moved too.
The ELS is a simple device that does its job well. It sounds like you want a CNC conversion.
@@Clough42 Not really full CNC for me at least and that was only 1 of the things I listed. The rest of the items I listed were not CNC. How a carriage stop is "CNC" is a mystery to me. Same for stop switches, but they are used in full on CNC.
I am not sure where to put this but here it is.
You now have an electronic lead screw, a tool post gridnder and VFD motor control on your lathe. Given this combination it would seem that an option would be to add a capability to be able to control the angle of the spindle under electronic control. This would be helpful in making gears as an example. There are a few options for this. Probably hte most logical would be to add a rotary encoder to the spindle as the belt from the motor may slip losing accuracy. For accuracy considerations if the maximum number of teeth in a gear is ~120 and a involute toot is requied I would estimate the angular accuracy required would be 5 deg or less (normalized by the number of teeth). The maximum step sized would then be 120 (number of teeth) * 360/5 (relative accuracy) = 8K steps/revolution. 4K encoders are common but I would expect this this would be sufficient for 99% of the applications. If the encoder drives a interrupt service on zero crossings, the interrupt rate would be at 60rev/sec or 360 rpm max would be 60 rev/sec * 4K step/rev = 240K steps/sec or 6 ns. This would be very difficult to achieve in a SW only solution.
An alternative is to purchase an chip for the pulse to position counter similar to LS7366 which can operate up to 40 MHz pulse rate and design the controller assuming this HW assist. Given 4K steps/rev and the 40 MHz pulse rate then equates to a maximum 40E6 step/sec / 4E3 step/rev = 10K rev/sec max which is far above what would be normally required. The loops in SW could then run at this slower rate like 10ms/time increment.
If you commit to the rotary encoder the control would have to be a bit more sophisticated probably necessitating a processorfor the unquie control required. My chioice would probably be a rasberry pi for this control One could then also incorporate the lead screw control as well reducing the number of parts in the lathe system.
As a note in the lead screw controller you used floating point math for the conversions requird which is probably sufficient in this application. I have in the past imiplemented controllers for rotational/angular control. If the device has the possiblity of many (millions or more) rotations between starup and shut down (in systems that normally run until they break). In this case one can represent the position as an integer (with some number of fractional bits for the number of whole rotations). The control system nearly the same as the FP version and usually faster and possibly more accurate.
I suppose that a BLDC motor could also be used in the tool post tool as well. However I cannot think of a reason rotational posisition controll could helpful but a standard VFD type control could also use the same processor/controller.
This soluition would require several other parts for the motor drivers and other consideratoins. I am not sure I would take on the additional work but it is tempting.
great video have you considered adding the ability to add a limit switch for threading into tight shoulders and cutting internal threads in a blind bore
I have spent a fair bit of time thinking about this. The implications of stopping the leadscrew and restarting it in sync raises a bunch of technical issues that are difficult to manage. The primary complication is around hybrid threads (e.g. metric threads with an imperial leadscrew) and the way unlocking the half-nut works. Remember that you can usually flip the tool upside down and thread in reverse, away from the hard shoulder. (unless you have a non-locking threaded spindle)
Thanks for considering safety issues though spinning the chuck at high speed to shape 8tpi is unrealistic.. You are a genius and always come forward with bright solution.
I would suggest an additional safety related change--the requirement should be: The lead screw stepper/servo motor shall stop within 1ms (or 10ms or whatever) after the spindle encoder indicates that the spindle has stopped. This additional change would remove any other possible surprise lead screw movements with the lathe stopped.
Yea, having the lead screw panic stop seems extreme. A mechanical system wouldn't come to a complete stop so quickly.
Hey James, it was awsome to see how you programmed this feature under the hood. As someone who likes to tinker microcontrollers it would be great to understand some of the code design decisions you are making and why. It is easy to find a solution but finding one that is distributable and robust is sometimes a bit more challenging. It seems like you have a very good grasp on software engineering and I think many of us would like to see more content on the subject. Thank you for all your hard work on these videos. I personally have learned a ton from the way you work.
If there's enough interest, I'd be happy to make some videos about it. I have decades of experience in software development, though embedded systems and real-time control are specialized fields where I'm still learning.
Hello James,
Interesting video... and good to know the software is now somewhat safer, albeit in a scenario that is not likely to happen...
Take care.
Paul,,
Part 20 or 21 ? Great video as usually, thanks a lot
I think technically, it could be part 22 if you count the demo of the logic analyzer I did a few weeks back.
You could also just stop de pulsing for the leadscrew if you stop the main motor and let the out of sync as it is if the main motor is running. But give a message that it is out of sync. Reset the counters after the stop.
In German we have a word for what you're observing here: "Schleppfehler" (roughtly translatets to dragging-error because the actual position is dragged behind the desired positon)
Just a few suggestions:
Adapt the buffered step limit depending on the RPM (might want to use a RPM counter with a higher refresh rate for that to avoid lag)
e.g. if the spindle is stopped, and we have steps left, the ELS will trigger an error
or maybe just limit the number of buffered steps
e.g. if the offset is greater than X steps pull the desired position backward to keep that offset constant
this would lead to incorrect thread pitch, but that's a problem we're having anyways if we cant't output the pulses fast enought
As long as you don't exceed 100KHz, there will never be any buffered steps. Once you do, they will compound rapidly.
I have been thinking about adding this to my 10ee. It seems like it would be super useful to cut metric threads ad I would be able to adjust feed rates on the fly. I don’t want to remove my change gears but I think I could add it at the end of the lead screw.
Excellent, as always. Thanks, James.
Thanks for sharing!
Actually, you will never get into a situation where the system goes into a panic condition while in a cut. If you look at the process as a sequence of events, you will have hit the panic condition before you would engage the halfnut to begin threading OR engaging the feed nut to begin feeding. Since the sequence of events that qualifies the panic state is Input_Pulse (logical AND) Output_STEP and that will always happen before the process to feed or thread begins, you will hit the panic state the moment the lathe starts and comes up to speed.
Under most normal circumstances, this is correct. I can think of two counterexamples. One is if the operator reaches over and increases speed during the cut. I do this often, but usually only when feeding, in which case it wouldn't be an issue. There's also the possibility of being right at the limit and having the VFD bog down and overcompensate when entering the cut. These are corner cases, so I don't think it's really of much concern.
I could see myself doing something stupid like "tweaking" the RPM during the cut and accidentally flicking the knob.
Threading 8 TPI at 3000 rpm gives a feed rate of 6.25 inches per second. This is a ludicrous speed.
Of course this is not just about TPIs and RPMs but about the number of steps.If a system is using very small steps (i.e. lots of steps per revolution), the step rate goes up and you run into this problem faster.
Most system will never reach this point. It is more likely that in a system with a stepper motor the motor will stall before the maximum stepper speed is reached - at least that is the case on my lathe.
I love ELS and incorporated in my home built DRO and as such ported the code on a Teensy 4. I will have to check if this problem could occur on my system also.
On further discussion in the issue on GitHub, this particular setup had the servo set for 4000 steps/rev with 3:1 belt reduction to an 8TPI leadscrew, and for coarse threads it could hit the limit around 500rpm. So depending on the configuration, it could be reachable.
Your point about what to do when the driver can't keep up and stopping being the lesser of two evils, even though it might wreck your part, is largely moot. It's only likely to cause major issues when threading and if you've taken a cut at the wrong speed your part (and possibly tip) is likely ruined anyway. It depends how out of sync, but given you can set the threshold with MAX_BUFFERED_STEPS I wouldn't lose any sleep over it.
Leave it to our "Mr James". None better. Thank you kind Sir.
Thanks again for all your hard work.
That was a great explanation of the issue, and a good solution. Well done.
Great video again. I have a saleae logic Pro 8, brilliant tool and helps check out those weird software to hardware issues.
I have been super impressed with it. Iwas using a vintage Agilent logic analyzer before I got the Saleae, and while it's very capable (4GHz sample rate!) it's big and heavy and the UI is clunky. Being able to watch the output from the Saleae in real-time is a huge win.
You can probably calculate the theoretical maximum encoder speed based on the gear ratio and lead screw pitch. Not sure how you’d show that limit to the user, but you could use it as a threshold to warn the user that they’re getting close to dropping steps, before you have to do a safety stop.
Perhaps also have a buzzer as a warning?
I have been thinking about doing exactly this for a while.
That would have been a fantastic thing to include in the PC boards when I designed them a couple of years ago. :)
Thank you for the update.
Very interesting, as always. Thanks.
Have you considered putting in built in limits to operations, i.e. Rpm to Feed Rate/TPI. So that you can not have this step count issue happen. Great find. I think this would be more safe operation. Thanks for sharing.
Yes. I've been thinking about it. I think what makes the most sense is to set a limit for the RPM of the leadscrew, but the biggest question is what to do if it's exceeded. Capping the speed would be an option, but it introduces the possibility of wrecking a part without noticing. Stopping is probably better, unless you're sitting right at the limit and you exceed it and panic in the middle of cutting a thread that otherwise would have been fine. So it probably makes sense to have some kind of warning when you hit 80-90% of the speed limit. ironically, since it increases the complexity of the software, adding safety features like this could introduce new defects that themselves become safety issues.
@@Clough42 I would think you could with testing figure out the rpm/feedrate combos
that would exceed the count, then just do allow those combinations to be selected in the software. Just a thought.
I would suggest the user update fields like lathe min Max speed, the software could limit the choices available based on encoder speed. So for example, 8tpi selected Max speed not exceeded(read from encoder) then allow procedure to go forward otherwise a fault will display and stepper will not move.
James, thank you so much for sharing your work, it is appreciated more than you could ever imagine
The math for this is easy. The challenge is that the software is not in control of the spindle. It doesn't know if it should allow a given pitch to be selected because it doesn't know how fast the operator is going to run the spindle.
@@Clough42 Oh yes, one of those moments. Well I guess you are going to need an additional control element,. So the software can limit the speed of the machine, only limit it not control the speed. Starting to sound like a CNC lathe.
Any plans to do anything with the alarm output from the servo driver? If mine alarms (stalled servo) the servo presently simply stops, so maybe nothing needs to be done (or maybe I can plumb it to display your error message!) I'm still waiting on some hardware to get this lipstick on the pig (an import lathe/mill with no threading or feed capabilities, but fairly hefty iron.) I don't foresee stalling that servo at 3:1 drive ratio, unless I forget the carriage lock!
can you update hardware links /stepper,driver,encoder as they dont work anymore
Seems like you'd ultimately want to wire it to the E-stop, or set up some communication with the VFD/motor controller. But given that it's so rare, it's more of a 'don't do that' (along with all the other wrong things you shouldn't do with your lathe).
The enable output on the interface board is ultimately an open-collector output, so it could be wired into an e-stop system. I think you would also probably want to monitor the servo driver itself, since it can panic on its own due to over-torque and other conditions.
Wow, what a really nice dive into the problem and the solution.
Does the jitter in the output steps due to fixed resolution end up making any weird artifacts or sound from the drive?
Seems like the most likely scenario for this to be hit, is when somebody's configuration of gearing/belt drive is not ideal: too much gear down on the drive or something. More likely in initial setup than in regular use.
Yes. High resolution makes it more likely. The jitter is from the fixed steps, but it's also pretty high resolution, so I don't really hear it. That probably depends on the driver.
When you are correcting a copy error it's not a * it's a ^. An asterisk * is a footnote marker to elaborate on a word. A ^ caret is a proofers symbol to correct a word, ^Lathe
I'll keep that in mind next time I'm proofreading a printed document with a pen.
some random thoughts. It seems to the me that MAX_BUFFERED_STEPS could be more accurately be called something like MAX_DEVIATION and possibly scaled with the pitch/gearing of the leadscrew. In the real world I expect that a servo/stepper will run out of speed well before the rate of step pulses is the limit. As soon as you have set the feedrate/threadpitch you also have a good idea of the maximum spindle speed it can keep up with so it would be possible to issue an early warning. Considered adding an output to shutdown the lathe if an error occurs?
Yes. I've been thinking about this for a while. My current thinking is that an RPM limit on the leadscrew is the easiest to implement and the easiest to explain.
THANKS TO JAMES (and anyone else supporting this project too) for this really good project - I have followed it all the way, it has been enlightening (and successful) throughout. My real aim is to cut a helix for which I need to be able to load any longitudinal travel parameter (in mm). Any ideas?
I've been thinking about that ever since Tom Lipton demonstrated his setup. Do you think very many people would be interested in cutting helical parts on the mill? Or were you thinking of something else?
I don't have a mill but I am intending to use a milling attachment fixed to the cross slide. I'll ask someone else in the UK who is following this ELS series for an opinion.
@@kenhelix4494 ahh... So all you would really need would be very large thread pitches? And the ability to turn the lathe very slowly. You should be able to add larger thread pitches to Table.cpp as long as you have a high enough encoder resolution.
@@Clough42 Hi, I asked my one contact who is following your ELS design and have drawn a blank as they already have a 4-axis mill. I don't know anyone else locally, typically through the Society of Model Engineers (UK). Regarding encoder resolution I have the encoder you specified and I drive that from the headstock with a 1:2 ratio (1 turn headstock:2 turns encoder) which I believe is 8192 edges per headstock turn. I agree I need large pitches, so thank you for pointing me to Table.cpp. This is such a good project as I have now cut threads without changewheels and a Cardan shaft.
It'd be cool if there was some output so you could hook into a vfd and keep the spindle say 10% below the saturation point and not speed up if you asked for more, like maybe the spindle rpm pot goes to the els and the els outputs 0-10v to the spindle
Yeah, putting the ELS in control of the spindle could enable features like this. So far, I have been trying to keep it simple. It's easy to stray right into a full CNC conversion.
James, what time investment for this code? Write and debug to first working? Just curious. Thanks, great content.
That's a really good question. I probably spent 20 hours reading and doing math on envelopes and 3-5 hours coding to get it initially running on a breadboard. Developing it to the point where it is now, I've probably got 100-200 hours in it, but I was developing the hardware and the software and figuring out the mechanics all at the same time, so it's hard to track.
I wonder: should the ELS be able to stop the lathe, if it detects this issue?
As in: should there be a gpio output, that can trigger the estop of a VFD?
In my non-mashinist mind this would allow to safe the part, given that the number of buffered steps didn't already scrap it, but the first problem that comes to my mind is the inertia of lathe and part - one wouldn't want to suddenly have the lathe jump at you, just because one went too high with the rpm.
Spindles take a few seconds to stop due to inertia.
James, great explanation of what's going on behind the scenes as usual. Did you design the encoder simulator or get it from another source? The reason I ask is I have a need for the simulator and would like to build it. Did a couple of quick searches but nothing that directly demonstrates the simple setup. Any information is appreciated to save me some time
Hey James, I just got my kit a few weeks ago, still waiting on the stepper, but once it gets here I'm going to get started installing. I know in a previous video you had mentioned possibly adding a feature for an infeed stop. My lathe doesn't have half nuts, so this would be an incredibly useful feature. Are you working on it? If not, I may take a swing at it and send you a pull request. I've coded in C#, Python, PHP, and a half dozen other languages, but never C, and I've never coded embedded platforms, so maybe this is a terrible idea, but I'd love to give back to the project. You've done something huge for the open source community and it's awesome!
Suggestion: calculate and display projected maximum spindle speed for given TPI on their equipment, so operator is informed of "crash" condition prior to starting spindle.
Oh, that's an interesting idea. It would mean the controller would have to know the max allowable leadscrew RPM, but that could be configurable.
Impressive analysis, impressive... all of it! What a lab You've got!
Why not use the encoder changes to trigger the servo stepping instead of the 5 microsecond interrupt? Okey, for this issue, system overload, it would not make any difference.
Just used the Git-hub link. Where do I find the "shopping list" in order to find the totalt cost for the project?
Excellent video as usual!
Thanks 🙏
is there a way to use the ELS box to get the spindle angle index?
Hi James. I'm finally getting around to my ELS. I have everything up and running on the bench with no issues. (I loaded 1.4.00) My lathe has different drive train for the feed so I need to modify configuration.h to account for this. It looks like I need to modify lines 78 and 79. Do I replace "STEPPER_MICROSTEPS" and "STEPPER_RESOLUTION" at the end of lines 78 & 79 with the numeric numbers I need? Thanks again for all you do.
Is there a plug and play option for people who do not have the skills to build one of those. Thank you great video
Maybe not so extreme, depending on the ratio.
Hmm... automatic thread (half nut) engage without stopping the lathe?
Just wondering...
Very clever
Have you thought about a "Emergency Stop" condition?
I don't have a Leadscrew yet but this video was excellent. I hope you will have more electronic or even better electro-mechanical related videos ;) (What about gear cutting? ;) )
There are potentially a number of applications that could use essentially the same hardware with different mechanical and software configurations. Gear hobbing and spiral cutting are a couple.
Sorry in advance to ask about how you've spent your money, but I am mostly ignorant of the cost of the electronics. How much does all this add up to? The controller, encoder, motors, readout, etc. Plus the lathe itself(and any improvements to it). An estimate, of course, is what I ask before I even think of starting something like this. If you don't mind answering.
since torque drops quickly with increasing RPM on a stepper maybe you want the user to test the max usable torque for their stepper and then set the speed limit based on that, not as much of a problem for a servo but how many servo users do you have? Perhaps something as simple as setting a 400 or 600 RPM limit in the config?
I am actually working on this on a branch already. I picked 500rpm, but still need to do some testing.
I have the same Lathe like yours Grizzly. It's being returned because on the high range, the motor pulley is not aligned. The belt walks off on the spindle pulley. A huge disappointment. I know about this screw driver system. I felt I wanted to exchange my ordeal.
Is "Panic! Stop" the best way to handle this? I mean assuming it's something like a threading pass then "Panic! Stop" is the same as "Auto scrapping your part"
Wouldn't a better solution be "Too Fast" to the display telling the operator to slow down
&&
If the spindle stops (or having been high falling below 1 RPM) then stop the enable of movement on the output
Keep in mind this is a serious safety issue, preventing a crash. IMO a warning sent to the display is a half measure that (1) may not be noticed, especially by an operator who is obliviously overdriving the ELS, and (2) doesn't mitigate the risk of a crash.
Stopping the servo actually IS the message to the operator. "Stop doing that!"
No need to worry about scrapping a part, because anyone overdriving the ELS hard enough to trigger this condition wasn't making a usable part anyway.
If the high rpm with low tpi scenario kills the feed during operation of cutting a thread Does the feed stepper stop while the spindle still rotates? Wont you have an issue with smashing the tool during the cut? Could you program a total system (spindle motor and stepper feed motor) shutdown?
If the cpu had control of the spindle, this would be possible, but it doesn't. That's starting to get into CNC conversion territory.
I think you can do variable pitch thread while pressing the buttons :)
Technically possible. Not recommended. :)
The links for the parts on your wiki page (hybrid servo and driver) are not found on ebay anymore. Can you most the model numbers you used for those on the wiki? Thanks
Yeah. I'm in the process of revisiting my servo choice. I'm currently using the 2Nm set from Automation Technology, and it's just barely strong enough. I have a 3Nm set on order as well as a ClearPath for some testing. I've been looking at all the "3Nm" and "4Nm" sets on eBay and Amazon, and there's a lot of creativity in the specifications. most of the "4Nm" sets actually peak at 2.5Nm or less.
@@Clough42 Thanks. Will stay tuned.
Why, now you set, stepper micro steps 8 and stepper resolution 200? Before you set 3 and 1000? If I remember well, was the configuration that you set when you play the metric leadscrew video, and ai follow that, but now look that you change it, why?
Hi James,
Thanks for all interesting things you share with us. I would like to build your ELS for my late but the TI LaunchXL-F280049C evaluation board specified in your BOM is not available anywhere. Is there other TI compatible version, like the LAUNCHXL-F28069M which is available, we could use instead ? Many thanks in advance
Wow. They're backordered until July? That's frustrating. The f28069m is a different animal and isn't directly compatible, unfortunately. If the shortage continues, it might be worth porting the project over to another platform.
@@Clough42 yep it is, I just ordered combo on your ebay, fortunately, it seems there are still some LaunchXL-F280049C available on aliexpress, I will try by this way...
After a little more research, it looks like it's the chips themselves. Every version of the microcontroller chip is out of stock everywhere--even the offshore assembly houses. I thought I had designed my hardware to use commodity parts that wouldn't be subject to supply chain issues, but I didn't think about the TI chips. :(
Can anyone help with a question I have??? I have completed the electronic lead screw and it seems to be working well! I would like to add an emergency stop along with a carriage stop. the carriage stop would only be for emergency purposes. I am fine with the mechanics of this but need help where to do the wiring. can i just connect normally closed switches in series in the enable - line or do i somehow use the Alarm circuit??? Any help would be deeply appreciated!
You can connect normally closed switches in series with enable if enable is normally-closed. Different drivers do this different ways. If disconnecting the enable causes the motor to stop, it will work. You may be able to reverse this in the driver (and invert the signal in Configuration.h). You could also disconnect the STEP wire, but this would not help if the (servo) driver is running away for some reason.
@@Clough42 Thanks so much for the quick answer James. My main concern at my older age is an inadvertant crash into the chuck I really would like to thank you for sharing your knowledge on the build. Most of this is way past my payscale!! Thanks again.
@@chuckmayerchak3071 in practice, this works the same as a gearbox. Keep your hands on the half-nut lever, the same as you would normally.
Which version control software are you using here?
That's SourceTree.
Wouldn't it be better to not allow threading at very high rpm ?
How would that differ from what I'm doing? (displaying an error if you exceed a speed limit on the leadscrew)
Version 1.4 has a bug in it. I have loaded into ccs yesterday and project explorer shows exclamation mark and ccs doesn't want to build it. I am using ccs v10
I am having the same problem. Sadly, Code Composer only loaded Version 10 when I first loaded up in May 2020 - Are we stick with Version 10? Ken Cobb
I have deleted Code Composer V10 and loaded V9.3. This has loaded the latest version (V1.4, May2021) of the ELS software onto my board successfully. KC
James, for some reason I cannot get into your ELS video list. Could you see if all is correct on your end, if so please tell me what to try so I can open the list? Thanks
UA-cam seems to be doing something funky where it's shortening the link text in the description. I just replaced the links with shorter ones. Let me know if that still doesn't work.
James I ran into a problem today, everything was working just fine. I was running the lathe and all of a sudden the drive stopped. I am no longer getting a tach signal! the Display powers up normally nut when i power on the spindle I get no tack reading. I removed your interface board and check all my soldier joints went through all the continuity tests from pins. checked the switches on the board. I have two green led's on the interface and the blue and red on the TI all the buttons work on the display but no tachometer reading. Is there a way to test the encoder. I don't have anything other than a decent volt ohm meter. I am using the encoder you used Although I'm thinking its a Chinese knock off. I hate to start throwing parts at it. I need help. Also in a case like this, is there a way to operate the stepper motor at least for turning.?? Please help!!!!
The encoder drives the tach display. It the display is responding (can change pitches) and the tach reads zero, it isn't getting an encoder signal. The encoder connects directly to the launchpad board, so the problem would lie with the encoder, cable, or the launchpad. You could try the other encoder connector on the launchpad board (EQEP2). You would also need to change Configuration h and reprogram it to use the other encoder input. If that works, the Launchpad board is damaged--possibly by static electricity.
@@Clough42 James, thanks again for the quick replay. Those were my thoughts also, although I am leaning towards the cheap Chinese knock off encoder??? I ordered a second encoder and found a Launch board still available, They are getting short in supply. neither will go to waste at this point. My next question is if the board is damaged is there any chance that it ruined the interface board?? I'm not at all apposed to also replacing it if you feel there is any chance of it hurting the main board. I am trying to be cautious here because of the lack of Launch boards. The price is insignificant.
I enjoyed the electronic lead screw so much for the short time it operated, I have to get it up and going no matter what! Such an improvement on the old Atlas lathe!
Nice software fix!! :)
I've just found your channel, but I can already tell I'm going to be spending a lot of time here. So I hope I won't offend you if I offer a friendly suggestion. Since your channel is growing quickly, it's inevitable that new viewers will sometimes arrive in the middle of a project (example: your multi-video spindle installation project). This can be quite disorienting, since it falls to the viewer to figure out what you're up to and why they should care. To make newcomers morewelcome, I suggest you spend a minute or two at the beginning of each video giving viewers a high level overview of your project and how the current video fits into it. I hope this suggestion is helpful. Good luck with your channel!
Is the two-and-a-half minute review I started with at 0:29 insufficient?
@@Clough42 I have to apologize for the fact that my comment is not actually associated with the videos to which it best applies. I had been watching videos related to your mill spindle upgrade, and I found it difficult to get up to speed on what you were doing, why you were doing it, and how you were going to complete it. Many others no doubt experienced no such problem, but I still thought it might be helpful to post a general comment that might apply to every project. Through some mysterious mistake I don't fully understand, I left the comment on a video to which it is less relevant. Sorry for the confusion that caused. I enjoy your videos, and I'm sure your channel will enjoy continued success.
@@TitusLivy777 I've seen the same thing happen when playing on Chromecast. I start editing a comment, and then autoplay starts a new video and the comment goes there instead.
This would normally be 'following error' in a normal CNC...
In the Fanuc world closed loop mode will limit your top feedrate in P1430. Some builders will set this to between 160ipm to 210ipm and if that feedrate is exceeded you will get an alarm. Pitch of the thread x rpm will yield feedrate. Sounds similar to what's happening here.
👍👍😎👍👍. Wow......
interesting!!!
In your opening, something tells me you’ve been watching Blondihacks. Correct? :)