Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed Loop Support? #388

Closed
andrewismoody opened this issue Feb 25, 2018 · 9 comments
Closed

Closed Loop Support? #388

andrewismoody opened this issue Feb 25, 2018 · 9 comments

Comments

@andrewismoody
Copy link

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.

@chamnit
Copy link
Contributor

chamnit commented Feb 25, 2018

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.

@davidelang
Copy link

davidelang commented Feb 25, 2018 via email

@chamnit
Copy link
Contributor

chamnit commented Feb 26, 2018

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.

@langwadt
Copy link

@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

@andrewismoody
Copy link
Author

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?

@X3msnake
Copy link

X3msnake commented Feb 26, 2018 via email

@cube000
Copy link

cube000 commented Mar 8, 2018

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.

@petmakris
Copy link

petmakris commented Mar 23, 2018

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.

@chamnit
Copy link
Contributor

chamnit commented Apr 25, 2018

@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.

@chamnit chamnit closed this as completed Apr 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants