How to add a X component
2
#X
I am picturing a separate module to set and control X. It could be integrated into Jon's Z code someday. Possible this will be come Pseudo Code. Description: Cross slide stepper motor Encoder Limit switch front max lsfm Limit switch rear max lsrm Limit switch travel front lstf Limit switch travel rear lstr Start: Move Cross slide front to back and back to front. Need to limit maximum travel with limit switches or possible encoder count if you hit limit switch have reverse Jog: Move short distance(?) front or back Making cut: Set lstf 0 Set lstr depth of cut and on and on, this is just off the top of my head much help is needed, oh I am not a programmer. to be continued. Ralph
|
What are .stp files?
11
Jon what program opens .stp files from your CAD folder? I had a 3D program called Moi that used .stp files but my subscription has expired. Ralph
|
#INTRO
2
#INTRO
Well done Ralph for setting up this group. I've already fitted Jon's excellent ELS to my Myford lathe and I'm currently plodding through tidying up the loose ends. I'm chuffed to bits with the system to date ... it just needs a little tweeking to the drive train to over come a small glitch of my making! Ralph, I'm more accustomed to a forum type of discussion group than this email system, but I have a feeling it's possible to associate one of these groups with it's own Wiki. If that's the case is it possible to set one up here? It's a fantastic way of disseminating information without posts drifting off topic. Julian
|
WIKI
There is a WIKI available for the group but it is available only for "PAID" groups. The paid groups and have lots of features but I do not imagine we would ever need them, but that would be nice if we actually needed more space and features. Ralph
|
Icon
9
Anyone have a idea for a cool group icon? All donations freely accepted. Ralph
|
Hobbymat MD65
4
Hello everyone, I'm Gene and I originally come from Russia. I've been living in Thailand for a few years, and for the past few years I'm in Luxembourg. I'm working as a software developer, but quite far from the field of MCU programming (although I did use C/C++ and x86 assembly years ago), learning about Arduino since earlier this year. I've recently bought a used Hobbymat MD65 lathe from UK, and planning all sorts of upgrades to it. I don't have a desire to go CNC as I was always fascinated with manual machining and want to focus on it. However, the idea of fiddling with belts to change spindle speeds, and set up change gears to cut threads seems kinda outdated, considering what kind of technology is available today. I'm going to replace the original motor with a 3-phase one and a VFD. Still haven't decided if I will keep the original belts and pulleys (4 reduction options available), or make new ones with a single ratio. I'm also planning to install a DRO with magnetic linear encoders and a touchscreen laptop-based interface (using a not so well named "Caliper2PC" unit to interface with the encoders, and the related software). For varying feed rates and cutting threads, I was previously recommended the "Russian ELS" (made by Oleg), however I'm not that fond of it's controls (a joystick, couple of rotary switches and a bunch of buttons, with just a 16x2 text display), and I am not sure I will ever want the X axis control. Then I stumbled on Jon's Atomic ELS, and when I saw the UI, and how well Jon explained everything in the video, I figured that looks like a great option. I'm now in the phase of gathering parts, so far I've ordered: - 3.5" Nextion Enhanced NX4832K035 display from ITEAD ($38.64, use discount code NEXTIONTRIP) - Omron 1800 PPR E6B2-CWZ6C (Chinese, most likely a copy - as the original costs $332 from Mouser) rotary encoder from eBay seller anna758595 ($32.30) - YE Series 1 Axis Closed Loop Stepper CNC Kit 4.8 Nm(679.87oz.in) Nema 34 Motor & Driver from StepperOnline (€101.20, shipped from Germany for €12.36) - 350W 48V 7.3A 115/230V Switching Power Supply from StepperOnline (€25.88, shipped from Germany for €12.36) Note that the encoder I've chosen is 1800 PPR, rather than 800 PPR that Jon uses, hopefully the code will be able to keep up with the pulses. I think it should be possible, because the Russian ELS also uses an Arduino Mega, with a 1800 PPR encoder (which it decodes in X2 mode), and claims support for "7 feeds: 0.03-0.21mm at spindle speed up to ~~2500 RPM". The main reason I chose it is that I would like to implement spindle dividing and would like higher resolution. With X2 or X4 decoding, respectively 3600 or 7200 counts per revolution can be measured, providing a resolution of 0.1 or 0.05 degree (6 or 3 minutes). I plan to make custom enclosures using either Aluminum or galvanized steel sheet. I like Aluminum better, but am not sure how to ensure proper electrical connection between the riveted/screwed together parts for proper grounding (considering the oxide layer on the surface of the sheet). I already have several different Arduino boards (including one Mega, and some 32-bit boards based on STM32 and ESP32) and various other parts, so I will figure out if something is missing later on. Good luck with your projects, guys. Best regards, --Gene
|
Greetings from Canada
10
Hello - I'm lurking here and hoping to learn something. Some of you might find this amusing but I've always wanted to do something like an ELS to my teeny Unimat lathe as it would be a great way to make tiny screws. The Unimat can barely cut something about the diameter of a cigarettte with about a 2" swing and 7" bed capacity ? Thanks for setting the group up. Lewis
|
re-using computer cases
7
I probably have a stack of 8 old computers. I was picturing making some forms and making bends then some welding (gee I might even learn how to use my mig welder attachment) than with some bondo and sanding should make a nice box/cover whatever. Ralph
|
Video
10
Is there a video of the AtomicELS actually cutting a thread? If so where? D1cky
|
Why motorized X ?
9
#whyX
Why motorized X? I know some people say they do not want or see the need for a motorized X axis. Of course there are those who say they they do not want or need a motorized Z axis. I want motorized Z and X. The recommended thread cutting practice shows for a 1mm thread you use the following cuts: Pitch Depth Pass1 Pass 2 Pass 3 Pass 4 Pass 5 1 0.61mm 0.18mm 0.15mm 0.12mm 0.10mm 0.06mm Damm I have Imperial dials now what do I do? With AtomicELS with motorized X you just enter it in. With the nice Nextion display you see exactly what you are entering, and possible we will be going to a larger display. You can always convert the mm to inches but it is so much easier to set the depth on the Nextion LED. Then if you have a lathe like do that is 50 years old and the dials are small and hard to read to say nothing of my/your 50+ year old eyes entering 0.18mm might be doable but getting down to 0.10mm or 0.06mm might be impossible. Then suppose you want to do some broaching. Even I with my limited machining experience have had to modify or add a broach to a pulley. So you setup the broach on your tool holder and your work piece is in your chuck. Now you need to go to a 1/4" depth and you figure you can get .005 per stroke. Any idea how often you are going to be setting and retracting X. Again with AtomicELS and motorized X it is all set on the display you push the buttons and it is done for you. I would appreciate any and all help and criticism on implementing X on AtomicELS. Ralph
|
ELS encoder-stepper math
18
Well, I've been looking at the Master version of the Atomic ELS code on GitHub, last changed in April 2020. This code appears to be written in ANSI C, although the comments are C++ style. The following comments are against the "AtomicELS.ino" module. Two things jump out at me, in the "feedFill()" (module line 614), whose purpose is to "Distribute the [leadscrew] steps evenly around one spindle rotation": All the computation variables are declared as "int", which (for a Arduino Nano using a Microchip model ATmega328P microcontroller) means a twos-complement 8-bit signed integer. One bit is reserved for the sign, leaving seven bits of value, so the range for positive numbers is 0-127. The math is done using two such variables, one containing leadscrew rotations per spindle rotation, the other containing the fractional part of a leadscrew rotation; this can be expressed as the decimal number "aa.bbb". The integer part, aa, varies between 0 and 40, while the fractional part, bb, varies between 0 and 127. The only expressible LS/S speed ratios are 0.00079 through 40.992 in steps of 1/127. The computation is done once per spindle rotation, and the remaining fraction of a stepper step is discarded at the start of each new spindle rotation. The net effect is that the leadscrew will spin slightly slower than intended for any given spindle speed. Two easy fixes occur to me. First, change the "int" declarations to "uint8". This will allow the fractional part's range to grow be 0 to 255, versus 0 to 127. Second, do not zero the variable "sum" at the start of each spindle rotation. Instead, let it accumulate and roll over (following Modular Arithmetic). One way to see if this theory is plausible is to cut a scratch thread at least 12" long, and measure the distance between start of first full thread and start of the last full thread, count threads, and do the math to determine the achieved threads per inch. Do this for a number of different target thread pitches. This may suffice. If not, one can use scaled arithmetic in a 24-bit or 32-bit integer. Given the need to handle all manner of thread types and spindle to leadscrew gearing ratios, what's needed is a way to handle ratios that are irrational numbers without excess error, even when cutting a new full-length leadscrew. Joe Gwinn .<https://en.wikipedia.org/wiki/Modular_arithmetic>
|
Analysis and Implementation of Scaled Arithmetic
5
This is adapted from a memo I published on 24 January 1985 titled "Analysis and Implementation of Scaled Arithmetic", written for use by the 125-member software team writing the code to implement the many algorithms of a weather radar. This memo was a runaway best seller. While this memo is Fortran-centric, it mostly carries over to C directly, even thought the code syntax is slightly different. The processors were Motorola 68000, the founding member of the 68000 family. Floating-point hardware came later. As I recall, the 68000 could do one million instructions per second, but only under lab conditions, attended by marketeers in white coats. .<https://en.wikipedia.org/wiki/Motorola_68000> =============================================================== The purpose of this memo is to show how to implement mathematical functions in compiled languages such as Fortran using scaled integer variables instead of the usual floating point. A coding practice which avoids undetected overflow and loss of precision in scaled integer computations is also described. There are two problems to be solved. The first is the lack of a simple, clear algorithm yielding the scaled arithmetic equivalent of a desired function. The second is an oddity of some implementations of Fortran: The expression "(A*B)/C" is computed by multiplying the i*2 variables "A" and "B" together yielding the i*4 result "A*B", which is then wrongly made into an i*2 value by discarding the most-significant i*2 word before division by "C". This means that if "A*B" exceeds plus or minus 32767, even if "(A*B)/C" does not, the answer will be wildly wrong, with no warning given. This problem may be avoided by a simple coding practice, described below, that works on most current compilers. The coding practice is simply to split the i*2 expression "S=(A*B)/C" into two expressions joined by the i*4 temporary variable "T": "T=(A*B)" followed by "S=T/C". The variables A, B, C, and S are all i*2. The rule-of-thumb for the assignment of the scaling factor of scaled variables is to use the largest factor that permits the largest value expected to fit into the scaled variable. For example, if the variable "X" ranges from +460 to -460 and must fit into an i*2 scaled variable X', the largest and therefore correct scale factor is 32768/460= 71.235. However, fractional scaling factors are not allowed, and for speed power-of-two factors are desirable (so division can be implemented with bit shift instructions), so we would actually use 64: X = X'/64 . If precision is more important than speed, one could use a scaling factor of 70 instead. One may ask why we bother with i*2 variables at all if they cause all this trouble. The answer is that the Motorola M68000 processor hardware directly supports the multiplication of two i*2 variables to get an i*4 result, and also the division of an i*4 variable by an i*2 variable to yield an i*2 quotient. The i*2 remainder is discarded by the Fortran "integer divide" operator. Addition and subtraction of two i*4 variables yielding an i*4 result is also directly supported. Arithmetic operations supported only indirectly, by special Fortran Mathematical Runtime Routines, are very much slower. The analysis algorithm and use of the coding practice are shown in the following examples. In these examples, unprimed variables are floating-point, primed variables are scaled. Also note that all scaled-variable divisions are integer, and therefore the remainders are discarded. A. A speed-distance-time problem: 1. The unscaled equation, with floating-point variables: Y = S*T+Y0, where Y = current position in miles S = speed in miles per hour T = time in hours Y0 = initial position in miles 2. The scaled-integer variables are chosen: Y = Y'/8 The lsb of Y' is 1/8 mile. S = S'/8 The lsb of S' is 1/8 MPH. T = T'/4 The lsb of T' is 1/4 hour. Y0 = Y0'/16 The lsb of Y0' is 1/16 mile. 3. Substitute scaled variables into the original equation: Y = S * T + Y0 (Y'/8) = (S'/8)*(T'/4) + (Y0'/16) -- Multiply through by 8 and simplify -- Y' = (S'*T')/4 + Y0'/2 4. Coding: Note th
|
Stepper Command Dithering Math
Attached find a pdf containing my musings of dithering to mitigate errors in the ELS due to quantization of leadscrew drive using steppers. Comments welcome from all. Joe
|
ELS Assumptions and Canonical Examples - Draft 2
2
Now draft 2, corrected and greatly expanded, for comment by all. The ELS (Electronic Leadscrew) must cover all known and possible screw-thread systems, using an unconstrained gearing system, so ELS cannot depend on the regularities of any possible screw-thread system, or of any gearing system. Thus, the speed ratio between the spindle shaft and the lead-screw shaft of a lathe is necessarily unconstrained in the following way -- mathematically, one must be able to implement a repeating rational number or an irrational real number ratio, over a bounded (finite) range. In practice, standard 12" (by swing diameter) lathes cannot usefully cut threads finer than 80 TPI (threads per inch) or coarser than 4 TPI, and pitches finer than this range are actually used for ordinary turning, boring, or facing operations, for which great accuracy of pitch is not required. (This is a pitch range of 20:1.) For example: Assuming an 8 TPI leadscrew, to cut a notional 240 TPI thread, the spindle must turn 240/8= 30 times faster than the leadscrew -- the carriage just creeps along. And to cut a 4 TPI thread, the leadscrew must instead turn twice as fast as the spindle -- it's just flying along. (This is a pitch range of 60:1.) As a practical matter, at low TPIs, the threads are big and deep, so the lathe may become torque-limited. The torque issue is traditionally handled by using the back gear, but this detail is invisible to ELS, as it measures spindle rotation directly. At simultaneous low TPIs and spindle speeds, the leadscrew stepper may be speed-limited. If needed, a polyphase AC servo motor can go far faster than a stepper. The Arduino's PWM channels can be used to synthesize the needed 2- or 3- phase drive signals. In addition to screw-thread systems, it is also desired to handle all possible cross-slide feed rates, and to be able to vary this dynamically, for use during facing. The numerical case is already covered by the real-number ratio assumption. The ELS must approximate the ideal form of the selected thread such that the absolute error never exceeds 0.0001" (2.54 microns), so that other mechanical imperfections of the lathe dominate the error budget. ELS must implement some kind of torque limiting, to prevent damage when carriage motion is mechanically blocked. The lathe may also implement some kind of mechanical fuse to prevent damage. If the ELS' torque limit is lower than that of the mechanical fuse, the fuse won't need replacement very often. Another fundamental limit to accuracy in the error budget is that the crystal clock oscillator in the Arduino has errors not exceeding +/- 25 ppm (parts per million); this is unlikely to matter, compared to other errors. The objective is that cut threads have a specific thread density (threads per inch), and if one arranges things suitably, the clock frequency can be made to cancel out, so long as the clock frequency doesn't change too rapidly. We can compute the ration of leadscrew rotational speed to that of the spindle, and use the measured time for a single rotation of the spindle to compute the time for one rotation of the leadscrew to cut the desired thread pitch. In this, the exact clock frequency drops out. An ELS-equipped lathe must be able to replicate its own leadscrew, or the leadscrew of any lathe of similar bed length. The maximum length of such leadscrews is maybe six feet. There are longer lathes, but not usually in home shops. There are two major kinds of thread-cutting error to be addressed here: First, there is the few-turns error, which may be but is not necessarily random in nature. Nominally zero-mean random error is preferred. A standard way to randomize non-random errors is by adding random dither to smear out the undesired patterns. Few-turns error controls the ability to freely run a close-fitting nut from end to end on a newly cut threaded rod. If all as-mitigated errors are of roughly the same magnitude, their sum will tend towards random, by the law of large numbers. Second is long-term trend error, where the as-cut thread pitch is not exactly correct, so b
|
ELS Assumptions and Canonical Examples
28
Well, I've been thinking about the ELS, and what problems is is supposed to solve. What issues have I missed or misunderstood? The ELS (Electronic Leadscrew) must cover all known and possible screw-thread systems, using an unconstrained gearing system, so ELS cannot depend on the regularities of any possible single screw-thread system or gearing system. Thus, the speed ratio between the spindle shaft and the lead-screw shaft of a lathe is necessarily unconstrained -- one must be able to implement an irrational real number ratio over a bounded finite range. For example: An 8 TPI (threads per inch) leadscrew may rotate 30 times as fast as the spindle (240 TPI), or as slow as one half the spindle speed (4 TPI). As a practical matter, at low TPIs, the lathe may become torque-limited. The torque issue is traditionally handled by using the back gear, but this is invisible to ELS, as it measures spindle rotation directly. At simultaneous high TPIs and spindle speeds, the leadscrew stepper may be speed-limited. If needed, a polyphase AC servo motor can go far faster than a stepper. In addition to screw-thread systems, it is also desired to handle all possible cross-slide feed rates, as used for facing. This case is already covered by the real-number ratio assumption. The ELS must approximate the ideal form of the selected thread such that the absolute error never exceeds 0.0001", so that other mechanical imperfections of the lathe dominate the error budget. Another fundamental limit to accuracy in the error budget is that the crystal clock oscillator in the Arduino has errors not exceeding +/- 25 ppm (parts per million); this is unlikely to matter, compared to other errors. An ELS-equipped lathe must be able to replicate its own leadscrew, or the leadscrew of any lathe of similar bed length. The maximum length of such leadscrews is maybe six feet. There are longer lathes, but not usually in home shops. There are two major kinds of thread-cutting error to be addressed here: First, there is the few-turns error, which may be but is not necessarily random in nature. This error controls the ability to freely run a close-fitting nut from end to end on a newly cut threaded rod. Second is long-term trend error, where the as-cut thread pitch is not exactly correct, so the accumulated error grows gradually along a threaded rod as residual per-turn errors accumulate. This error controls the ability to produce a long threaded rod (like a leadscrew) with exactly the correct pitch (limited only by the accuracy of the lathe doing the thread cutting). This is often the harder problem to solve in practice, because even the smallest of errors will slowly accumulate. Joe Gwinn
|
Welcome Everyone
Most every month the administrators of the forums I follow post a Status/Acceptable Use. So here goes. I think we are doing great. Julian has almost worked out all of his problems. Are there other users who have implemented AtomicELS? I know there was a user Chuck on the Logan Lathe group that was building up the AtomicELS system. I do not know if Chuck has joined us, if anyone has his email please invite him. Is anyone else working on building a AtomicELS system. I sure would love to see pictures of your progress. The AtomicELS group is not limited to just discussing Jon's system. Most anything could be discussed. I am going to be posting and asking questions on mounting a a Z drive stepper. I am going to be posting and asking questions on mounting a a X drive stepper. I also will be posting questions and pictures and videos of controlling the spindle motor. Actually since Jon and I both have a Clausing 8520 vertical mill that will come up in our discussions. Especially as I have the EazyCNC kit so that will be discussed. That and also DRO I have DRO on my mill as Jon does but I am also "thinking" of having DRO on my lathe. Oh and since we are no longer on the Logan Lathe group I can admit to actually having a Craftsman 101.07403 12x36 lathe and a 4x12 mini lathe. I'd love to hear from anyone trying or using AtomicELS, especially videos and pictures. Has anyone actually seen our great icon? It looks so much better than the Groups.io default elephant. Ralph
|
Installing Z stepper #Step Z
7
#step
I am slowly motorizing my lathe in order to use the AtomicELS or other ELS method. Here is my leadscrew end: https://photos.app.goo.gl/ywYz7pyUC4J5czRB7 And here is my adapter: https://photos.app.goo.gl/fwiNn4Kyekm65SYh7 I will be posting pictures of my attempt to mount the motor. Ralph
|
D1ck1es AtomicELS system build
6
Well I have built my control box, written the Nextion file to a Micro SD and attempted to load the sketch to the Mega. Comments and problems so far. 1 The sketch verify failed with "invalid operands double and int to binary operator %" After a read of the code I added an L to the end of my LSPM10 and LSPMM10 values in configuration.h The Sketch then loaded. 2 Nothing on the display! Then I thought maybe remove the Micro SD which I did. 3 I have a display but I mounted the Nextion upside down! No sure why as I checked a number of photos on the web as I found no info on the hardware itself. At the moment the whole front panel to my box is rotated. This is the first time that I have used a Nextion so I need to check to see if a command will invert the display. 4 No scrolling from the manual encoder. 5 No display of spindle RPM, display shows 0 when spindle running 6 No display of any position numbers. I need to start prodding and maybe get the scope out! D1cky
|
D1ck1es AtomicELS System build 2
16
I slightly changed the Subject so that we do not get a ridiculously long thread. OK after some time on the bench I have a near working system. The errors seen previously are now sorted The Upside down screen was sorted by changing the orientation in "Nextion Software - Device" to 270 degrees, compiling, re-writing the Micro SD then loading to Nextion (then removing!) The missing display of RPM was sorted by swapping the Serial connection to the Nextion. The schematic does not show the actual Nextion connections. The labelling on the connection to the schematic RX2 and TX2 refers to the Mega not the Nextion. Allowing the Nextion to actually talk to the Mega resolved the position display. The main problem seen was with the manual encoder. Initial very intermittent changes of pitch were seen rotating the knob. I examined my wiring and realised I had fitted 10K resistors not 1K - changed. Still problems so looked at code. No pullups seen on schematic so must be in the code - No. So software pullups added. Still problems! Examined code and found an error. void knobCheck(void) { //Check for encoder knob ticks if (knob_count) { feedSelect(feed_mode); nextionUseRPM(); } } Should really read as void knobCheck(void) { //Check for encoder knob ticks if (knobCount) { feedSelect(feed_mode); nextionUseRPM(); } } I also found a couple of other points I believe are errors but will check when running. Everything now works on the bench but I yet need to confirm the stepper signals are correct Richard
|
Touchscreen Calibration
33
On Mon, Sep 28, 2020 at 05:38 PM, Ralph Hulslander wrote: So are you supposed to touch the spot in the lower left corner? You have to touch each crosshair in turn as it moves from one corner to another. Not sure how it decides that it's calibrated, but it eventually reboots. I can't really tell whether it made a difference in mine, but I'm going to include it in the next version, just in case. I would like to avoid the power cycling, but it doesn't seem to send any acknowledgement that it's finished. I will probably have to add a power-up "READY" message on the Nextion side. -Jon
|