- Joined
- Dec 3, 2014
- Messages
- 497
I seriously doubt a hacker is going to the bother of hacking a hobbyist's lathe when they can hack Elon's Tesla and drive him to prison or into a wall instead... just sayin.I'd prefer for my lathe ELS software to be stable, and not need to be updated years later because some phone library was no longer valid. I do agree that user interfaces are hard, and I don't want something like the popular ELS that uses a $2 LED display/button board with severe limitations and lack of flexibility. Better interfaces are possible these days with a rotary encoder knob (or two) and a graphical display and in this case perhaps a dedicated switch or two (even better than a phone interface). Once it works, lay in a few spare parts and only touch it if you want to improve it. At some point it is done and no further changes are needed, and it keeps working till the hardware breaks. So while a phone interface is neat, I don't think I want one on my lathe, but that's just me.
My 3D printers do have wireless interfaces, and that's fine because someone else is maintaining it, I don't have to hack the code every few years to keep it working. If the hackers were to get in they could overheat a heater or send a little motor past the limits, but that's hardly comparable to what they could do with a 2hp lathe ELS. Scary thought.
There are some Pico boards that have Wifi etc. Perhaps even using an ESP32. If that is needed it is best offloaded to separate processors.
I also cannot concur with your criticism of the simple LCD and encoder options. Properly implemented with the right choice of controller they can be powerful tools. I just haven't seen that done enough.Most people building a simple ELS controller for threading would be well advised to keep it simple with their hardware options except for their controller.
For example, my friend and I collaborated on a ESP32 based multi-mode (milling, drilling, turning, sanding, and counter) tachometer and machining calculator that cost sub $10 to make, uses LCD display and a single EC11 encoder for data selection and input. What makes it special is the memory capacity and the use of look up tables for data input. Ultra fast selection from vast arrays of data for materials, cutters and dimensions. For instance, the user does not enter 12.125" by scrolling thru five places and selecting the appropriate integer for each place. The user selects data progressing thru sub menus for mode, material, tool, and then scrolls thru dimension just by turning the encoder wheel to the correct value from a table. More on that in a minute.
To start, the uses enters set-up routine which is stored in non-volatile memory. The user can select metric or imperial, and the number of pulses per rotation, ie the number of magnets or slots in their selected sensor mounted to their machine, this allows flexibility in sensor mounting options and calculator sensitivity.
The device measures the spindle speed based intervals between pulses for faster returns, and by default the device then displays the calculated RPM. If selected, the device then further calculates the optimal surface feet per minute and feed rates based user inputs for material being machined and the selected tool. The user toggles between these views with a simple push on the encoder wheel.
Data input is currently split between tables of typical dimension ranges based on the operational mode and user input of data from external printed charts for recommended surface feet per minute and chip loads. However we're just in the process of converting external charts into look-up tables to be stored in onboard memory. This enhanced data input method is faster, cleaner, and cheaper than anything else possible.
Thanks ESP32 for adding the memory to make this capability viable.
Selection goes like this: Mode <scroll, push > Lathe. Material <scroll, push> Steel <scroll, push> Non-alloyed <scroll, push> 1045. Tool <scroll, push> insert <scroll, push> size. These choices then populate the fields to perform speed and feed calculations. Encoder wheels can be powerful input devices in the hands of a knowledgeable programmer.
KISS and keep it cheap, and utterly reliable and fast to use. This is V1:
V2 features layout for improved ergonomics and cable management.
To accomplish the best end result for their ELS project, people really need to solidly define what you project goals are. Are you making an ELS or a smart lathe? Then research and understand well the hardware and software choices.
I'm come right out and say, I was not enamoured with clough42's ELS because for it's targeted purpose it is is overly complicated, uses less than ideal hardware choices for the larger audience, and appears to me to be designed more to create youtube channel content than for helping the masses fix a gaping issue with Chinese mini-lathes, that being that they suck for threading.
I dont have a mini-lathe, I have a Precision Colchester Chipmaster lathe. I want to convert it to a smart lathe that retains all the feel and functionality of a manual lathe. So I haven't attempted to design an ELS for the masses, but as a designer, my opinion is that people who do should ensure that aside from the stepper motors and mounting, the controller itself should be as simple, easy and inexpensive as possible relying on readily available parts. Just ask why the auto sector still uses aged chips few others would consider.
Oh and make it open source naturally. You can still sell completed boards and cases to make it semi-plug and play for people with various lathes and still make some money if you wish.
If someone wants to send me a terrible mini-lathe I'd have the impetuous to design an ELS as I describe to solve this one simple issue with mini-lathes for dirt cheap.