Ken> We would create a stepper driver object for multiple motors allowing step, direction, speed and ramping.
I'm Looking forward to it. I'm curious about the implementation details. Does this mean I should start a new discussion about my own ideas or should I keep posting here?
Cluso> There are now better drivers than the A4988
Sure. But the A4988 is cheap and small. I think the bare chip is <$1 and it should be sufficient for small motors up to NEMA17. If you know better drivers that are also cheap and easy to handle please tell us.
The "silent" drivers that are popular is the Trinamic ones, they are hardware compatible, pololu and others make boards with the chip(s) on them that plug in to the same sockets as their 4988 boards. The only difference is in software that configures the config pins, which is trivial to handle in the driver via a param at startup.
They still work with the same step/dir/enable pins during operation. So this driver project should work with most of them also, just need the different initial config pin setup handling.
TMC2100, TMC2130, & TMC2208 are the things to search for on Amazon to buy them.
Some of the chips in the Trinamic line can also be configured via SPI or UART (but they still can be configured by the config pins).
Perfect. The trinamic boards cost about twice as much (~$10 instead of $5 for the A4988). But if they are pin compatible then everybody can decide if they want to upgrade. I think the A4988 is still enough for small demo setups. For "real" machines I'd prefer larger drives with more amperes, anyway.
Next question: How should the front end (the interface to the G-code parser) look like? I'd prefer using float numbers and real world units (mm or inches) instead of steps. This makes length, speed and acceleration calculations easy and it's no problem if some axes have different resolutions. Of course, the step/dir driver uses fixed point math internally.
Unfortunatelly, float math looks ugly in Spin. You have to write c:= fm.Mul(a,b) instead of c:= a*b. That's why I prefer writing all high level code in C.
It has all the fancy stuff like lookahead trajectory planner, feed override, low jitter high speed step signals with sub-pixel resolution and so on. But that one includes several man-years of development and I won't make that open source. It would be far too complex for an education project, anyway.
But what I talk about in the posts above is meant to help the P2 community and will be open-source. The idea is to make something less complex as my commercial products but still more powerful than the average GRBL Arduino stuff.
Robots are a completely different thing. Ken was talking about CNC applications and G-code. That is something pre-computed by a CAM software or slicer on a PC, typically, and read from a filesystem on an SD card or USB stick. Surely, the P2 could also control a robot. But that's not what wer're heading for in this discussion, I think.
I have made all sorts of devices - great for education- rubbish for industrial; from threaded rod and steppers recovered from scrap printers which allow the student to experiment with software algorithms to their hearts content.
So perhaps two paths- maybe using the same code- one on economical parts and the other aimed at industry.
((Ah, New Forum Software, how can I switch off the numbering?))
What is nice, is the GRBL interface to the software on the PC, I use GRBLcontrol Candle.exe. It would be nice if this new software would be working with the same control Programs.
The functionality of GRBL is very much advanced over some educational code, I think. I am not sure, if educational code should use Pasm. I don't really think, that Pasm is needed in the beginning to drive step motors. At least my P1, which controls my small lathe can do the linear interpolation with only one cog and with Tachyon.
I don't think it's Parallax' job to provide gear for industrial machines. It's important to have something to start with. If you need something bigger you can buy it elswhere as you see fit. If the quality of the signals is good you can control any size of motor you like, even a 15kW Siemens or Yaskawa servo.
"Simple things must be simple. Complex things should be possible" (author unknown)
PUB Start (pin1, rx, ry, rz, ra)
' Sets the base pin and resolutions for all axes in steps/unit (float).
PUB WaitEndMove ()
' Waits until all moves are completed
PUB SetVelocity (v)
' input: v = velocity in units/s (float)
PUB SetAcceleration (a)
' input: v = velocity in units/s² (float)
PUB AddLinMove (x, y, z, a)
' Moves from the last position (end point of previous move)
' to the coordinates (x,y,z,a) in units (float) on a straight
' line. Can be called at any time even when the machine is
' still moving. In this case the line segments are concatenated
' seamlessly. It's the callers responsibility to check if
' the resulting jerk (acceleration peak caused by sudden direction
' change) is acceptable or if there's a risk that the motors
' will stall. If the lines form a right angle or sharp bend
' WaitEndMove() should be called in between to insert
' braking/acceleration ramps.
PUB AddCircMove (x, y, z, a, cx, cy, cw)
' Moves from the last position (end point of previous move)
' to the coordinates (x,y,z,a) in units (float) on a circular
' or helical (if z differs) curve. Can be called at any time.
' (cx,cy) defines the center point. It's the callers
' responsibility to check if transitions to preceeding/following
' lines are continous and the distance from the center to both end
' points (=radius) are equal. Z and a are interpolated linearly.
' Turns clockwise if cw==true, counterclockwise if cw==false.
PUB AbortMove ()
' Ramps down and stops as soon as possible, clears the
' remaining (buffered) moves.
PUB GetActPosition (): x, y, z, a
' return the current position of all axes in units (float)
' Exact only if moves are completed
Edit: forgot cw/ccw flag for AddCircMove()
Edit2: added AbortMove() and GetActPosition()
Disclaimer: I don't promise to implement all features at once.😇
I'm following this VERY closely and I'm liking what you are proposing here, ManAtWork. Keep it simple on the front-end (so things can be quickly assembled and tested on the bench with just a few lines of user code), and then allow for deeper learning and adjustments as we climb-up the learning curve.
These recent posts encompass exactly the right vision, I believe. The contributions from @ManAtWork, @JRoark, @tritonium, @iseries, and @Roy Eltham give us a good starting point. I think we can use the @ManAtWork user interface as written, too.
As far as Parallax having some hardware on hand and in stock, it's just for educational and demonstration purposes. Because we're working with steppers, the same code should be able to run much larger motors, geared down for CNC conversions. As for demo, I'd probably get some NEMA17 motors attached to ballscrew slides just to demonstrate the code example.
Current plan is to ask @JonnyMac to write this object, unless somebody else jumps in to accomplish it within 10 days from now. I'd like this one posted by the second week of February.
As for demo, I'd probably get some NEMA17 motors attached to ballscrew slides just to demonstrate the code example.
It might also be possible to buy a cheap 3D printer (or use a broken one), rip apart the extruder and replace it with a pen. This can be used to draw figures on paper for demonstration. It's better than separate ball screw slides because you can also demonstrate circular moves. Or you could build a simple pick&place machine with a solenoid magnet to lift and drop screw nuts or other iron pieces.
I think I could also write some code but I have nothing against some help from Jon if he wants to join. As my nickname says I'm always busy 😄 and 10 days is quite a tight schedule. I can surely put up something that at least moves around a bit but I can't promise to finish every detail.
Thinking out loud here: A cheap X/Y/Z positioner with an electromagnet for a “gripper”, and a Checkers board with metal pieces would be grand mischief! Put a webcam on it and let ‘er rip 24/7. All controlled by a single Prop that plays both sides AND does the positioning AND has a display for the stats.
On P2 the smart pin Quadcounters are essentially free, so it makes sense to allow for a Encoder input, even if just for testing verification, and those intent on shaving the last cents on their high volume consumer designs can leave off the encoders, when they have proven there are no missing steps.
Useful P2 pin modes for checking and verify would be
%01011 = A/B-input quadrature encoder
%01101 = Accumulate A-input positive edges with B-input supplying increment (B=1) or decrement (B=0)
The second mode could clip-onto the Step & DIR outputs commonly used to feed simple steppers, to keep track of what actually came out of P2.
Yes, I agree that it's good to have the option to connect encoders. And because it's easy with the P2 and demonstrates its capabilities we should go for it. But I have to repeat that "stepper systems are always sensible to lost steps" and "closed loop systems are the cure" are both myths. There are so many reasons for "lost steps":
Bad step signal timing (dir setup/hold violations, low pulse width, jitter)
EMI problems (interference adds ghost steps)
acceleration peaks caused by bad trajectory calculation
excess mechanical friction (+ lack of power/budget)
software bugs
Adding feedback adds complexity. And it avoids only some of the problems listed above and even adds some new ones. If, for example, the encoder cables are long and not properly shielded the risk of loosing steps are actually increasing instead of decreasing because the encoder signals are also susceptible to EMI.
I don't vote against encoder is general. I just say you have to be careful. Encoder feedback makes well designed systems better but it can make crappy systems worse and it's not the cure to all problems.
... All controlled by a single Prop that plays both sides AND does the positioning AND has a display for the stats.
Yes, brilliant. I just realized that controlling 4 (or even more) stepper motors only takes one cog and 8 pins of the P2. So we have plenty of resopurces left to do it several times concurrently plus some fancy display and blinkenlights.
I've just seen the announcement "Stepper Motor fun with JonnyMac" on March 10th. Very good!
This brings back the chance that I'll also have something to show by that date. I've been busy with lot's of urgent orders the last days and the 10 days deadline was way too short.
@ManAtWork said:
I've just seen the announcement "Stepper Motor fun with JonnyMac" on March 10th. Very good!
This brings back the chance that I'll also have something to show by that date. I've been busy with lot's of urgent orders the last days and the 10 days deadline was way too short.
We'd really like that! Get those orders done, and get some stepper action started. I'd be pleased to post some objects as Quick Bytes, too! Anything you'd like to share is welcome at the P2 Live Forums, too.
Ken Gracey
For me, if I can't verify that a command has been successfully executed...I am not in "control".
This applies to something as simple as a 2-position actuator, I have sensors to verify that the actuator is where it's supposed to be.
The same would apply to a stepper motor; not reaching desired/commanded position might be caused by an obstruction and nothing to do with motor/drive performance. I think students will quickly see the benefits of this and would compare it favourably with other MCUs that don't have this capability.
but a gd interpolator only determines the present positon on each axis...present velocity of each axis and how far along u are.
remember...u may need to slave an axis
by making mine with an adjustable feedrate i can just ramp up to feed...and by knowing how long it took to get up to speed i was able ramp down...to create a trapoazodial accel and decel ramp
if ur using encoders u can u use the interpolated position with a pid and pwm to control a bridge
if ur using steppers u use ur error to adjust ur step signal
i threw my steppers out a week after i got them (they were nema 34, just couldnt be trusted) and switched to gearhead motors with encoders on from polulu.....it was easy to jam my machine and error it out...u cant do that with only steppers
Yes, in 40 years, my only involvement with steppers was ripping them off a machine and throwing them in the bin. I should be thankful because this is exactly what put me in business, back in the 80's.
I don't advocate the use of steppers but if that's what's required, at least put a feedback device on there so you're not running blind.
Edit: "slaving an axis"... Good point! I do this all the time and with a variable gearing ratio.
It's been quiet for a while, here. I was very busy the last week. But I finally had some time for programming, today. The basic concept of what I proposed in post #24 is working:
lookahead buffer management
linear interpolator
S-shaped ramp generator
projection of scalar (ramp output) to vector (trajectory coordinates)
I don't post any code, yet, because it doesn't produce anything useful so far except long debug hex dumps. Circular interpolation is also still missing. But I hope I can come up with a demo that shows some real mechanics moving, soon.
Here is a short simple program to demonstrate CNC interpolation and stepper motor step generation.
If is far from perfect, but it's small size and simplistic (somewhat) nature make it easy to follow.
You need to run it in PNut because it uses debug graphics.
I haven't tested the stepper pulse output.
Comments
Ken> We would create a stepper driver object for multiple motors allowing step, direction, speed and ramping.
I'm Looking forward to it. I'm curious about the implementation details. Does this mean I should start a new discussion about my own ideas or should I keep posting here?
Cluso> There are now better drivers than the A4988
Sure. But the A4988 is cheap and small. I think the bare chip is <$1 and it should be sufficient for small motors up to NEMA17. If you know better drivers that are also cheap and easy to handle please tell us.
Cluso99,
The "silent" drivers that are popular is the Trinamic ones, they are hardware compatible, pololu and others make boards with the chip(s) on them that plug in to the same sockets as their 4988 boards. The only difference is in software that configures the config pins, which is trivial to handle in the driver via a param at startup.
They still work with the same step/dir/enable pins during operation. So this driver project should work with most of them also, just need the different initial config pin setup handling.
TMC2100, TMC2130, & TMC2208 are the things to search for on Amazon to buy them.
Some of the chips in the Trinamic line can also be configured via SPI or UART (but they still can be configured by the config pins).
Perfect. The trinamic boards cost about twice as much (~$10 instead of $5 for the A4988). But if they are pin compatible then everybody can decide if they want to upgrade. I think the A4988 is still enough for small demo setups. For "real" machines I'd prefer larger drives with more amperes, anyway.
Next question: How should the front end (the interface to the G-code parser) look like? I'd prefer using float numbers and real world units (mm or inches) instead of steps. This makes length, speed and acceleration calculations easy and it's no problem if some axes have different resolutions. Of course, the step/dir driver uses fixed point math internally.
Unfortunatelly, float math looks ugly in Spin. You have to write
c:= fm.Mul(a,b)instead ofc:= a*b. That's why I prefer writing all high level code in C.If your going this route then I think you should look at this product and maybe can produce your own version of it. These guys did a really nice job.
B-ROBOT EVO 2. Much more than a self balancing robot > jjrobots
Mike
No, I don't want to make a product out of it, at least not this time. I already have several products, servo drives, stepper drives (high power) and motion controllers, all based on the P1. For example: https://www.sorotec.de/shop/6-Axis-Interface-board-with-Network-Interface-for-Beamicon2.html
It has all the fancy stuff like lookahead trajectory planner, feed override, low jitter high speed step signals with sub-pixel resolution and so on. But that one includes several man-years of development and I won't make that open source. It would be far too complex for an education project, anyway.
But what I talk about in the posts above is meant to help the P2 community and will be open-source. The idea is to make something less complex as my commercial products but still more powerful than the average GRBL Arduino stuff.
So were suppose to buy a NEMA17 motor and attach a flag to it and what it go around?
We need to build a NEMA BOT, P2 BOT or EDGE BOT so that it can move around or something.
Mike
Robots are a completely different thing. Ken was talking about CNC applications and G-code. That is something pre-computed by a CAM software or slicer on a PC, typically, and read from a filesystem on an SD card or USB stick. Surely, the P2 could also control a robot. But that's not what wer're heading for in this discussion, I think.
Hi
Is this for industrial or educational use? If industrial then go for top spec devices.
In my part of the world educational spend is limited.
It seems to me that spending £5 for a 4988 stepper is irrational if you can get 5 of them for the same price locally, within 3-5 days of ordering.
5Pcs A4988 Driver Module StepStick Board Stepper Motor For Reprap 3D Printer ·UK | eBay
I have made all sorts of devices - great for education- rubbish for industrial; from threaded rod and steppers recovered from scrap printers which allow the student to experiment with software algorithms to their hearts content.
So perhaps two paths- maybe using the same code- one on economical parts and the other aimed at industry.
Dave
Hi, ManAtWork,
what I miss at my little mill with GRBL:
I don't think it's Parallax' job to provide gear for industrial machines. It's important to have something to start with. If you need something bigger you can buy it elswhere as you see fit. If the quality of the signals is good you can control any size of motor you like, even a 15kW Siemens or Yaskawa servo.
"Simple things must be simple. Complex things should be possible" (author unknown)
Proposal for the front end interface:
Edit: forgot cw/ccw flag for AddCircMove()
Edit2: added AbortMove() and GetActPosition()
Disclaimer: I don't promise to implement all features at once.😇
I'm following this VERY closely and I'm liking what you are proposing here, ManAtWork. Keep it simple on the front-end (so things can be quickly assembled and tested on the bench with just a few lines of user code), and then allow for deeper learning and adjustments as we climb-up the learning curve.
These recent posts encompass exactly the right vision, I believe. The contributions from @ManAtWork, @JRoark, @tritonium, @iseries, and @Roy Eltham give us a good starting point. I think we can use the @ManAtWork user interface as written, too.
As far as Parallax having some hardware on hand and in stock, it's just for educational and demonstration purposes. Because we're working with steppers, the same code should be able to run much larger motors, geared down for CNC conversions. As for demo, I'd probably get some NEMA17 motors attached to ballscrew slides just to demonstrate the code example.
Current plan is to ask @JonnyMac to write this object, unless somebody else jumps in to accomplish it within 10 days from now. I'd like this one posted by the second week of February.
Thanks for everybody's input here.
Ken Gracey
As for demo, I'd probably get some NEMA17 motors attached to ballscrew slides just to demonstrate the code example.
It might also be possible to buy a cheap 3D printer (or use a broken one), rip apart the extruder and replace it with a pen. This can be used to draw figures on paper for demonstration. It's better than separate ball screw slides because you can also demonstrate circular moves. Or you could build a simple pick&place machine with a solenoid magnet to lift and drop screw nuts or other iron pieces.
I think I could also write some code but I have nothing against some help from Jon if he wants to join. As my nickname says I'm always busy 😄 and 10 days is quite a tight schedule. I can surely put up something that at least moves around a bit but I can't promise to finish every detail.
Thinking out loud here: A cheap X/Y/Z positioner with an electromagnet for a “gripper”, and a Checkers board with metal pieces would be grand mischief! Put a webcam on it and let ‘er rip 24/7. All controlled by a single Prop that plays both sides AND does the positioning AND has a display for the stats.
Yes, I'd agree.
On P2 the smart pin Quadcounters are essentially free, so it makes sense to allow for a Encoder input, even if just for testing verification, and those intent on shaving the last cents on their high volume consumer designs can leave off the encoders, when they have proven there are no missing steps.
Useful P2 pin modes for checking and verify would be
%01011 = A/B-input quadrature encoder%01101 = Accumulate A-input positive edges with B-input supplying increment (B=1) or decrement (B=0)The second mode could clip-onto the Step & DIR outputs commonly used to feed simple steppers, to keep track of what actually came out of P2.
when they have proven there are no missing steps.
Yes, I agree that it's good to have the option to connect encoders. And because it's easy with the P2 and demonstrates its capabilities we should go for it. But I have to repeat that "stepper systems are always sensible to lost steps" and "closed loop systems are the cure" are both myths. There are so many reasons for "lost steps":
Adding feedback adds complexity. And it avoids only some of the problems listed above and even adds some new ones. If, for example, the encoder cables are long and not properly shielded the risk of loosing steps are actually increasing instead of decreasing because the encoder signals are also susceptible to EMI.
I don't vote against encoder is general. I just say you have to be careful. Encoder feedback makes well designed systems better but it can make crappy systems worse and it's not the cure to all problems.
... All controlled by a single Prop that plays both sides AND does the positioning AND has a display for the stats.
Yes, brilliant. I just realized that controlling 4 (or even more) stepper motors only takes one cog and 8 pins of the P2. So we have plenty of resopurces left to do it several times concurrently plus some fancy display and blinkenlights.
I've just seen the announcement "Stepper Motor fun with JonnyMac" on March 10th. Very good!
This brings back the chance that I'll also have something to show by that date. I've been busy with lot's of urgent orders the last days and the 10 days deadline was way too short.
We'd really like that! Get those orders done, and get some stepper action started. I'd be pleased to post some objects as Quick Bytes, too! Anything you'd like to share is welcome at the P2 Live Forums, too.
Ken Gracey
Encoders:
For me, if I can't verify that a command has been successfully executed...I am not in "control".
This applies to something as simple as a 2-position actuator, I have sensors to verify that the actuator is where it's supposed to be.
The same would apply to a stepper motor; not reaching desired/commanded position might be caused by an obstruction and nothing to do with motor/drive performance. I think students will quickly see the benefits of this and would compare it favourably with other MCUs that don't have this capability.
Yes, in 40 years, my only involvement with steppers was ripping them off a machine and throwing them in the bin. I should be thankful because this is exactly what put me in business, back in the 80's.
I don't advocate the use of steppers but if that's what's required, at least put a feedback device on there so you're not running blind.
Edit: "slaving an axis"... Good point! I do this all the time and with a variable gearing ratio.
CNC is not limited to machining centers/lathes/routers/3D printers, etc.
The P2 will end up being retrofitted to the following:
This is all closed-loop servo control.
It's been quiet for a while, here. I was very busy the last week. But I finally had some time for programming, today. The basic concept of what I proposed in post #24 is working:
I don't post any code, yet, because it doesn't produce anything useful so far except long debug hex dumps. Circular interpolation is also still missing. But I hope I can come up with a demo that shows some real mechanics moving, soon.
Here is a short simple program to demonstrate CNC interpolation and stepper motor step generation.
If is far from perfect, but it's small size and simplistic (somewhat) nature make it easy to follow.
You need to run it in PNut because it uses debug graphics.
I haven't tested the stepper pulse output.
Mike