Closed andrewismoody closed 6 years ago
I think the general idea is to never run into the problem of losing position. The motors and drive system need to be robust enough to handle the cutting forces. For open loop control, like Grbl, this is mandatory. For closed loop, this is still pretty much mandatory. In my view, closed loop control only gives you the ability to catch the error. In a properly size CNC system, the errors willl be nonexistent or very rare.
it depends on the closed loop system you are dealing with.
A proper closed loop system will adjust the speed of each axis to keep you where you should be, speeding up when you fall behind (and ideally doing this at a small enough scale that you don't notice the error)
if you are running an axis full speed, you don't have any headroom to catch up, but at that point you are running the machine faster than you should. But as long as you have the headroom to catch up, closed loop is better
don't think of closed loop in terms of steppers combined with encoders, think of it in terms of DC (or BLDC) motors combined with encoders, there it's not a matter of making up for a missed step, it's a matter of continually adjusting the speed to keep you where you want to be at that point in the cut.
Sure. That is one way to approach it. However, if you have a good motion planner that takes all of that into account, you don’t need closed loop control. Personally Ive seen super high tech, half million dollar 3D printers with nice closed loop linear actuators. It does just as you say but had a really bad motion controller. An $800 Prusa 3D printer did an order of magnitude better job at print quality and print speed.
@davidelang what you are describing is basically adaptive feedrate, shouldn't be too far way since there is already a feed override mechainism. I believe some cnc machines can do it based on a nominal spindle load and a range it can adjust the feed within
This is all good conversation and @chamnit it makes sense that a well-powered, well-engineered, well-assembled machine wouldn't need error correction. I suffer from the negative of all of those. I can't afford well-engineered; I don't know how much power I actually need; and I'm crap at properly assembling (or so it would seem). I did romanticize closed loop systems when I first read this article on cnc cookbook: here. Of course, I skimmed over the terribly technical stuff and came to the conclusion that this was all that I needed in my life. Closed loop doesn't solve mechanical limitations - I was faced with the situation where I told the machine to drive the wasteboard through the wall of the containment box. It was not able to do this, despite having closed loop encoders. Closed loop doesn't solve electrical limitations - I was also faced with a situation where the encoders were drawing more power than the Arduino was being served. The encoder shut down of course, and the motor stopped. Consequently discovered this very good article on Arduino power: here. Conclusion: get the most current from your 5v pin by using a 7v 1a adapter on the barrel connector. I did, however, see a huge improvement in motor performance with the closed loop encoders (smart steppers in my case). Some of this may be due to switching from a single driver board to dedicated per-motor drivers, and cleaning up my wiring quite a bit. I would really like to find a solid bridge between the smart steppers and grbl. Even if grbl won't adaptively adjust to the encoder feedback, if I could just get to stop when things go awry that would be great. In a perfect world, my machine wouldn't randomly lose parts during a job and jam up the x axis lead screw, but that's not where I live. If one of my axes does jam up, I would like to save the stock I'm cutting, at the very least, from complete destruction. Would hooking error pin to feed hold on grbl do this? Is it going to require a year-long project to design a break-out board or something to make this connection?
Would hooking error pin to feed hold on grbl do this?
Depends on what the closed loop drivers send back. If it is a simple Low High signal the you can probably get away with that or even connect it to a limit pin?
2018-02-26 1:42 GMT+00:00 andrewismoody notifications@github.com:
This is all good conversation and @chamnit https://github.com/chamnit it makes sense that a well-powered, well-engineered, well-assembled machine wouldn't need error correction. I suffer from the negative of all of those. I can't afford well-engineered; I don't know how much power I actually need; and I'm crap at properly assembling (or so it would seem). I did romanticize closed loop systems when I first read this article on cnc cookbook: here https://www.cnccookbook.com/ultimate-cnc-mini-mill-steppers-servos-closed-loop-open-loop/. Of course, I skimmed over the terribly technical stuff and came to the conclusion that this was all that I needed in my life. Closed loop doesn't solve mechanical limitations - I was faced with the situation where I told the machine to drive the wasteboard through the wall of the containment box. It was not able to do this, despite having closed loop encoders. Closed loop doesn't solve electrical limitations - I was also faced with a situation where the encoders were drawing more power than the Arduino was being served. The encoder shut down of course, and the motor stopped. Consequently discovered this very good article on Arduino power: here https://www.open-electronics.org/the-power-of-arduino-this-unknown/. Conclusion: get the most current from your 5v pin by using a 7v 1a adapter on the barrel connector. I did, however, see a huge improvement in motor performance with the closed loop encoders (smart steppers http://misfittech.net/3-2a-nema23-smart-stepper/ in my case). Some of this may be due to switching from a single driver board to dedicated per-motor drivers, and cleaning up my wiring quite a bit. I would really like to find a solid bridge between the smart steppers and grbl. Even if grbl won't adaptively adjust to the encoder feedback, if I could just get to stop when things go awry that would be great. In a perfect world, my machine wouldn't randomly lose parts during a job and jam up the x axis lead screw, but that's not where I live. If one of my axes does jam up, I would like to save the stock I'm cutting, at the very least, from complete destruction. Would hooking error pin to feed hold on grbl do this? Is it going to require a year-long project to design a break-out board or something to make this connection?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/388#issuecomment-368367017, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-pkLqPrrSdgJNFFA-mgDDKufKlutks5tYgwWgaJpZM4SSea1 .
-- Com os melhores cumprimentos, Vinicius Silva
Closed loop isn't only for correcting mistakes of misalignment. It is used also to adjust setting of motor controller (i.e. PID). As example, lets have vertical milling center, with table moving in x and y axis. Cast of the table, linear bearings and every other component that the table is made of have known mass. We can measure at the beginning step of assembling machine and set PID parameters especially for moving that mass. When im setting at the table 1kg aluminium plate, mass isn't changing so much. But when the setted part reaches 200kg, mass changing significantly. So, the current of motor could be too weak to properly accelerate and de-accelerate all that stuff and that could cause dimensions overruns, resonances etc. Feedback is needed for motor controller to adjusting current of coils. But when drivers will not be able to reach assigned position, should send error signal to motion planner to pause other drives until late driver reaches position or to stop machine when error will be bigger than setted maximum. This case does not even consider cutting forces, but when they are present, situation is even more complicated. Of course, problem is highly reduced when machine is configured as a plotter, where the mass moving is rather constant ( differences in weight between tools), but still cutting forces should be considerable.
Joke (from some thread about programming machines): Q: Is there any g-code for fast spindle stop? A: G00 Z-1000.
Also,more and more smart drivers come into existence (thanks TI) such as DRV8711 which reports missed steps (analyses BEMF and other black magic)
In the rare case of missed steps you can hard-wire the STALLn to Emergency-Stop (Reset for GRBL?)
Maybe this is one way to prevent problems with steppers on cheap systems.
@petmakris : Agreed. This includes trinamic drivers that the new Prusa MK3 uses. It also senses coil current and uses that to detect limits, instead of using switches. Most of these new smart drivers communicate via SPI and is a much better use of precious IO pins than just supporting a set of error pins.
The problem with closed loop (that I'm discovering first-hand) is that each axis is independent. The encoder does notice the missed step and compensate for it, but at the expense of time. As you might imagine, not all axes get 'bound up' at the same time - usually just one. This means that one axis is slightly behind on motion while the other two (or three or whatever) continue along their merry way, none the wiser. The result being that the spindle does eventually land in the right position, the path it took to get there may not be as planned. Think about making an XY move where the X axis is a half second behind. The angle of the path will be much different than the expected angle and therefore result in cutting (or not cutting) material that was expected. Would like to see GRBL support a feedback mechanism with closed loop controllers (like Smart Stepper and MechAduino) so that the encoder can tell the controller to hold up while it corrects its position. I had thought about hooking the 'error' pin of the closed loop encoder to the feed hold pin, but I don't know if this would quite do what I want (will the feed hold be removed when the error pin reverts?). And I'm not an EE, so I don't really know how to determine what would be required to 'convert' the signals to be compatible. This feels like it would need to be a 'supported feature' of GRBL to really work properly.