I'm not a very good c/c++ programmer so you may not want me as a teacher.
By definition, I am the worst possible C++ programmer, since I have never even produced a single line of C++ code, so you are way ahead of me.
it is ugly because it is the minimal working code, not the best code or the easiest to read code. It has tons of hanging half finished ideas sprinkled throughout.
No, I meant, "Why do you say creating a hardware user interface is begging for pain?" To my eye, a hardware interface is ideal for this sort of thing. A purely hardware interface worked very well for over 150 years. Duplicating that with a digital panel is quite straightforward.
If you can design an interface that you'd never want to change then you are a better designer than me.
It is not the interface so much as the application. Changing the user interface for a screwdriver, for example, doesn't yield much of an advantage, and in fact may be a really, really bad idea. The interface for a specifically manual lathe - decidedly not a CNC lathe - should be minimalistic and limited by design intent.
That is emphatically not to say creating a more automated machine even up to and including a full blown CNC conversion is a fool's errand. Quite to the contrary, however far one wishes to go in that direction is purely a judgement call based upon one's own desires and available funds. My desire is for a capable, safe, manual lathe, not a programmable one. The ability to thread or turn to a shoulder is a very desirable feature for an otherwise perfectly manual lathe. A single button can readily be employed to enable all the necessary features with no need for any enhancement, as far as I can tell.
this is not easy for me. I wanted to display the angle releative to the start. I wanted to add a turn counter for winding coils.
I designed a coil winder a couple of years ago. I have not had the time or the money to actually build it, but I really do not want the function to be part of my lathe. I have an extreme distaste for "all in one" devices. I won't get into the long list of reasons why, but suffice to say I don't want to use my lathe for winding coils. If you want to add that functionality to your lathe, then go for it. My needs are far more modest.
I wanted to add a mode that made the cut and did an auto rapid back to the starting position. I will re-use it to drive my hobbing controller.
Again, that is a great idea if you want it for your own setup. I don't want it for mine. It involves more hardware and software than I am willing or even able to consider at this point, for a purpose for which I have no need.
Yes. A WiFi system is not simple. It is fraught with issues. I would never,
EVER even begin to suggest a highly dangerous, potentially fatal machine should have any sort of WiFi interface. I detest WiFi in general, but it is just too flaky for any industrial use.
websocket control is $0 hardware, you already have a phone or tablet.
First of all, that is an assumption. It happens to be true in my case, but it is also true I hate the phone with a seathing passion. It is horrible to the Nth degree. If I move forward with selling the thermostat design I showed you, I suppose I will have to implement a phone based UI, but I do so only under extreme protest.
In addition, it isn't $0. I would have to add a WiFi interface to the ELS board. No thanks.
On an aside, my phone cannot reliably contact any other device on my home network. Why is a puzzle I have not had a chance to address, but the bottom line is I would be spending lots of time unable to work with my lathe just so I could implement a feature I hate in the first place and which provides me no advantage whatsoever.
The bigger win is the ease of refactoring the controller code. Doing all of that in hardware is yuck. if you could abstract it all away then fine, but a MCU doesn't have the resources for that.
Again, to what end? Just because something can be done in no way implies it is of any advantage to do so.
The most niave implementation is you need to insert a calculation deciding if the move calculated in step 2 exceeds the stop and if so tell the controller it is either done or in error.
I m not quite sure what you mean. Simply compare the value of the "desired" lead screw position to the stop point. If the "desired" position is beyond the shoulder, simply update the "desired" position to the stop point and stop sending pulses. I am not sure what you mean by "tell the controller". Theree should not be any error. Any error as far as the software is concerned at this point could only be due to a programming error. Of course, it could be due to one or more missed encoder pulses, but there is no simple way to know that.
This is likely best done with 2 stops, the first is where you start and the 2nd is where you want to stop.
In this context, what do you mean by "start" and "stop"? All that needs to be known or managed is the position of the lead screw when the mode is set and the modulus of the rotation of the spindle, provided the lead screw is in sync.
Since the direction could go wonky you want to be sure you stay between these.
I don't follow you, at all. How can the direction "go wonky". Stay between what?
You can implement these stops as simple integer counters relative to a "start position counter". Be aware that you might get overflows if you use 32bit values since when threading you may leave the spindle running for a while.
That is irrelevant. When the lead screw is stopped, the number of revolutions of the spindle is immaterial. Only the small angle (between 0 and 360 degrees) is of any concern. When it si moving, only the differential between the previous position of the lead screw and the new position is required. A 16 bit counter is much more than enough for the spindle position.
It looks like clough switched to Uint64 because of this10/2020.
I didn't see this. In Encoder.h, it si a Uint32. Where do you see it as 64 bit? It certainly is not necessary.
The problem with this niave approach is that it doesn't account for acceleration/deceleration and you likely don't have any spindle control.
It doesn't really need to. As long as the code can keep up with the spindle position, and all outputs to the motor are implemented during a single encoder step, the system will keep up as well as it possibly can. The error should typically be less than 1 encoder step, or perhaps 5 arc-minutes. That is far more than accurate enough for a hobby shop, or indeed even the vast majority of industrial shops.
The practical thing is that if you use a closed loop stepper it tends to compensate for this naivete quite nicely (at the expense of accuracy).
I am using a servo. Its precision is roughly 11 arc-minutes, or 2.7 arc-minutes after being geared down. Its repeatability is not quite that good, but it is good enough in practical terms. UNC or even UNF (or metric fine) threads are just not all that accurate. One might not wish to cut threads for a micrometer or a high precision optical measuring device, but then such things should not be attempted on an ordinary lathe in the first place.
I'm honestly not really sure of the best way to do this to account for acceleration without spindle control. You'd need a motion controller that could estimate the current distance from the stop and calculate the acceleration curve (based on your settings (based on your hardware)) and as it gets into the range where it would need to decelerate it somehow balances that with the need to keep up with the spindle (which you have no control over).
It doesn't really matter how fast or slow the spindle is turning, per se. All that matters is the lead screw stops turning when the lead screw counter reaches 0x800,000. Whether the encoder pulses are coming in at over 200 Khz or at one pulse per minute, the lead screw needs to stop between the same two pulses. It is the inertia of the lead screw that can be a problem, not really the spindle. Clearly, it is true the accuracy of the stop point is of some concern. How much depends on the situation. Typically, a matter of a few thouandths is not an issue.
This is tough because you must decelerate and maybe mess your thread up or overshoot. Again, in practice this error doesn't seem all that big and in my opnion isn't worth messing with, just use a closed loop stepper which can compensate. If you use an open loop stepper you may loose steps when it tries to stop on a dime and then you could slowly lose position and not be able to repeat theading passes.
Correct.
Before you begin you need to figure out how to tell the controller to stop. Are you using a hardware stop or a software stop. If software how do you tell the controller where the stop is? Are you going to have a 10 digit keypad to enter a value?
'Simple. I have outlined this before. With the ELS engaged and the cross slide retracted, wind the spindle until it is close to the point where the shoulder will be. Stop the spindle and wind the chuck by hand until the DRO, dial indicator, or whatever says the tool is where it needs to be. Press the <Set> button three times. Entering a value requires knowing some value, and it is simply unnecessary. All either the machinist or the controller needs to know i s the carriage is where it needs to stop.
can you change the units?
No particular units are necessary. The position 0 is 0 whether it is in inches, millimeters, parsecs, whatever. Again, don't introduce unnecessary complexity. Of course, the ELS must be able to handle positions on either side of the zero reference, so zero should be represented as 0x8000,0000.
How do you account for thread direction vs spindle direction?
By the LED indicators on the controller. James has already taken care of this. One thing, I want to blink the direction LED when the lead screw is stopped to remind the machinist which way the carriage will move when the <Set> key is pressed again.
this is hairy, when left hand threading with the tool in front you need to move the carriage left if the spindle is moving counter clockwise. if the tool is in the back and you run the spindle in reverse (clockwise) you need to move the carriage right. swap all that if you are cutting a right hand thread.
Yes, of course. So what? This is always the case. No one who does not understand this should be operating a lathe.
How do you enter "stop mode" vs "slave mode"?
I propose pressing the <Set> button three times in quick succession to enter Shoulder Mode. I have gone over this all before.
Again, three presses of the <Set> button.
How do you tell all this to the controller since it wasn't designed for this?
I am not sure what you mean by that. It has several buttons, including the one labeled <Set>. This button is not used for anything at this point.
Do you try to implement double button presses, or long presses?
I was thinking triple presses. A single press can start and stop the lead screw, irrespective of the mode. Two quick presses does nothing. Three enters and exits Shoulder Stop.
When the lead screw is stopped, the word "STOP" should be in the right hand display. The left hand should still show RPM. When in Shoulder Stop mode, the text "Shoulder", or some such, should flash on the entire display every few seconds. When stopped (regardless of mode), the direction the carriage will move WRT the spindle when the <Set> key is pressed should flash on the LEDs. In standard mode, this will be the same direction the carriage was moving when the machinist pressed <Set> the last time. In Shoulder Stop mode, the direction will switch.
