Low-level library and timer assistance -- TeensyStep library ???
- Thread starter epicycloid
- Start date
epicycloid
Well-known member
Joe -- To elaborate a bit on what Ed just replied, you can see some of the screens that the users of our system interact with, to change settings with respect to the multiple steppers, coordinating the motions, and then making the cuts on the lathe(s).
Here's a link to the controller's screen descriptions...
Nextion Multiple Stepper Control Screen Descriptions
The Nextion touchscreen is a serial device, talking bi-directionally with the Teensy, which then, via TeensyStep library, manages the coordinated motion of the motors.
If you're familiar with them, think of a CNC system, but instead of CAM software generating g-codes, we manage a bunch of "canned functions" via the touchscreen interface, and the user can adjust parameters prior to running a cut / process. Our setup would be somewhat like a "conversational controller" on a CNC machine these days.
Hope that helps a bit,
--Jon
Here's a link to the controller's screen descriptions...
Nextion Multiple Stepper Control Screen Descriptions
The Nextion touchscreen is a serial device, talking bi-directionally with the Teensy, which then, via TeensyStep library, manages the coordinated motion of the motors.
If you're familiar with them, think of a CNC system, but instead of CAM software generating g-codes, we manage a bunch of "canned functions" via the touchscreen interface, and the user can adjust parameters prior to running a cut / process. Our setup would be somewhat like a "conversational controller" on a CNC machine these days.
Hope that helps a bit,
--Jon
joepasquariello
Well-known member
Yes, it does, thanks. I know he already said he hasn't found a repeatable set of actions that causes a crash, but perhaps he will.
Hi Jon,
because I find your application very interesting I am still following this thread. May I ask some questions?
Do I understand correctly, that there is already a prototype version of the control software for the rose lathe, that uses the TeensyStep4 library?
(((It is interesting to see, that the TeensyStep4 library works in a way similar to the one I suggested. I have the impression, that some difficulties might arise from the fact, that the original control program and also the original library seem to be centred around SPEEDS and their relations. (Edit: I have now seen, that absolute position is even reset before starting a movement. And that speeds are indeed changed dynamically.) The T4 library is using Bresenham and is therefore fixed to linear movements between POSITIONS. And the leading axis is not allowed to change during one movement. I would assume, that problems can arise from dynamically switching dependency of axis and/or speeds. I would split all movements into very short linear movements. This will mean, that the influence of acceleration will diminish. During one of these movements all axis can be handled as dependant.
Also it seems that float or double variables are used. I would recommend to use integers for all position data to be sure, that errors do not sum up. )))
The software seems to be capable to do the radial movements, so you actually don't need the Swinging Headstock with the Rosettes any more?
And one curious question: How do you handle backlash of the axis? (((In the software for my little lathe, where I also do not have ball screws, I have constants for backlash travel, which works quite well, as long as friction is high in relation to working force.)))
@joepasquariello , I am well aware, that it is you, who has given real help here, while my comments are not much of practical use. Great!
Cheers and good luck! Christof
P.S. Perhaps I should repeat my suggestion to use Teensy threads library here, because with this, the handling of the user interface can be somewhat separated from movements. Or some layer of software could be inserted to go from SPEEDS to POSITIONS.
Last edited:
joepasquariello
Well-known member
TeensyStep4, like TeensyStep, provides methods for reaching and holding a given speed, or moving a specific number of steps. In both cases, Bresenham is used to rotate or move multiple motors in fixed ratios. In terms of computing resources, Bresenham allows generation of steps to multiple motors from a single timer.
epicycloid
Well-known member
Hi Christof -- Of course you can ask questions. Isn't that why we're all here? 
Ed / @Elf has taken down his develop branch with the T4.1 work in progress, but he is working on the T4.1 version privately. I think because it is in such a state of experimentation, and not really close enough to call a beta, it is easier for changes and testing to not have the experimental version out there.
What I think I tried to say before was that your suggestions are good ones, but at least for the time being we're trying to preserve the huge amount of complicated code, rather than re-writing from scratch. Our conundrum is really because we got caught between a broken library, and an incomplete replacement (and a chip shortage, and architectural timer changes, etc.).
The speeds, as you now see, are dynamic. Most of the functions are designed around coordinating the motion of two or more motors, and the original library is very good at that. Hard to say with the replacement right now. Joe's fixes seem like they are helping that along... ongoing testing.
The whole concept for the lathes is based on the historical "rocking headstock and rosettes" design. Most of the lathes using the controller are electro-mechanical, and generate patterns from the rosettes (cams). While the lathes have multiple motors, there is no requirement for their sliderests / cross slides to be parallel to the spindle axis, or orthogonal to one another (X and Z). Some are, some aren't. So in use, a lot of the setup is a manual process to position the cutters and workpiece, then, when ready, begin a coordinated movement with the various motors. Quite a few of the lathes use MagSwitches on a steel top, to allow positioning the sliderests arbitrarily on the lathe bed.
For this project, the goal was to retain the manual interaction, and the physical rosettes for their geometric patterns. But there are other designs out there, where the rosettes have been "virtualized", typically therefore requiring the sliderest stages to be orthogonal. You can look at COrnLathe and Embellished Turnings or the new-ish LatheEngraver for examples of those kids of configurations. Typically g-code based. Each of those has related GitHub repositories. Let me know if you can't find them. (One of the early pioneers, Dewey Garrett's site seems to not respond at the moment.)
This project was envisioned as a way to make complicated patterns seem approachable, especially to artistically-oriented users, as opposed to mathematically- or tech-oriented users. Hence the easy to understand touchscreen, no computer per se, and relatively little technical knowledge required to use the system. But, as with any project like this, where you're tasked with "hiding the complexity under the hood", it is often harder to do than most people realize, e.g. it can be very difficult to make things look easy.
Because this is a "hands-on" system (as opposed to CNC), most backlash is dealt with in the same way an experienced machinist would approach it on a manual machine... when you are preparing to make a cut, you back out far enough, so that you can turn in the desired direction, taking up the backlash before you reach the workpiece / start of your cut, and then lead into your cut, with the leadscrew already having removed all the backlash before you entered the cut. Reverse by retracting the cutter, backing out further than where you need to start, and repeat, leading into the cut again while taking up the backlash on your way to starting the actual cut again.
I am sure the Teensy Threads library would work perfectly, if we were starting over from scratch. Other options might have worked as well, like the very good AccelStepper library, which we experimented with early on, before @luni introduced TeensyStep.
Hopefully that answers most your questions,
--Jon
Ed / @Elf has taken down his develop branch with the T4.1 work in progress, but he is working on the T4.1 version privately. I think because it is in such a state of experimentation, and not really close enough to call a beta, it is easier for changes and testing to not have the experimental version out there.
What I think I tried to say before was that your suggestions are good ones, but at least for the time being we're trying to preserve the huge amount of complicated code, rather than re-writing from scratch. Our conundrum is really because we got caught between a broken library, and an incomplete replacement (and a chip shortage, and architectural timer changes, etc.).
The speeds, as you now see, are dynamic. Most of the functions are designed around coordinating the motion of two or more motors, and the original library is very good at that. Hard to say with the replacement right now. Joe's fixes seem like they are helping that along... ongoing testing.
The whole concept for the lathes is based on the historical "rocking headstock and rosettes" design. Most of the lathes using the controller are electro-mechanical, and generate patterns from the rosettes (cams). While the lathes have multiple motors, there is no requirement for their sliderests / cross slides to be parallel to the spindle axis, or orthogonal to one another (X and Z). Some are, some aren't. So in use, a lot of the setup is a manual process to position the cutters and workpiece, then, when ready, begin a coordinated movement with the various motors. Quite a few of the lathes use MagSwitches on a steel top, to allow positioning the sliderests arbitrarily on the lathe bed.
For this project, the goal was to retain the manual interaction, and the physical rosettes for their geometric patterns. But there are other designs out there, where the rosettes have been "virtualized", typically therefore requiring the sliderest stages to be orthogonal. You can look at COrnLathe and Embellished Turnings or the new-ish LatheEngraver for examples of those kids of configurations. Typically g-code based. Each of those has related GitHub repositories. Let me know if you can't find them. (One of the early pioneers, Dewey Garrett's site seems to not respond at the moment.)
This project was envisioned as a way to make complicated patterns seem approachable, especially to artistically-oriented users, as opposed to mathematically- or tech-oriented users. Hence the easy to understand touchscreen, no computer per se, and relatively little technical knowledge required to use the system. But, as with any project like this, where you're tasked with "hiding the complexity under the hood", it is often harder to do than most people realize, e.g. it can be very difficult to make things look easy.
Because this is a "hands-on" system (as opposed to CNC), most backlash is dealt with in the same way an experienced machinist would approach it on a manual machine... when you are preparing to make a cut, you back out far enough, so that you can turn in the desired direction, taking up the backlash before you reach the workpiece / start of your cut, and then lead into your cut, with the leadscrew already having removed all the backlash before you entered the cut. Reverse by retracting the cutter, backing out further than where you need to start, and repeat, leading into the cut again while taking up the backlash on your way to starting the actual cut again.
I am sure the Teensy Threads library would work perfectly, if we were starting over from scratch. Other options might have worked as well, like the very good AccelStepper library, which we experimented with early on, before @luni introduced TeensyStep.
Hopefully that answers most your questions,
--Jon
Thank you for your explanations and for the interesting links! ChristofHi Christof -- Of course you can ask questions. Isn't that why we're all here?
Ed / @Elf has taken down his develop branch with the T4.1 work in progress, but he is working on the T4.1 version privately. I think because it is in such a state of experimentation, and not really close enough to call a beta, it is easier for changes and testing to not have the experimental version out there.
What I think I tried to say before was that your suggestions are good ones, but at least for the time being we're trying to preserve the huge amount of complicated code, rather than re-writing from scratch. Our conundrum is really because we got caught between a broken library, and an incomplete replacement (and a chip shortage, and architectural timer changes, etc.).
The speeds, as you now see, are dynamic. Most of the functions are designed around coordinating the motion of two or more motors, and the original library is very good at that. Hard to say with the replacement right now. Joe's fixes seem like they are helping that along... ongoing testing.
The whole concept for the lathes is based on the historical "rocking headstock and rosettes" design. Most of the lathes using the controller are electro-mechanical, and generate patterns from the rosettes (cams). While the lathes have multiple motors, there is no requirement for their sliderests / cross slides to be parallel to the spindle axis, or orthogonal to one another (X and Z). Some are, some aren't. So in use, a lot of the setup is a manual process to position the cutters and workpiece, then, when ready, begin a coordinated movement with the various motors. Quite a few of the lathes use MagSwitches on a steel top, to allow positioning the sliderests arbitrarily on the lathe bed.
For this project, the goal was to retain the manual interaction, and the physical rosettes for their geometric patterns. But there are other designs out there, where the rosettes have been "virtualized", typically therefore requiring the sliderest stages to be orthogonal. You can look at COrnLathe and Embellished Turnings or the new-ish LatheEngraver for examples of those kids of configurations. Typically g-code based. Each of those has related GitHub repositories. Let me know if you can't find them. (One of the early pioneers, Dewey Garrett's site seems to not respond at the moment.)
This project was envisioned as a way to make complicated patterns seem approachable, especially to artistically-oriented users, as opposed to mathematically- or tech-oriented users. Hence the easy to understand touchscreen, no computer per se, and relatively little technical knowledge required to use the system. But, as with any project like this, where you're tasked with "hiding the complexity under the hood", it is often harder to do than most people realize, e.g. it can be very difficult to make things look easy.
Because this is a "hands-on" system (as opposed to CNC), most backlash is dealt with in the same way an experienced machinist would approach it on a manual machine... when you are preparing to make a cut, you back out far enough, so that you can turn in the desired direction, taking up the backlash before you reach the workpiece / start of your cut, and then lead into your cut, with the leadscrew already having removed all the backlash before you entered the cut. Reverse by retracting the cutter, backing out further than where you need to start, and repeat, leading into the cut again while taking up the backlash on your way to starting the actual cut again.
I am sure the Teensy Threads library would work perfectly, if we were starting over from scratch. Other options might have worked as well, like the very good AccelStepper library, which we experimented with early on, before @luni introduced TeensyStep.
Hopefully that answers most your questions,
--Jon