Hello Guest it is March 28, 2024, 12:25:34 PM

Author Topic: Why is there no effort for the true closed loop control on the mach3 level  (Read 20485 times)

0 Members and 1 Guest are viewing this topic.

Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #20 on: January 14, 2011, 02:09:34 PM »
I am not that elegant on getting my point across and this is just my thoughts.
when I say 'real closed loop'  I think of real machines like fanuc or whatever.  The machine control commands a motion - reads back its speed/vel calculates  and adjust accordingly - this is how emc does closed loop.

step servos or steppers machines don't do that.  Emc or Mach blindly sends out pulses that relate to how the control wants the motion to go.  Yes - you can setup the step servos so that if they loose position - the machine will estop (rogersmachine interface gets you at least position - if I understand it right)...  but I don't consider that 'true close loop' as the control doesn't know its position at that point and isn't reading back and constantly correcting while moving.

I kinda like the mouse analogy above..

I don't know how mach handles the more expensive solutions..  (Galil, DSPMC, etc)

This was a quote from a motion control expert..

'I suppose PC hardware is inferior above some sample rate (maybe 10-20 KHz) but unless you have very exotic CNC mechanics those sample rates wont buy you anything.'

sam

(we might have to agree to disagree :))

Offline ASC

*
  •  59 59
    • View Profile
    • Automation Systems
Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #21 on: January 14, 2011, 02:11:04 PM »
Had to pipe in on this one!

Using Mach I've had no problem getting resolutions of 5 uM or less using open loop steppers.  The real key is to have an extremely rigid machine with tight smooth motion and a good microstepping driver.

That said, on the closed loop end, I've used mach to supply the motion signal to copley servo drives and reached resolutions of 500 nM.  Mach supplies the control interface and trajectory planning and the servo drive and encoder do the rest.  Mach may not be closed loop but the driver its controlling sure is.
Mr. Creosote

Offline Jeff_Birt

*
  •  1,107 1,107
    • View Profile
    • Soigeneris
Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #22 on: January 14, 2011, 04:17:28 PM »
Sam, I'm not trying to give you a hard time. Nor am I saying that what EMC does is not great. There is just a lot of mysticism related to 'closed loop back to the control'. All I want to do is get the facts out and let everyone decide what type of control they want/need.


Quote
step servos or steppers machines don't do that.  Emc or Mach blindly sends out pulses that relate to how the control wants the motion to go.  Yes - you can setup the step servos so that if they loose position - the machine will estop (rogersmachine interface gets you at least position - if I understand it right)...  but I don't consider that 'true close loop' as the control doesn't know its position at that point and isn't reading back and constantly correcting while moving.


You have the general idea, but you don't quite right. EVERY servo system knows exactly where it is, that is what the encoder tells it. EVERY servo system is never exactly where you tell it to go, there is always a bit of error. If the error is too great you get an error signal. Simple servo drives keep all the encoder information to themselves but will tell the controller if the error is too great. The important part is that they go where they are told or an error is generated, the controller that is telling them where to go knows exactly where they are unless an error occurs. If an error occurs than your part/fixturing is likely scrap so it does not matter either way.

More complex servo controllers can share the encoder position with the control logic and the control logic can 'sync' multiple axis movements together. So, if one axis is lagging behind everything can slow down and you might be able to avoid an error. For 99.99% of cases this ability to 'sync' axis' together dynamically is superfluous. Why? Well if what you are doing is bogging down an axis to the point of tripping an error then you have most likely ruined the part and/or tool anyhow. For some operations like threading it is important to synchronize the axis' movement with the spindle. This really only requires an index pulse from the spindle for single point threading. For more complex operations you need more synchronization, but again that is outside what is really needed for the vast majority of cases.

Happy machining , Jeff Birt
 

Offline RICH

*
  • *
  •  7,427 7,427
    • View Profile
Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #23 on: January 14, 2011, 05:19:34 PM »
I will comment that this is an interesting discussion but you may never get an answer to the original question.

Art gave some thoughts some time ago relative to EMC and Mach and I will post a link if I can find it.  I think, as Jeff has pointed
out, that many users are miss-informed on their understanding of closed loop. Tell that to somebody that spent a lot of money and realy didn't get what they expected once informed. ;)

RICH

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #24 on: January 14, 2011, 06:02:56 PM »
Emc or Mach blindly sends out pulses that relate to how the control wants the motion to go.
Actually, that is what the motion planning part of other systems do. They send signal to the lower-level motor control sections. Does it matter where the error sensing is done? Once you get near to an error state you are dead anyhow.

Quote
Yes - you can setup the step servos so that if they loose position - the machine will estop (rogers machine interface gets you at least position - if I understand it right)...
Correct up to a point. If I estop at full speed I will lose position. Instead I 'pause', which is the right way of doing things. But if I estop, something has gone WRONG.

Each servo amplifiers has a magnetic breaker. It that trips then I also lose position. But again, I have done something WRONG, and may have wrecked the job or need to completely restart a new piece.

Quote
but I don't consider that 'true close loop' as the control doesn't know its position at that point and isn't reading back and constantly correcting while moving.
As long as I operate in a conservative regime, Mach DOES know where the control point is. It is where Mach has told the INTELLIGENT servo amplifiers to go. If they can't obey that order they flag a fault.

Mind you, I think Rich has hit the nail on the head:
I think... that many users are miss-informed on their understanding of closed loop. Tell that to somebody that spent a lot of money and really didn't get what they expected once informed.

Nothing quite as upsetting as finding out later that there is a cheaper but equally effective solution! Happens to all of us. Everyone needs to design and build a couple of CNC systems before they get it right...  :-)
(I'm on my 3rd or 4th.)

Cheers


Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #25 on: January 15, 2011, 01:53:24 PM »
Closing the loop in the Gcode layer is for me important, Why?,
let me describe you my dream how it should function. ex: 6000 lines ahead.
The software should anaylze the whole 6000 lines and build up mathematically defined spline
segments. For example gathering 16 gcode lines to a bezier curve, for a simpler explanation
just think abaout the vector drawing in corel draw, when you draw a line corel draw connects the points
through a spline curve which has analog continiuty and can be defined with maybe 3 or 4 constants.

a simpler spline p(x)= ax^3+bX^2+cx+d  , these coefficients a,b,c,d are calculated in real time in dependance of
the given follow error by the user. EX: in pick and place applications the user can increase the trajectory follow error and
decrease the follow error just at the end of the (last point of the polynomial function).For surface fini sing according to roughing or finising passes,
the user can define lower or by demand higher follow error for roughing and very low follow error for finising.

After you have a,b,c,d  you dont deal with the gcode data anymore, your polynom sends the position data to the servo,
But here I also think abaout an important connection, the polynom data is so optimized that the sppeeds and acceleration are regulated in real time,

think abaout a life feedback that servo tells the controller, hey I am %80 loaded you can drive me more severly, or hey my decceleration is %73 in capacity you can do more decceleration.

In this art of regulation you get an error only when there is hardware fault. Why I am telling this. Think abaout a Gcode program that has many small curves.

Everytime I run such a programm I never reach the feedrate that I have given, Maybe %10 of the feedrate is there, because of inefficient acceleration decceleration profiles.

The polynomes can be chosen according to the computing power. maybe p(x)=ax^3+bxsin(wx) or a logaritmic one to smoothen the velocity and accelerations curves and speed up the responsiveness of the whole system.

Naturally an additional computation should be there so that if we have defined 200 polynoms in 6000 lines of gcode , the endpoint of each polynom shuold be the first point of adjecant polynom function.


The computational overhead is with a 8 core i7 not a problem. A 100$ GPU card with from Nvidia (ex:CUDA interface) can also compute simultaneously the polynom coefficients.

A regular GPU we all have has 96 computing cores. and the matrix multiplication is peanuts for the GPU.


What do you think abaout spline interpolation and servo regulation for a higher dynamic.Very important is the inertia feedback from the servo if possible.

The fault signal is not enough between the servo and gcode interpreter,  There should  be a dynamic regulator for the inertia reserve,power demand reserve, braking reserve, regenerative reserve.

Any ideas?

Offline rcaffin

*
  •  1,052 1,052
    • View Profile
Re: Why is there no effort for the true closed loop control on the mach3 level
« Reply #26 on: January 15, 2011, 11:50:41 PM »
let me describe you my dream how it should function. ex: 6000 lines ahead.  The software should anaylze the whole 6000 lines and build up mathematically defined spline
segments. For example gathering 16 gcode lines to a bezier curve, for a simpler explanation
Two very major problems with this.

* The first is that this is high-level planning, which Mach is perfectly capable of doing if that was what the market wanted. This sort of planning is totally disconnected from the 'feedback' issue.

*The second problem is that I do NOT WANT Mach doing that sort of thing, EVER! If I program the control point to go to a series of locations, that is what I want it to do. I do NOT want some smart-alec programmer who has absolutely NO idea of what I am machining trying to alter what I have programmed ! ! ! ! !

Quote
EX: in pick and place applications the user can increase the trajectory follow error and
decrease the follow error just at the end of the (last point of the polynomial function).
Yeah, sure but pick&place is NOT CNC machining. Yes, I have designed and built successful P&P machines. And Mach is NOT designed for P&P machines. (Read the manual.)

Quote
think abaout a life feedback that servo tells the controller, hey I am %80 loaded you can drive me more severly, or hey my decceleration is %73 in capacity you can do more decceleration.
I do NOT want the machine changing what I have deliberately programmed into it. NEVER. I may be running the machine slowly because the material I am machining will melt at a higher speed. You can think of other reasons for me.

Quote
In this art of regulation you get an error only when there is hardware fault. Why I am telling this. Think abaout a Gcode program that has many small curves. Everytime I run such a programm I never reach the feedrate that I have given, Maybe %10 of the feedrate is there, because of inefficient acceleration decceleration profiles.
In that case you may be using the wrong machine. Don't expect software to compensate for an inadequate machine. That's a bit like trying to put sophisticated fault-tolerant software on top of Windows98 ....

Cheers