UCCNC vezérlő program

[ANTAL GÁBOR]

Olvasom a beírást ( bár csak a felét értem ) tudom hogy az árképzésnél minden cm2 panelfelület számít de ha kicsit lazábban terveztek ( legyen a panel mondjuk 3 cm2 -rel nagyobb !! ) akkor lehet kikerülitek a csapdát. A minap vettem egy Li Po akku töltő Ic t ( I= 2.5 A ). De nem mélyedtem bele a pdf be. Hát megjött ( chipcad a forgalmazó -microchip a gyártó  ). Kibontottam , megnéztem nagyítóval azután egy csipesszel szépen belehelyeztem a kukába  ( mottó :  63 évesen még szeretném élvezni az életet ,ezért kerülni kell az idegeskedést )[#csodalk][#csodalk]

[sanyi84]

Ok, ez így működik sok vezérlőnél. Ha én bármit írok be a linuxcnc nek G64 P0.01 akkor sem fog durván lassulni, tartja a megadott sebességet gyorsulási görbe szerint, próbálja körív átmenettel átlépni a sok egyedi szakaszból álló íveket és bizonyos szögig működik is a dolog.  
 
Itt viszont gondolkodott és nem fogásvételnél hanem sarkoknál.  Sok szerszámgép gyártó csinál már optimalizációt a vezérlőbe, ezáltal jobban tartja a megadott sebességet. Az állandó sebesség és állandó forgácskeresztmetszet feltétele a minőségibb munkának. Én nem tudhatom van-e pályaoptimalizáció ennél de valószínű nincs. Hasonló megoldása lehet például a hurconak mint a linuxcnc nek a pályaoptimalizációra sok kis egyenes szakasznál például amit a cam programok generálnak.
 
 A modell például szeletelve véges egyenes szakaszra oszlik, ha minden pontot mi összekötünk akkor érthetően alacsony átlagsebesség jön ki. Valami trükk van mert mindenre pozitívan hat ki a pályaszerkesztő ezirányú optimalizációs törekvése. Mind szerszáméltartamra, mind felületre, mind végrehajtási időre . Arra mozdul a cam és a vezérlők világa hogy állandó értéken tartsa a szerszámterhelést a lehető legnagyobb pontosság mellett.  
 
Na de gondolkozzunk fizikában, ha lassulni kell és valamely tengely lóg akkor bizony a csökkenő erő miatt a lógó tengelyek el fognak mozdulni-csökken a szerszámra húzó vagy szerszámtól elnyomó erő nagysága, akkor meg aztán a vezérlő pontossága már semmit sem ér-szépen lassul, a rugóerő ami szíj miatt is lehet meg visrosszántja az asztalt. Szerintem hobbinál bármely gépet bele lehet küldeni ilyenbe.    
 
Bocsánat a sok sületlenségért.

[000000000]

Szia Gábor,
 
Hát igen, ha kicsit nagyobbra tervezünk akkor valóban kikerüljük. A gond ott volt, hogy nem tudtunk a csapdáról, hogy ki kell kerülni.
Vagyis nem tudtam, hogy ez gondot okoz nekik a gyártásnál. Régebben terveztem már olyan panelt aminél powerpad (olyan pad- ami a chip alján lévő pad-en adja át a hőt a panelra.) volt és a gyári ajánlás szerint volt rajta 12-20 via .. ez alapján meg sem fordult a fejemben, hogy egy 0805 padjén egy 0.25mm dia furat fondot okozhat.

[000000000]

Az uccnc-nek ugyanolyan pályaoptimalizációja van mint a linuxcnc-nek, egy az egyben ugyanúgy működik.
 
Nem, nincsen ott semmi gondolkodás, csupán addigra áll meg a tengely a sarkon 300mm/sec/sec lassulással.
 
A videón a példa (a négyzetnél) igen egyszerű, sarkallatos, a két szakaszt bezáró szög derékszög, vagyis 90°, ha a feltétel az, hogy a sarokpontot érinteni kell, akkor nincsen mire optimalizálni, mert egy egyenes szakasz van, aztán megint egy egyenes szakasz úgy, hogy az első mozgás után a tengelynek meg kell állnia (mivel a sarokpontot el kell érni úgy, hogy a másik tengely nem indulhat el, különben nem lesz pontos érintés) a második szakasznál pedig a másik tengelynek el kell indulnia, fel kell gyorsulnia. És ugyebár két pont között az egyenes szakasznál nincsen rövidebb út, szóval nincs optimálisabb út. Ez egyszerű fizika, lehet bármilyen hókuszpókuszokra gondolni, de a fizikát nem lehet legyőzni, akárhogy is szeretné sokszor az ember.
Ja még annyit, hogy megnéztem a beállításokban, hogy 89°-ra volt állítva a szög aminél megáll az optimalizálás, szóval ezért is írtam most, hogy a négyzetnél a sarkon pontosan át kellett haladnia...
Majd Januárban ha lesz egy kis időm, akkor levideózzuk ugyanezt a pályát az optimalizálást kicsit áthangolva.

[pisti73]

Sajnálom, azért már nagyon várom, hogy elkészüljön!

[000000000]

Ja és nincsen semmilyen szíj a rendszerben, mod 2.0 fogasléces hajtás van és 25:1 bolygóműves precíz áttételház, egyiknek sincsen rugalmassága, merev hajtástechnikai elemnek tekinthető mindkettő.

[000000000]

Köszi és tudom, hogy várod, én is eléggé elszomorodtam amikor kiderült a dolog nemrég.
De megfogjuk oldani és amint lehet gyártásba rakjuk az ISOBOB-ot, hogy ne kelljen már sokat várnotok rá!

[pisti73]

Köszi, szerintem mindenki nevében!

[sanyi84]

Akkor nem szóltam, ekkora gyorsulásnál persze hogy látványos a dolog. Én a mechanikára értem, minden gépnél előjön, ez olyan mint egy átfúrt alkatrészbe nútmarás, 1-2 századot de nagyobbat fog vinni a maród ha bármennyi lógás is van a rendszerbe. Na de ez nem a mechanika. 300 mm/sec2 gyorsulásnál/lassulásnál látványos. Nálam a lézernél nagy gyorsulások vannak, át tud lépni a pályatervező a rádiuszos sarkokon, sima saroknál nem, ott jön a gyorsulás/lassulás rész.  
 
Ez látványos a gépemnél mivel jobban égeti a kartont, pont a sarokba át is égeti. Ha rádiusz van a saroknál akkor nem, ott átlibben minimális sebességvesztéssel.

[fektiforg]

Gépem UCCNC -és átalakítását ünnepek miatt hanyagolom, sokat dolgoztam vele…
Tapasztaltam pár nyűgös dolgot.
Pl. Kézikerénél tengelykiválasztásra statikus kapcsolót használok, folyamatosan frissítve  
charge pump - LED jelével, sajnos kiválasztott tengelynél nem indul el a referencia pont felvétel.
Márpedig, a megoldás miatt mindig van egy kiválasztott tengely.  
Másik nyűgöm  - referenciára álláskor másnap már nem állt vissza a gép a próbadarabra, észre vettem nem nullázódik gépi koordináta rendszer referenciakapcsolóra álláskor.

[000000000]

Szia,
 
Köszi a hibajelzéseket.
Ezt a charge pump frissítéses ref. felvételt megfogjuk vizsgálni. Igaz, minden mást is újra végig kell "zongoráznunk", illeve majd a ti segítségeteket is szeretnénk igénybevenni az új API tesztelésénél, de ahogy írtam ennek már csak Januárban fogunk a végére érni, addig is a türelmeteket kérem.

[9npx2xk89]

Elfelejtettem írni, de hiába van nem resetben a gép akkor sem hajlandó az fro-t állítani, vagy legalábbis a képernyőn nem látszik, ugyan akkor mintha lassabban menne a gép, de a kiírás 90%-on marad.
Menet közben két +-al megy fel 90%-ról 100%-ra, tehát valószínű leveszi 80%-ra, csak a képernyőn marad 90%.

[xfg6v697j]

Balázs,kűldtem egy email-t.

[kr97pwss2]

Többen érdeklődtetek a napokban, hogy hogyan állnak a fejlesztések. A nagy csend ellenére a háttérben folynak a munkálatok. Az új programverzió kb. 90%-os készültségben van, és sok módosítást hajtottunk végre rajta (legfőképp a belső működésben, ill. tovább lettek csiszolva a már működő funkciók is). Mutatok is két kis videót. Az elsőn egy sima szinkron filccel rajzolás (menetvágás) látható: https://www.youtube.com/watch?v=_PVYLCoFoK8&feature=youtu.be" TARGET=_fnew>Menetvágás-1
A másodikon pedig két szinkron menetvágás van összekapcsolva, melyeknek különbözik a menetemelkedése: https://www.youtube.com/watch?v=kUwmSwNs8Tg&feature=youtu.be" TARGET=_fnew>Menetvágás-2
A videón látható mozgások az UCCNC program új készülő verziójával és UC300-5LPT-vel készültek, a főorsón egy 576 PPR-es inkrementális enkóderrel és Index jeladóval.

[Béni]

[#eljen]
Az esztergályosok szerintem meg lesznek elégedve.
Lesz egymenetes menetvágó ciklus?
(G32 vagy G33 stílusú.)