Teensy 3.6 - Interface a Microstep driver which uses 5V

[epicycloid]

@luni -- Apologies in advance for this long post, it grew as I tried to add the appropriate details...

Much earlier in this thread you asked about information / specific examples, so going back to revisit that I have two questions / requests...

1) We got a bit off track solving jpk's / jun's winder problem, but back around post #33 we were discussing using encoders for the example speed change. In your recent speed change video you opted to use a pot. I know you have a lot more experience with encoders than most of us ever will acquire, so I hope that when you do get a chance to go back to adding to your examples, that you will consider including a speed change variation using an encoder as well (the pot example is very useful, so I don't think they are mutually exclusive, and I learned about ResponsiveAnalogRead ).

2) You posted a video, which for the life of me I can't find now, but it had two apparently asynchronous motors moving, one running up and down on a vertical linear rail. Even without finding that video again, I think the motion of the linear stepper in your V2 Speed Override video might be the same motion. And perhaps this is somewhat related to frmdstryr's S-Curve problem and your Custom Acceleration Profile solution... I am having trouble wrapping my brain around what can or can't be done, or perhaps should or shouldn't be attempted with TeensyStep.

When frmdstyr mentioned engraving, you immediately said that was coordinated motion and redirected to grbl. Yet you move ("pump") the linear stepper in and out while the disc and pins are spinning in the Speed Override video.

Since I don't think we have seen the sample code for the movement of another motor, like the linear stepper, I am hoping you can add some more details / clarification to what can or can't (or shouldn't) be attempted with TeensyStep.

In my application, more complex but I didn't think too unlike jpk's winder problem, or I think frmdstyr's s-curve, requires one stepper to "oscillate," while the other rotates, but ultimately starting and ending in coordination (with of course the complication of "synching" the accelerations and decelerations at the beginning and end of the whole cycle). Like the winder problem, I need one motor to oscillate n times in m revolutions of the other motor.

The simplest case would be a sine function, oscillating say 48 times, while the other motor completes one revolution (or e.g. 100 revolutions driving a geared ratio to a spindle). One example of what I am describing is what I accomplish with mechanical "cams" (rosettes) today. You can see some examples here, which are all tied to the spindle and a single revolution per pattern. There are many more "functions" that I would like to implement well beyond the "cam" examples, but they provide an illustration for the problem.

I can easily imagine many other users of the library wanting to do similar things, that are much less sophisticated than jumping to multi-axis coordinated motion and g-code like grbl. The best one that comes to mind are the hundreds of people who have used AccelStepper to make camera sliders... imagine a camera slider with one motor driving the rail slide, while another is rotating the camera platform 360°, one or more times, during the linear motion travel. Exactly the motion I'm trying to accomplish, but different application / illustration.

I can't tell from your comments if the limitations in TeensyStep have to do with managing / coordinating the different acceleration profiles of the two motors? E.g. does your V2 Speed Override only work because there is no real mass involved in your system? Is your reservation about mechanical systems where the mass needs to be factored in, hence very different acceleration profiles? Or is there some other issue I'm not aware of?

Sorry, lots of questions but what I really am trying to ask / request is... is this something that TeensyStep is appropriate for, and if so, is this something you can include in your next round of examples? Or maybe even provide some real-world help with before the next examples are released?

--Jon

 

[luni]

Ok, lets answer that one by one

1) We got a bit off track solving jpk's / jun's winder problem, but back around post #33 we were discussing using encoders for the example speed change. In your recent speed change video you opted to use a pot. I know you have a lot more experience with encoders than most of us ever will acquire, so I hope that when you do get a chance to go back to adding to your examples, that you will consider including a speed change variation using an encoder as well (the pot example is very useful, so I don't think they are mutually exclusive, and I learned about ResponsiveAnalogRead ).

Using an encoder instead of a pot to read in the target speed should be straight forward but generating an example is a good idea indeed. I'll upload something on the weekend.

2) You posted a video, which for the life of me I can't find now, but it had two apparently asynchronous motors moving, one running up and down on a vertical linear rail. Even without finding that video again, I think the motion of the linear stepper in your V2 Speed Override video might be the same motion. And perhaps this is somewhat related to frmdstryr's S-Curve problem and your Custom Acceleration Profile solution...

You are probably looking for this video. The problem with the winder application was not so much a TeensyStep problem but a principal one. If you have one motor running with constant speed and the other one oscillating the concept of a simple synchronized movement is somehow not working. It has nothing to do with the acceleration profile (S-Curve, constant acceleration ...)

I am having trouble wrapping my brain around what can or can't be done, or perhaps should or shouldn't be attempted with TeensyStep.

TeensyStep basically is able to move a groups of motors synchronized from "point" A to "point" B. More than one group of motors can be moved in parallel. Additionally you can rotate a group of motors with fixed rotation speed ratios. If you want to do real CNC applications there are much better solutions like grbl. They take care of planning the motion between more than two points so that they usually do not stop when they arrive at point B but just "pass it on the fly". Difficult to explain but youtube is full of videos showing that (look for grbl motion planner or path planner)

When frmdstyr mentioned engraving, you immediately said that was coordinated motion and redirected to grbl. Yet you move ("pump") the linear stepper in and out while the disc and pins are spinning in the Speed Override video.

You are probably referring to this video

The video shows synchronized and unsynchronized movements. The pumping movment of the linear motor is not synchronized to the movement of the disk and the pins. Synchronized movement of pins and disk starts at 0:58. The synchronization which starts at 0:43 is done by a simple PID regulator (P only in fact) From the TeensyStep point of view the movement is done by two unsychronized controllers.

In my application, more complex but I didn't think too unlike jpk's winder problem, or I think frmdstyr's s-curve, requires one stepper to "oscillate," while the other rotates, but ultimately starting and ending in coordination (with of course the complication of "synching" the accelerations and decelerations at the beginning and end of the whole cycle). Like the winder problem, I need one motor to oscillate n times in m revolutions of the other motor.

The simplest case would be a sine function, oscillating say 48 times, while the other motor completes one revolution (or e.g. 100 revolutions driving a geared ratio to a spindle). One example of what I am describing is what I accomplish with mechanical "cams" (rosettes) today. You can see some examples here, which are all tied to the spindle and a single revolution per pattern. There are many more "functions" that I would like to implement well beyond the "cam" examples, but they provide an illustration for the problem.

They look nice. To achieve this you probably need very tight control of the positions of both motors at any time. Currently you could try to implement a very stiff PID controller regulating the speed according to pre-calculated paths. But this will be quite demanding. I plan to add a feature to change the motor position on the fly, this would be much better suited for such applications. But this will need to wait for a couple of month I'm afraid.

I can't tell from your comments if the limitations in TeensyStep have to do with managing / coordinating the different acceleration profiles of the two motors? E.g. does your V2 Speed Override only work because there is no real mass involved in your system? Is your reservation about mechanical systems where the mass needs to be factored in, hence very different acceleration profiles? Or is there some other issue I'm not aware of?

The Speed Override example has nothing to do with acceleration profiles or the moved masses. I don't have any "reservation" using TeensyStep for any application. But I think each tool has it's advantages. TeensyStep is fast, easy to use, and a good choice if you need to position things. Here a typical real life application (in fact this was the application I developed the library for originally)

but if it comes to control a CNC machine there are better tools like e.g. grbl https://www.youtube.com/watch?v=tl6nF-bq6WQ

Hope that helps. Just play around a bit you will quickly get a feeling for what is possible and what not

 

[luni]

I had a closer look at your web page and the machines. This is really interesting. If you can wait for the "change position on the fly" feature this might be exactly what you need for this.

 

[epicycloid]

Thank you for the thoughtful and detailed reply.

Using an encoder instead of a pot to read in the target speed should be straight forward but generating an example is a good idea indeed. I'll upload something on the weekend.

I appreciate that, and I hope others will too. Encoders can be confusing for many of us. I can get them to work, but I'm always hanging by a thread.

You are probably looking for this video.

Yes, exactly. That was the one. Thank you.

TeensyStep basically is able to move a groups of motors synchronized from "point" A to "point" B. More than one group of motors can be moved in parallel.

This is where I was /am confused. Because I haven't seen how you implemented the above winder video, or the code behind the V2 Speed Override, I couldn't tell if the motors were synchronized (which I suspected, but didn't know how), or parallel, via a second controller (if that's what you mean by parallel?).

If you want to do real CNC applications there are much better solutions like grbl. They take care of planning the motion between more than two points so that they usually do not stop when they arrive at point B but just "pass it on the fly". Difficult to explain but youtube is full of videos showing that (look for grbl motion planner or path planner)

I am familiar with trajectory planners, CNC, grbl, and others. grbl's shortcoming in my application, if I were to go the CNC / g-code route, is the lack of support for rotary axes, and G93 inverse time mode in particular, which allows rotary axes to "play well" with linear coordinated motion. Other projects, like Synthetos' G2 Core might solve that issue, but then there has to be approachable design software (CAD and CAM) to create the design and generate the rotary g-code... non-trivial for mere mortals to approach.

The video shows synchronized and unsynchronized movements. The pumping movment of the linear motor is not synchronized to the movement of the disk and the pins. Synchronized movement of pins and disk starts at 0:58. The synchronization which starts at 0:43 is done by a simple PID regulator (P only in fact) From the TeensyStep point of view the movement is done by two unsychronized controllers.

And this answers the question, the PID is what brings them into sync. That is what I think I want to see in a sample, even if i doesn't apply to my specific case, it will be useful for other things.

They look nice. To achieve this you probably need very tight control of the positions of both motors at any time. Currently you could try to implement a very stiff PID controller regulating the speed according to pre-calculated paths. But this will be quite demanding. I plan to add a feature to change the motor position on the fly, this would be much better suited for such applications. But this will need to wait for a couple of month I'm afraid.

Thank you. The one thing not obvious, and why my application differs from many others (except perhaps camera sliders) is that the work we do on these lathes is at very low speeds, picture the spindle running at 3 RPM. The headstock of the cam (rosette) modulated lathe "rocks" the workpiece into and out of a (relatively) stationary fly cutter that removes the wood (at about router spindle speeds).

I am able to do this today using AccelStepper, by pre-calculating the number of steps in the entire path for each of the two motors (using his acceleration and speed equations), and then I do the math to evenly distribute (insert) the steps of the slower (shorter target) motor in between steps of the faster (longer target) motor. Sort of a simple Bresenham-like approach, but with the underlying timers (managed by AccelStepper for me) sorting out the actual profile of the ramps.

I can't quite picture how you envision the new feature for changing motor position on the fly, but clearly you see what I'm trying to do, and think your solution will apply, so I will wait patiently.

Here a typical real life application (in fact this was the application I developed the library for originally)

That's a great positioning example, and clearly shows where your thought process came from that led to the library. Now the rest of us are trying to twist you in different directions.

but if it comes to control a CNC machine there are better tools like e.g. grbl https://www.youtube.com/watch?v=tl6nF-bq6WQ

Of course you would select a grbl rotary wrapping video as the example, just to counter my previous example of grbl's one shortcoming. That said, the example in the video is wrapped by software using Vectric's Aspire, which a lot of people see and wrongly assume grbl can handle natively.

I had a closer look at your web page and the machines. This is really interesting. If you can wait for the "change position on the fly" feature this might be exactly what you need for this.

I am making things work right now with AccelStepper, but with some challenges. I am in no immediate hurry, and I have a lot of learning with TeensyStep.

I will write some code and make some "building blocks" to experiment and learn the ins and outs. I ordered some of your DRV8825x3 boards, and will use those as a test bed, so I know I have an identical setup. Thank you again for your library, patience, and helpful feedback and direction.

--Jon

P.S. If you are anywhere near Dresden, you can see spectacular examples of this style of turning in ivory in the Grünes Gewölbe.

 

[luni]

By showing me your machine you somehow hit my sweet spot Had a look at some videos showing those machines in action and think that I understand the principle now. At least for the headstock rocking. The structure in z-direction is done manually by the operator, correct?

I was thinking how I would solve that and have some ideas which will not involve weeks of programming effort but I want to do a few tests first.

Questions:

• How do you plan to do the CAM part? Will the "electronic rosettes" be described by functions or will you supply tabulated spindle-angle vs headstock-deflection data.
• For cusps in your rosettes in principle the headstock needs to accelerate very quickly, using steppers instead of the mechanical solution those cusps will be smeared out somehow. Would that be a problem?

If you are anywhere near Dresden, you can see spectacular examples of this style of turning in ivory in the Grünes Gewölbe.

My daughter happens to study in Leipzig, so Dresden is on the way from Bavaria. I try to have a stopover next time I visit her.

 

[epicycloid]

By showing me your machine you somehow hit my sweet spot

I cannot be held responsible for any addictions I may create.

The structure in z-direction is done manually by the operator, correct?

As this is quite an old art form / hobby, you can imagine there are many machine variations, but yes in general (traditional) Z and X are manual. On most machines the slide can also be rotated, so work can be along the cylinder, or across the "face" or end of the cylinder.

My goal is more of a "hybrid machine" where the operator is still in "artistic control" but the dreary parts (indexing, feed, and gear ratios for helices) are virtual / electronic.

I was thinking how I would solve that and have some ideas which will not involve weeks of programming effort but I want to do a few tests first.

I tried to send you a .pdf by PM. The case I used as an illustration (cams / rosettes) is the simplest case, but shows the concept. Once you have steppers on the spindle and slide, virtual gear ratios are available to enable spirals / helices (and even threading). The more complex patterns, by oscillating the sliderest, when combined with the spindle rotations, produces looped patterns. And obviously oscillating the spindle while moving the slide creates what we call "reciprocation," or sine waves along the cylinder (or wrapped around the cylinder if the slide oscillates while the spindle rotates). I could go on, but I'm sure you see the permutations and possibilities.

How do you plan to do the CAM part?

The goal is not to do CAM, this is for mere mortals to use artistically. And in fact to not have a computer, but instead "canned functions" via a touchscreen (https://nextion.itead.cc) and the Teensy (T3.2's and/or T3.5's?). I will try again to PM you a conceptual document I created.

Will the "electronic rosettes" be described by functions or will you supply tabulated spindle-angle vs headstock-deflection data.

The current hybrid implementation is mechanical for the rosettes, with the slide and spindle under stepper control (for these specific machines). But, surprise, surprise, most of us have more than one machine, and I want to build / modify to virtualize the rosettes too (among other functions), but that may quickly exceed the Teensy / touchscreen / UI memory and complexity limits... the "slippery slope" as I refer to it.

For cusps in your rosettes in principle the headstock needs to accelerate very quickly, using steppers instead of the mechanical solution those cusps will be smeared out somehow. Would that be a problem?

Remember these machines are going very slowly, 3 RPM or less on the spindle is typical. I am sure there will be trade-offs on some of the patterns / rosettes, but as we are approaching this incrementally, initially via a mechanical / electronic hybrid, the rosettes can remain mechanical until the "cusp" problem is solved. That may be the part of the problem that pushes over the slippery slope to require a computer (or dedicated motion controller that can take geometry vs. g-code) instead of the Teensy, mainly for trajectory planning.

More later... I need to board a plane.

--Jon

My daughter happens to study in Leipzig, so Dresden is on the way from Bavaria. I try to have a stopover next time I visit her.

The "ultimate collection" was sacked from Saxe-Coburg and resides in the Silver Palace in Florence, for your next trip abroad.