Mach3 / Linux CNC kör profiler och ramper

[DAP]

Hej

Sitter och gör lite beräkningar på min fräs och räknar på dimensioneringen av mina servomotorer.
Det jag inte har kunskap om är hur dom olika cnc mjukvarorna fungerar.
Vad är det för typ av ramper som dom använder sig av?
Är det vanliga linjära ramper dessa mjukvarorna generera ut eller man kan välja att få en 5th polynomial kurva?

Kan man ställa ramptiderna och vad är rimliga ramptider?
Mest så jag knappar in samma ramptider i min mjukvara för axel beräkningarna.

Maskinen är en Deckel FP4A och tanken är att ha en snabbmatning på ca 5-6meter / min som max och sen fräs hastigheten kommer ju att begränsas av spindel hastigheten.

Hur har ni era maskiner inställda?

MVH
Oscar

[H.O]

Hej Oscar,
Kan inte svara för LinuxCNC men Mach3 kör konstant acceleration, givtevis är den ställbar.
Vad som är lämpligt är svårt att svara på, det beror ju på hur stadig maskinen är (knappast ett problem i ditt fall), hur kraftiga kulskruvar, kopplingar, infästningar osv är. Den konstanta acceleration som Mach3 har är ju inte optimalt ur den synvinkeln (men duger mer än väl i 95 fall av 100, om inte mer) då det blir ett mer eller mindre kraftigt "ryck/slag" i varje "ände" på acceleration/retardationsrampen. Ju snabbare acceleration desto mer "ryck/slag" men desto mindre avrundning i hörnen när man kör CV.

Det finns en experimentell motion planner till Mach3 som kör linjär acceleration men den har inte utvecklats på år och dar och jag har inte koll på statusen.

På Abene'n har jag 5m/min snabbmatning och jag TROR jag har den ställd så den accelererar på 0.25s.

[swapper]

Vet inte om detta kan ge dig någon insikt

http://linuxcnc.org/docs/html/common/User_Concepts.html

1.3. Programming the Planner


The trajectory control commands are as follows:


• G61 - (Exact Path Mode) visits the programmed point exactly, even though that means it might temporarily come to a complete stop in order to change direction to the next programmed point.


• G61.1 - (Exact Stop Mode) tells the planner to come to an exact stop at every segment’s end.


• G64 - (Blend Without Tolerance Mode) G64 is the default setting when you start LinuxCNC. G64 is just blending and the naive cam detector is not enabled. G64 and G64 P0 tell the planner to sacrifice path following accuracy in order to keep the feed rate up. This is necessary for some types of material or tooling where exact stops are harmful, and can work great as long as the programmer is careful to keep in mind that the tool’s path will be somewhat more curvy than the program specifies. When using G0 (rapid) moves with G64 use caution on clearance moves and allow enough distance to clear obstacles based on the acceleration capabilities of your machine.


• G64 P- Q- - (Blend With Tolerance Mode) This enables the naive cam detector and enables blending with a tolerance. If you program G64 P0.05, you tell the planner that you want continuous feed, but at programmed corners you want it to slow down enough so that the tool path can stay within 0.05 user units of the programmed path. The exact amount of slowdown depends on the geometry of the programmed corner and the machine constraints, but the only thing the programmer needs to worry about is the tolerance. This gives the programmer complete control over the path following compromise. The blend tolerance can be changed throughout the program as necessary. Beware that a specification of G64 P0 has the same effect as G64 alone (above), which is necessary for backward compatibility for old G Code programs. See the G Code Chapter for more information on G64 P- Q-.


• Blending without tolerance - The controlled point will touch each specified movement at at least one point. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started). The distance from the end point of the move is as large as it needs to be to keep up the best contouring feed.


• Naive Cam Detector - Successive G1 moves that involve only the XYZ axes that deviate less than Q- from a straight line are merged into a single straight line. This merged movement replaces the individual G1 movements for the purposes of blending with tolerance. Between successive movements, the controlled point will pass no more than P- from the actual endpoints of the movements. The controlled point will touch at least one point on each movement. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started) On G2/3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines. Thus, line-arc, arc-arc, and arc-line cases as well as line-line benefit from the naive cam detector. This improves contouring performance by simplifying the path.

[DAP]

Hej Oscar,
Kan inte svara för LinuxCNC men Mach3 kör konstant acceleration, givtevis är den ställbar.
Vad som är lämpligt är svårt att svara på, det beror ju på hur stadig maskinen är (knappast ett problem i ditt fall), hur kraftiga kulskruvar, kopplingar, infästningar osv är. Den konstanta acceleration som Mach3 har är ju inte optimalt ur den synvinkeln (men duger mer än väl i 95 fall av 100, om inte mer) då det blir ett mer eller mindre kraftigt "ryck/slag" i varje "ände" på acceleration/retardationsrampen. Ju snabbare acceleration desto mer "ryck/slag" men desto mindre avrundning i hörnen när man kör CV.

Det finns en experimentell motion planner till Mach3 som kör linjär acceleration men den har inte utvecklats på år och dar och jag har inte koll på statusen.

På Abene'n har jag 5m/min snabbmatning och jag TROR jag har den ställd så den accelererar på 0.25s.

Jag tackar för info'n.
Har du nån anning om vad du har för tröghetsmassa i bordet som ett exempel på X rörelse och likaså vad du har för friktion på X rörelsen?

Skall testa och se hur beräkningen blir med en ramp på 0.25sekunder.

[arvidb]

Även LinuxCNC kör konstant acceleration; ingen begränsning av ryck (eng. "jerk").

Det pratas om detta titt som tätt på emc-developers (maillistan för utvecklare av LinuxCNC), liksom om bättre path planners, men något revolutionerande verkar inte finnas i pipelinen.

Edit: jag tycker att detta är ganska intressant och har funderat en del på det. Faktum är att ryck och acceleration är helt låsta om man vill ha en exakt bana i bestämd hastighet. D.v.s. redan vid CAM-steget måste man ta hänsyn till maskinen som arbetet ska göras på (och saker om begränsning ryck) om man ska få ett vettigt slutresultat. Särskilt om man vill ha konstant chip load och konstant skärhastighet. G-kod är inte riktigt lämpat för "modern" tillverkning...

Sen blir det ju spännande när man dessutom vill ha omedelbar "feed override" på maskinen.

Edit: bytte till svenska uttrycket för engelskans "jerk".

[H.O]

Oscar,
Jag har verkligen ingen aning men bordet väger nog ett par hundra kilo och åker i laxstjärtstyrningar så friktionen är relativt hög, i alla fall jämfört med moderna maskiner med skenstyrningar etc.

Arvid,
True that. Det är komplicerade saker. Det visar inte minst de otaliga gånger folk gnäller över att maskinen rundar av" i hörnen när CV är aktiverat.... Generellt så ger ju bang-bang principen (alltså acceleration på/av) snabbast tid från stillastående till begärd hastighet och som sagt, det duger till de flesta. De maskiner som verkar dra mest fördel av trapetsformad acceleration (eller ännu mer komplicerade algoritmer) är snabba men lätta maskner som annars "tar stryk av smällarna".

Och precis, feedrate override, hur påverkar det accelerationen i de olika applikationerna? Helst ska den ju inte göra det alls men i Mach3's fall så gör den det vilket kan vara mindre bra (katastrofalt) om man övermannar uppåt i hög utsträckning....

[arvidb]

Jag har börjat skriva på en ryck-begränsad trajectory planner i helgen:

140413-demo.png

Det finns en del kvar att göra innan den är användbar: för tillfället så kör den bara på hastighet utan att bry sig om positioner - byt till ny hastighetsvektor, kör 0,5 s, byt till ny hastighetsvektor o.s.v. Att ta hänsyn till positioner handlar dock bara om att beräkna tider för ny vektor. Sen tillkommer hantering av arcs och korta segment...

Ovan kört med ryck = 22,5 m/s³, acceleration begränsad till 1,5 m/s², och målhastighet på 0,1 m/s.

Edit: tanken är alltså att man kunde få in denna i LinuxCNC om jag lyckas få den färdig.
Edit2: jerk->ryck

[H.O]

Häftigt! Mattematiken för det där är lång över min nivå...
Vore ju fantastiskt coolt om du kunde få den integrerad/användbar i LinuxCNC!

[DAP]

coolt arvid.
Du verkar ha riktigt bra koll på detta.
Jag tror jag skall göra min beräkning utifrån att jag kan rampa upp / ner på 0.2 sekunder så får vi se vad beräkningsverktyget säger om det och med dom motorerna jag har.

Tackar så länge för all info

[arvidb]

Tackar!

DAP: Jag tror först nu att jag har fattat vad du frågade om i första inlägget. Så för att förtydliga: svaret är nej, man kan inte ställa in ramptider. Det man kan ställa in är som sagt acceleration. Det är logiskt eftersom accelerationen är direkt proportionerlig mot motormomentet.

Ramptiden (tr) blir då proportionerlig mot hastighetsskillnaden: tr = dv/a.

Om du ska rampa från 0 till 6 m/min = 0,1 m/s på 0,2 s så blir accelerationen 0,1 [m/s]/0,2 = 0,5 m/s². Det låter helt rimligt tycker jag (det är i alla fall inte för högt).

Edit: Observera dock att ramptiden till säg 3 m/min alltså blir 0,1 s med samma acceleration => ramptiden är beroende av hastighetsskillnaden.

[arvidb]

Nu har jag äntligen haft tid och ork att jobba vidare lite med trajectory plannern. Nu hamnar linjesegmenten på rätt ställe. I figuren nedan är linjesegmenten som följer:
L1: (0,00; 0,00) => (0,00; 0,15)
L2: (0,00; 0,15) => (0,10; 0,05)
L3: (0,10; 0,05) => (0,20; 0,15)
o.s.v.
Hastigheten är satt ganska högt till till 0,2 m/s (12 m/min) för att "vändningarna" ska bli tydligt rundade - förutom på L3 som har matning 0,05 m/s, och därför också får snävare anslutande hörn. Vid hörnet A har jag lagt in ett "exakt stopp" (där alltså matningen går till 0 m/s ett ögonblick).

140422-demo.png

Hela banan tar 7,8 sekunder inkl start och stopp.

[arvidb]

Jag har tittat vidare på ryck-begränsning av banor med cirkelbågar, och här dyker det upp ett problem. De flesta ser nog intuitivt att man inte kan följa en bana med skarpa hörn om man har begränsad acceleration (man måste "runda av" hörnet). Däremot är det kanske inte så intuitivt att man inte kan ha direkta övergångar mellan linjesegment och cirkelbågar med begränsat ryck.

Om man följer ett linjesegment i konstant fart \(v\) så är accelerationen noll. Följer man däremot en cikelbåge i konstant fart så har man en centripetalacceleration \(a = v^2/r\). En direkt övergång mellan en linje och en cirkelbåge ger alltså oändligt ryck.

Själva ryckbegränsningen går fint att lösa med hjälp av t.ex. Euler-spiraler - problemet är att då får man inte den kurvform som man förväntade sig:

575px-Easement_curve.svg.png

Cikelns centrum blir alltså förskjuten i både x- och y-led. Om man t.ex. har en bana med en linje, en 90 graders cirkelbåge, och sedan en linje igen, så är enda möjligheten att använda en cirkelbåge med mindre radie och förskjutet centrum jämfört med den programmerade.

Jag gissar att ovanstående inte är acceptabelt. Så hur löser man detta i professionella maskiner? Vilket slags kurvor genererar de? Skippar man ryck-begränsning på cirkelbågar, eller använder man inte rena cirkelbågar alls?

[H.O]

Ja, jag hade i alla fall trott att rycket borde bli förhållandevis litet med anledning av att det är just en radie, Y axelns (i det här fallet) hastighet ökar ändå "sakta" i förhållande till vad den "kan göra" rent accellerationmässigt. Så nej, att det blir just så var inte speciellt intuitivt.....

Hur fungerar matematiken om man "i förväg" gör om cirkeln till hundra- tusen- eller tiototsuenhörning etc? Då är det ju plötsligt en övergång från ett linjesegment till ett annat, om än kort sådant.

Har även sett NURBS nämnas lite här och var men vet inte hur det fungerar eller om det är applicerbart på det här problemet. Gissar att man applicerar det på oregelebunda ytor och konturer bestående av mängder med korta linjesegment.

Googlade på FANUC jerk compensation och hittade det här dokumentet, bland annat. Har inte läst det så noga men de verkar beskriva hur systemet fungerar och vad/hur man ställer in parametrarna, kanske går det att klura ut något från det.

[arvidb]

Oavsett hur man beskriver cirkelbågen så kommer man att få oändligt ryck om man går direkt från en rak linje till cirkelbågen. Eller tvärt om: med begränsat ryck är det fysiskt omöjligt att ha en direkt övergång från en rak linje till en cirkel.

I bilden nedan ser du hur en cirkelbåge ser ut, med inledande ryckbegränsning. Banan börjar i (0; 0), går till (0; 0,15) i en rät linje och går sedan över till en cirkel. Cirkelns centrum borde vara i (0,05; 0,15) men är förskjutet uppåt-höger. Utan ryckbegränsning hade accelerationsdiagrammet visat en flank utan lutning för X-axel och verktyg istället för den lutande flanken (när cirkeln börjar vid t = ca 0,85 s):

140502-arc-vector.png

Om man approximerar cirkeln med linjesegment så händer detta: (Med reservation för att mitt program inte klarar av att hantera segment som är så korta att man inte kommer upp i full hastighet, vilket gör att värdena för "tool velocity" är för höga. Att cirkeln inte är förskjuten beror på att programmet gör ett "hopp" på 3 mm efter varje segment, vilket egentligen är till för att bli av med avrundningsfel på långa körningar men nu blir en fulfix för de korta segmenten. Principen med vibrationerna som syns i diagrammen bör dock stämma - fast de hade haft högre amplitud i verkligheten):

140502-arc-segmented.png

Det vill säga: "centripetalaccelerationen" samlas i stötar vid varje vinkeländring, och mitt i segmenten så är accelerationen noll. Detta ger såklart vibrationer, även om det är vibrationer med begränsat ryck i detta fall.


En gissning till hur detta kanske löses på professionella maskiner är att man gör ryckbegränsning i servodrivarna (osynkat och individuellt för varje axel), och tar ett litet following error i övergångar mellan segment med olika kurvatur.

[swapper]

Snubbla över en tråd i Linuxcnc forumet om att det jobbar på förbättringar till TPn där.

http://linuxcnc.org/index.php/english/f ... mitstart=0