Smazat příspěvek

 Chystáte se smazat zprávu (se všemi případnými odpověďmi) z kategorie Hlavní diskuze:


5.04.2020 (23:21:13)
SOB's obalka :
vspomínáte, jak jsem tu scháněl radu ohledně servomotorů fanuc do 6-ti osýcho robota ? Tak už sem docela pokročil, ale mam pár problémů.
https://www.youtube.com/watch?v=qRDLMS1G2Is
Motor se točí, regulační smyčky sou vyladěný tak, že to nějak funguje, ale dost často, když zapnu driver (používám ten low cost leadshine) a aktivuju enable tak se motor rozjede plnou rychlostí pár otáček na ňákou stranu i přes to, že mu nedávám žádnej příkaz a pak se vypne s chybou pozice, dělá to jen někdy, setkal se s tim někdy někdo ? Může to bejt projev špatně nastavenejch regulačních smyček ?
Další problém, má to výstup na brzdnej odpor, kterej je zapojenej proti plusu a tranzistor v tom driveru ho spíná k nule, ale mě ten tranzistor sepne vždycky po zapnutí a je furt seplej...
Dík.
6.04.2020 (00:50:31)
8-bit obalka (web) :
Zapomene po vypnutí pozici a vyhodí chybu pokud nenajde index?
6.04.2020 (22:57:19)
SOB's obalka :
ten driver si přece pozici ani pamatovat nemá ne ? a i kdyby, jak jí pozná bez absolutního enkodéru...
Nenajde, index, tim je myšleno co ?
8.04.2020 (21:47:44)
8-bit obalka (web) :
Pokud enkodér není zálohovaný baterkou tak ten servopohon po zapnutí nemůže vědět, kde je. Nulovou angulární polohu by měl udávat impuls na index výstupu (Z) enkodéru. Je možné že driver se takto pokouší najít výchozí bod, proto se podívej do nějakého manuálu zda se někde to chování nedá nastavit.
10.04.2020 (15:06:32)
SOB's obalka :
tomu uplně nerozumim, když se zastaví motor a disk zůstane v pozici takový, že A, B, Z jsou třeba HIGH, LOW, LOW, vypnu to, znova zapnu, tak stav těch signálů je furt stejnej ať je enkodér zálohovanej nebo ne
10.04.2020 (21:22:44)
antibalda obalka (web) :
Tam spíše jde o to, že si "enkodér" musí pamatovat i kolikrát se otočil, aby si driver určil přesnou pozici třeba ramena. Jen kombinace signálů A, B a Z nestačí.
10.04.2020 (23:18:25)
8-bit obalka (web) :
Asi tak, prostě by to mělo být buď všechno zálohováno baterkama (tzn. nejen enkodér ale i nějaké počítadlo v servodriveru), nebo bys měl mít aktuální pozici nějak uloženu jinde a pak ji driveru vnutit ještě před tím než ho povolíš. Driver totiž nemůže vědět, že se s hřídelí mezitím neotočilo. A i když ty motory mají brzdy, pamatuj na to, že každá brzda má nějakou malou vůli, takže s každým vypnutím a zapnutím může pozice ujíždět. Když už, tak by se hodilo zabrzděný motor vždycky předepnout na nějaký konstantní moment pro zjištění polohy na které to zůstalo a při inicializaci. Hoď sem link na nějaký manuál k tomu tvému servodriveru ať se můžeme podívat co by se s tím dalo dělat.
10.04.2020 (23:40:14)
SOB's obalka :
Dík
http://www.cncshop.cz/acs806-ac-servo-driver-400w
tady je ke stažení manuál
Já sem žil v tom, že po znovu zapnutí začínám prostě na nule a kolikrát sem se otočil před tim, si musim pamatovat někde jinde v nadřazenym systému...
V tom manuálu ale toho asi moc nenajdeš, ještě udělám screen tabulky parametrů v tom programu
11.04.2020 (01:14:01)
8-bit obalka (web) :
Proletěl jsem ten manuál a o chování po zapnutí tam bohužel nic není. Měl by asi začínat na 0, ale ještě záleží zda vůbec k něčemu používá to Ztko nebo ho ignoruje. Ještě bych zkusil Z prostě odpojit a zkusit co se stane. Jinak máš zapojeny komutační signály? Nějak by to mělo fungovat i bez nich, akorát při spuštění může měnič rozběhnout motor špatným směrem nebo dělat různé vylomeniny. Podle mě by ta regulace měla vzpamatovat v řádu ms (je tam FOC), ale každý měnič se s tím asi může poprat jinak.
11.04.2020 (17:23:56)
SOB's obalka :
komutační signály tam mam, bez nich by se to možná ani nerozjelo, kvůli nim tam z toho robota visí ta deska s arduinem a 6-ti 485 převodníkama
11.04.2020 (19:04:24)
SOB's obalka :
začínám si myslet, že to nějak souvisí s tim, jestli před tim nedošlo k chybě pozice, a jestli si to nepamatuje kolik byla ta chyba a nesnaží se jí po restartu dohnat, ale to potom nevim, proč po tom startu po tom dohnání znova vyhodí chybu...
No nevim tyhlety startovní přechodový jevy mě pěkně serou, chová se to občas dost divně, jakmile to rozjedu do cyklu, tak to běží splehlivě jak dlouho chci, ale to počáteční rozjetí bejvá někdy na několik pokusů
11.04.2020 (20:06:01)
8-bit obalka (web) :
Ty komutační signály by měl měnič podle mě potřebovat jenom na rozjetí. FOC algoritmus si podle nich nastaví nějaké výchozí hodnoty a dál by měl polohu rotoru vypočítávat sám. Ale ujisti se že je máš správně nebo je zkus odpojit úplně, pokud to převádíš z toho FANUC protokolu nějakým mrduinem **02
11.04.2020 (20:40:42)
antibalda obalka (web) :
(vlastní zkušenosti s roboty)
Když jsem programoval roboty Mitsubishi, tak ty mají v patě robota baterky, který zálohují aktuální pozici v enkodéru. Robot bez napájení má vždy zamčenou brzdu. Po připojení driveru se vyčte aktuální pozice z enkodérů (jejich protokolem) a motory se odbrzďují a začíná pohyb. Toto je nutné, aby byla možná výměna driveru za jiný nebo nový.
Ještě mám zkušenosti s roboty Omron a FANUC - obě další firmy to mají stejně.
To že ti to po zapnutí cukne je neorigo driverem, který neumí vyčíst pozici z enkodéru. (manuál jsem neotevíral). Buď bych to používal takto nebo sehnal origo driver nebo vyhodil. Rozhodně bych se s tím takto netrápil - ty firmy přesně vědí, proč k tomu dávat origo driver.
Navíc je blbost, aby se po zapnutí robot nuloval - co když vypadne napájení z důvodu poruchy ?
11.04.2020 (22:31:08)
SOB's obalka :
nemusíš mi vykládat jak fungujou roboti, taky dělám s ABB a yaskawou, samozřejmě že to originálně fungovalo tak, že to přes komunikaci vyčetlo pozici z baterkou zálohovanýho enkodéru, jenomže abych zachoval tohle původní řešení, tak bych do toho musel narvat tak 150 000,- Tim, že se mi povedlo z toho enkodéru vatáhnout ABZ a komutační signály s tim můžu aspoň takhle fungovat za relativně pár korun, poslední pozici si budu pamatovat v nadřazenym systému v nějaký EEPROM, ve vypnutym stavu budou seplý brzdy, takže s tim nikdo moc nepohne.
Ten driver je určenej k servům, který nemaj nic víc než ABZ a komutační signály, baterkou zálohovaný taky nejsou a necuká to s nima po startu.
Ty byses s tím takto netrápil a vyhodil bys to... no já sem si to kvuli tomu koupil...
11.04.2020 (22:53:28)
SOB's obalka :
z fanuc protokolu ne, to sem zavrhnul, to by bylo hrozně složit. Už sem tu jednou postoval, že ten disk v tom enkodéru má na sobě vrstvu, která přímo odpovídá signálu jedný fáze, takže ty zbylý dvě od toho odpočítávám pomocí A a B signálů, funguje to si myslim velmi dobře i při vysokejch otáčkách, dokonce i když si dám osciloskop jednim kanálem na výstup třeba W a druhym kanálem na W mototru proti umělýmu středu, tak se to přesě kreje...
Ono to dělá jenom někdy, zkusim vysledovat, jstli to fakt nezávisí na předchozí chybě polohy
Nevim proč tu furt omlíváte zálohování baterkou, ty serva určený k tomu mýmu driveru nic takovýho nemaj, ani nevim kudy bych to do toho driveru připojil, on nemá vstupy na nic jinýko krom ABZ a komutace...Navíc má řízení jenom krok a směr, nic víc
11.04.2020 (23:13:26)
antibalda obalka (web) :
Podle toho, co tu píšeš poslední dny, tak jsem nabyl dojmu, že absolutně nevíš, co děláš. Takže se hned nevztekej.

FANUC si tam nandá svoje serva, svůj interfejs a další píčoviny a k tomu si udělá vlastní driver, se kterým to funguje tak jak má. A ty si myslíš, že to tu ojebeš mrduínem a nějakým univerzálním driverem ? **03 Dost naivní představa. Proč to origo asi stojí 150 000 ? Aby se to mohlo ojebávat ? Pak to takto vypadá.

Buď rád, že se ti to alespoň trochu hýbe.
12.04.2020 (00:40:05)
SOB's obalka :
Absolutne netušim co dělám a vztekám se až bušim pěstma do stolu.
A ano, myslim si, ze to ojebu ardujinama a lacinejma driverama za par korun. A rekneme si, zatim se mi to dari **01
12.04.2020 (10:06:12)
antibalda obalka (web) :
Ne, nedaří **37
12.04.2020 (12:20:49)
SOB's obalka :
prosim, ukaž mi jak to vypadá, když se daří
12.04.2020 (15:22:25)
VroutekB:
Šak on jen závidí hezkýho robota... **37
12.04.2020 (16:25:02)
SOB's obalka :
taky mi připadá, že v tom něco bude **13
12.04.2020 (17:49:19)
8-bit obalka (web) :
Asi tak, buď je to čistá závist a nebo je natěšený na to, že se v bazaru na CNC fóru objeví hromada levných harmonických převodovek které koupí aby s nima mohl šmelit **02

>SOB's
Zálohování baterkama omíláme proto, že ty pseudo-absolutní enkodéry musely mít původně zálohované napájení přes FANUC drivery. Sice si můžeš pozice ukládat do EEPROM nebo baterkou zálohované SRAM, ale můžou se ti takhle začít kumulovat chyby.
No dobře, tak teď víme že výstup z toho enkodéru je nějak doprasený. Proto ještě zkontroluj zda máš fakt správně komutační výstupy a jejich polarity, ideálně podle nějakého normálního serva. A Ztko bych odpojil úplně, driver by ho neměl k ničemu potřebovat.
12.04.2020 (19:03:55)
SOB's obalka :
zkusil sem si ještě jednou dát na osciloskop výstup jedný fáze proti umělýmu středu a výstup příslušenýho komutačního signálů a uplně přesně se to nekreje, tak sem zkusil trošku pootočit enkodér abych to doladil, aby to vycházelo přesně, ale lepší to rozhodně nebylo, bylo to stejný a přidali se jiný problémy, tak sem enkodír vrátil zpátky.
Ono jakmile překonám ten počáteční enable po startu, tak už je to v pohodě, můžu enablovat kolikrát chci a vždycky v každý poloze to drží a má to stejnej krouťák do předu i do zadu, takže v komutaci podle mě problém neni.
Zkusil sem odpojit Ztko, nemělo to žádnej přínos.
Zkusim si ještě pohrát s rgulačníma smyčkama, jestli třeba to rozjtí po zapnutí neni způsobený nějakym překmitem třeba rychlostní smyčky...
12.04.2020 (22:45:17)
antibalda obalka (web) :
Jediného robota, kterého bych záviděl by byl Mitsubishi. Fanuc rozhodně ne - programoval jste někdo Fanuc ? Navíc ani mechanika není žádná výhra. Takže ne, závist to není. **37
12.04.2020 (23:15:56)
SOB's obalka :
**01
13.04.2020 (15:18:17)
SOB's obalka :
Tak sem zkusil snížit všechny Pčka, servo se převaluje jak lempl a stejně se stává, že to po startu vystřelí někam a zastaví to až překročení povolený chyby.
Zkusil sem i invertovat všechny komutační signály, nebo je různě prohazovat, furt stejný, ty signály asi mam správně, protože servo de klidně do vysokejch otáček a s velmy malym odběrem, ale jde o to, jstli sou správně časovaný, což sem si ověřil osciloskopem, že sou...
Jinak, vzhledem k tomu, že ty procesory co mi generujou ty komutačí signály mam v plánu mít v tom rameni furt pod napětím aby nestratily nit, tak asi neni problém aby mi posílali aktuální pozici
13.04.2020 (20:14:16)
Dreit obalka :
Co vzpomínám na školení před asi půl rokem, tak brzdy nemusí dokonale držet a u hodně jetých Fanuců se prý stává, že se třeba přes noc enkodér trochu pootočí a elektronika to pak nerozdejchá.
Jestli si dobře vzpomínám, tak se muselo pohnout s osou aby každej enkodér udělal alespoň jednu otáčku, zastavit na ryskách a pak si to nějak dokázal dopočítat. Kdyžtak mrknu do školících papírů co k tomu mám, týká se to samozřejmě origo řízení, ale třeba by to k něčemu pomohlo.
13.04.2020 (21:01:51)
SOB's obalka :
u toho fanucu je to kvuli tomu, že jsou z těch pulzů vypočítávaný komutační signály, takže když se vybije baterka, tak stratí nit a musej pak udělat aspoň jednu otáčku, aby se zorientovali, ale neni mi jasný proč by k tomu mělo dojít při pootočení enkodéru, leda opravdu v kombinaci se slabou baterkou.
No ty brzdy maj jednak vůli několik půlzů a taky jdou přeprat rukou bez větší námahy, pokud točim přímo hřídelkou...
pokud bych zkusil vzít za rameno, tak přes ten převod 1:50 už tu brzdu nepřeperu
13.04.2020 (21:46:28)
antibalda obalka (web) :
Tak abych jen nekritizoval.
Pokud bych chtěl toho robota používat (což jsem pochopil, že by jsi chtěl), šel bych na to úplně jinou cestou a to, že bych zkusil okopírovat originální driver. Je mi jasný, že origo komunikaci mezi enkodérem a driverem nedekoduješ (kdysi jsem se o to pokoušel na Mitsubishi servech), tak bych si udělal vlastní. Tj. na každý servo bych si udělal DPS, kde by bylo zpracovávání pulzů A. B, Z a další komunikace s nadřazeným systémem (třeba arduinem). Jako komunikace se nabízí třebas RS-485, kam si můžeš definovat jakýkoliv příkazy (prostě si napsat vlastní protokol). Zároveň by si tento výtvor mohl pamatovat pozici (udělal by jsi z toho absolutní enkodér), která by mohla být zálohovaná bateriemi. Celé by to pak řídilo třebas arduino (kdyby AVR nestačilo, mohlo by být STM32), který by počítalo požadované pozice a do silové části by pak posílalo pulzy o kolik se má dotyčný motor otočit (tak jak je to u origo driveru). Silovina by neměla vstupy na enkodér a jen by hloupě poslouchala příkazy. Následně by to šlo celé řídit jako (upravené) CNC.

Vím, že je to trochu složitější řešení, ale myslím si, že toto, jak to máš nyní nevede k výsledku (viz ty problémy, co máš).


__________________________
K robotům Fanuc :
Pokud se vybijou baterie, musí se udělat reference. Standardně má na sobě robot přesné díry do který se strkají přesné kolíky a když je robot takto zakolíkovaný - řekne se mu, že je v "nule", následně si to uloží do enkodérů a už ví pozice. Před tímto se musí udělat pohyb všemi osami, aby se našly komutační signály.
13.04.2020 (22:10:57)
SOB's obalka :
no já sem nad tim taky přemejšlel, teď mam v podstatě hotovej návrh plošňáku na destičku ke každýmu enkodéru, která bude generovat komutační signály a společně s ABZ převádět na diferenciální pár aby se to dalo zapojit přímo do driveru, ten procesor mam v plánu mít trvale pod napětím (práve kvůli těm komutačním signálům) jediný co by se vypínalo, tak ty 485 drivery, protože hrozně žerou, takže bych tam přidal ještě CAN, na tej jednej CAN sběrnicy by bylo připojeno všech 6 destiček a pak bych si udělal jednotku, která by dostávala z nějakýho nadřazenýho systému rozkazy o úhlech kloubů, skontrolovala by si vždycky jak jsou klouby natočený aktuálně a podle toho by do servodriverů vyslala příslušnej počet kroků příslušnym směrem, v podstatě jak píšeš ty, akorád ne 485, ale CAN, příjde mi tam snadnější sběr dat z více zařízení...
Jedinej problém je ten procesor, aby byl schopen spolehlivě generovat komutační signály, i při vysokejch otáčkách, musí mu programová smyčka běžet na vysoký frekvenci, mě to arduino běží po menší optimalizaci asi na 50-ti KHz ale nesmí dělat už nic jinýho (třeba odesílání dat) jinak by ty frekvence šla dolu. Takže buď procesory dva, nebo jeden pořádnej...
13.04.2020 (23:43:48)
SOB's obalka :
tak sem teď zjistil, že se to po startu nekontrolovaně rozjede jenom tehdy, když je zrovna motor zastavenej tak, že U, V, W je LOW, LOW, HIGH nebo HIGH, HIGH, LOW zkrátka kvadrant, kdy má U a V stejnej stav, co to může znamenat ?
14.04.2020 (01:27:41)
SOB's obalka :
sem tak zjistil, že ten driver moc na ty komutační signály nedbá, zkusil sem ošetřit ty dva stavy, dal sem místo nich vedlejší a vubec nic se nezměnilo, tak sem zkusil tam na zkoušku nahrát program na pevnou hodnotu HIGH, LOW, LOW a nijak zvlášť se to nezhoršilo **02 tak mě napadá, jestli tam ty signály správně posílám, má to vstupy popsaný například HallW+, HallW- posílám to tam přes 485 driver, Ačko na + a Bčko na -...
14.04.2020 (02:41:20)
8-bit obalka (web) :
Znamená to, že jsi evidentně nevyzkoušel všechny možné permutace zapojení a polarity těch komutačních signálů a ještě jsi netrefil tu správnou **02 Jak jsem už psal - sežeň si jedno nějaké normální servo a pak nějak zařiď aby z těch tvých doprasených enkodérů lezlo to samé **02
14.04.2020 (02:51:35)
8-bit obalka (web) :
Jo a ještě je klidně možné, že enkodér dává úplně jinou sekvenci kvadrantů. Myslím že v tom vlákně na cnczone psali, že enkodér posílá kvadrant jako binární číslo v nějaké čísti té zprávy, takže vzor na tom skleněném disku se ani nemusí shodovat s normálním enkodérem.
14.04.2020 (10:17:03)
antibalda obalka (web) :
Nepoužíval bych CAN, to raději RS485. Na sít můžeš pověsit kolik chceš zařízení, akorát jim musíš přidělit unikátní ID. Pak posíláš zprávy s ID a zařízení, kde se ID shoduje, vykonává příkaz, zbytek zařízení zprávu zahazuje. Funguje to, akorát rychlost není moc velká - je to half-duplex. Ještě se nabízí RS422, kde je vyšší rychlost oproti RS485.

Procesor bych tam dal třebas STM32G071 (verzi s 48 nohama, aby to mělo dedikovaný VBAT pin), případně jiný. Pokud tam bude zapojen pouze jeden enkodér a jedna komunikace, výkonu bude nazbyt.
14.04.2020 (12:35:13)
VroutekB:
Ty toho natlacháš. RS485 je podstatně rychlejší, než CAN, i než CAN-FD. 485 můžeš hulit na 10 i více Mbps zcela bez potíží.
Na CANu není nic špatného, naopak je s ním podstatně míň sraní, než s vymejšlením vlastních nedomrlých protokolů na 485. Když už 485, tak si tam aspoň implementujte Modbus, ať je to pak aspoň s něčím kompatibilní.
14.04.2020 (14:00:44)
SOB's obalka :
ten skleněnej disk má jednu stopu, na který jsou 4 drážky, který přesně odpovídaj Wčku, ostatní dva od nich odpočítávám pomocí AB impulzů, vůdči EMF mi to všechno souhlasí, vyzkušel sem už hromadu kombinací ale tahle jediná jakštakš funguje...
Hodil by se mi nějakej procesor, kterej má tu vestavěnou periferii na dekódování kvadraturních signálů a kterej umí nějakej sleep mód, mam tu pár STM32F103, nešlo by to s tim ?
14.04.2020 (16:11:50)
VroutekB:
Šlo. Ale nestačilo by ti něco menšího? Třeba F030F4?**02
14.04.2020 (16:16:56)
antibalda obalka (web) :
Vroutku, dost dobře si pamatuji, že jsi mi CAN zakazoval, protože je tam problém dodržet časování. Nutil jsi mi RS485, protože s tím není tolik sraní. Ale chápu, že názory se vyvíjejí.
Dle mého názoru nepotřebuje žádný ModBus, protože to stejně nebude nikam připojovat (akorát ke své destičce), takže zbytečný komfort.

PS. Pokud vím, tak STM32F030F4 nemá dedikovaný VBAT pin. Možná to ale nechce zálohovat, takže pak je zbytečný tam dávat potvoru s 48 piny.
14.04.2020 (16:40:06)
SOB's obalka :
no procesor a enkodér musej běžet furt, enkodér bere asi 50mA a procesor nevim, ale do 10-ti mA by to bejt mohlo.
Ten CAN se mi líbí, protože je s nim míň práce a velkou rychlost já nepotřebuju, já jenom potřebuju to co nejrychlejš nasypat do tranciveru aby si moh program dál jet svoje a nebyl tim bržděnej.
Když by bylo zařízení vyplý, tak by běžel jen procesor a enkodér, jakmile by se zařízení zaplo, tak by se zaply linkový drivery na komutační a ABZ signály (MAX485) a zapnul by se i ten CAN tranciever MCP2515 a začal by bez ptaní chrlit data o pozici
14.04.2020 (17:45:20)
VroutekB:
Lol, tak do 10mA na procesor nepotřebuješ snad ani sleep mode.
Btw, neni trochu hloupý živit enkodér i ve vypnutým robotovi? Mi neříkejte, že to jinak nejde.

Antiblada: Nepamatuju si okolnosti, ale nechtěl si to tak náhodou tenkrát bitbangovat softwarovo ten CAN? **02
14.04.2020 (17:48:02)
SOB's obalka :
to už bych ten enkodér musel nějak nabourat a používat z něj jenom ten optosráč, ten by měl klidovou spotřebu nižší, ale jak tu bylo řečeno, enkodér musí bejt schopen počítat otáčky i při vyplym robotu, protože brzdy maj vůle a kumulace chyby a tak...
14.04.2020 (18:45:24)
VroutekB:
To se timpádem ale oklikou dostáváme k tomu, že nejlepší by bylo zachovat původní enkodér i s původním zálohováním. Pochybuju, že v původním stavu to potřebuje 50mA na zálohu na každé ose **13

Dybych tu měl jeden ten enkodér, tak sem moh zkusit omrknout co z něj leze a případně to nějak pohákovat. **20
14.04.2020 (18:49:50)
SOB's obalka :
neposlal sem ti to, protože si myslim, že to neni cesta, vyžaduje to hromadu vývoje a hromadu programátorský práce, se kterou si já nepoadim, tim pádem by to bylo závislý na tobě což by mohlo způsobit zmražení projektu.
60mA na osu ve vypnutym stavu mi nevadí, s tim se nějak poperu, dám do patky několik Lionek, který se při každym zapnutí budou dobíjet
14.04.2020 (20:50:36)
VroutekB:
Ale jakou hromadu vývoje zas... to o co se teraz snažíš je možná eště větší cesta do pekla, než to rozchodit tak jak to bylo původně. Jestli na tom cncforu maji pravdu a stačí tam jen poslat hentamtěch pár bajtů aby to vyprdlo pozici i komutační signály, tak bych to aspoň zkusil.
Pokud to chceš obcházet, tak místo rozchození (imho poměrně jednoduché komunikace) budeš muset: omrdat enkodéry, abys z nic hvytáhl čisté ABZ, udělat plošáky s diferenciálníma budičema, navrhnout na to desky, dodělat tam procesomrem generované komutační signály, vyřešit zálohování, nabíjení a vybíjení zálohovací baterky, kompletní vestavbu do ramene... kurde, to mě nyní přijde jako podstatně víc práce, než to zkusit rozchodit v původním provedení **13
14.04.2020 (23:35:30)
SOB's obalka :
tak už sem našel kombinaci komutačních signálů, při který mi to nedělá kraviny a nerozjíždí se to samo po zapnutí.
Teď už se můžu věnovat jenom doladění PID regulátorů a těm enkodérům.
Víš Vroutku, jde o to, že to cos vyjmenoval ohledně mojí verze řešení neni málo práce, ale já sem ochoten to udělat, protože to bude moje řešení, uvidim do toho a všechno to sou úkoly, který dokážu splnit, v podstatě, když mi pomůžeš vybrat procsor a případně mi dáš nějaký rady jak ho programovat, tak příští tejden odesílám gerber data do plošňákovny. Pokud by se jednalo o rozklíčování tej fanuc komunikace, myslim si, že to natáhne vývoj na hrozně dlouho a budou s tim problémy a může se ukázat, že je to nepoužitelný, navíc to sou věcí, který můžeš dělat jenom ty a ty se tomu taky nebudeš věnovat od rána do večera a já mezi tim budu stát, protože ti nebudu umět nijak pomoct. Navíc co sem to tak pročítal, tak tam sou docela svinstva, jako např. skoková změna pulzů na otáčku při překročení nějakejch otáček, další věc, že ten fanuc systém má při tý nízký rychlosti milion pulzů na otáčku... to se z toho to arduino sesype než vygeneruje jednu otáčku, takovou přesnost já nepotřebuju, navíc si sám řikal, že je problém ty signály zase vygenerovat pomocí toho hradlovýho pole
15.04.2020 (00:55:07)
8-bit obalka (web) :
Nepotřebuješ vyhodnocovat milion pulzů na otáčku - nižší bity můžeš ignorovat a zpracovávat jen to co je platné při maximálních otáčkách. Převodník pro těch 5 enkodérů by se pak v pohodě vešel do jednoho XC9572XL.
15.04.2020 (02:39:25)
VroutekB:
Já nebudu ale nic rozklíčovávat. Já zkusím použít to, co vykoumali jiní. A buď ty data z toho dostanu, nebo řeknu že to nejde a dávám od toho ruce pryč - protože na nějaký "rozklíčování" by člověk potřeboval i původní servodriver a ve funkčním stavu měřit za chodu. To už není ta práce na jedno max dvě odpoledne, co sem chtěl s tím zkoušením jestli vyčtu data.
I kdyby to mělo dovíkolik pulzů na otočku, tak to nikoho neprdí. AVR řady tiny/mega jsou mrtvej šrot dneska, s naprosto zaostávajícíma periferie. To i ty nejlevnější 8bitový ST procesory koupitelný v kusovce pod 10Kč kus (STM8S003F3P6) mají timer s dedikovaným módem pro enkodér. Je tomu pak vykuřbuřt kolik má ten talíř pulzů na otočku, I kdyby měl 64kpulzů na otočku, tak to i při 3000RPM bude nejspíš stíhat.

Nevim co by 8bit chtěl strkat do toho CPLD, origo enkodéry kecají po 485, tam by se pak hodilo nějaký FPGA. A to taky není vývoj na měsíce, udělat 5 nebo 6 UARTových periferií a z druhý strany to ládovat někam dál. Zrobit UART ve VHDL zvládnu **02
Záleží, co bys s těma polohama chtěl dělat dál, jestli je třeba nutné je opět převádět na kvadraturní pulzy a emulovat enkodér - trochu vopruz. Neřikám, že to nejde, ale nepřemejšlel sem o tom jak to lze udělat.
15.04.2020 (04:19:35)
8-bit obalka (web) :
No jenže pokud by chtěl použít původní, nedoprasené, enkodéry, nepotřebuje timer s kvadraturním vstupem ale musí pomocí 5 "UARTů" rozebrat ty zprávy a pak podle rozdílu poloh kvadraturní pulzy generovat. Zkrátka převést tu věc na normální enkodér. UART periferie v mikroprocesorech je ale nepoužitelná protože ve zprávě jde 70 bitů po sobě. Pokud ale předpokládám, že zprávy ze všech 5 enkodérů budou mít stejné časování (jakože asi jo pač psali že servodriver musí napřed poslat požadavek), vejde se zapojení asi do 10 klopáků společných a pak cca dalších 10 pro každý kanál (podle toho, jaké rozlišení chce zachovat vs. počet platných bitů které má garantováno že dostane). Takže to vidím na 9572, max. 2/3 95144 kdyby teda k něčemu chtěl těch 16 b na otáčku **01 Jo a jinak vyserte se na VHDL, stáhněte xilinx 10.1 a pište to v ABELu **02

Ještě když tak nad tím uvažuju, MOŽNÁ by se na to dal znásilnit i procesor - podmínkou je DMA co se dá clokovat těma 1,024 MHz a rychlé interrupty na generování kvadraturních pulzů.
15.04.2020 (14:04:27)
SOB's obalka :
no, aby teda bylo jasno, když už se do toho pouštět, tak aby to mělo smysl, tak to musí fungovat takto:
https://2i.cz/images/2020/04/15/IMAG1804.jpg
VroutekBox bude generovat komutační a kvadraturní signály přímo pro servo driver (tady se bojim, že bude největší problém, zase to všechno naladit a vyvinout aby to fungovalo) a dál mi bude po CANu třeba posílat aktuální polohu, kterou vyčte z enkodéru i po vypnutí, já tu aktuální polohu vemu, porovnám s žádanou a podle toho vyšlu impulzy do servodriveru aby tu polohu realizoval (to, jestli jí realizuje správně je už věc jeho PID regulátorů, ale to už mě tolik nesere, to totiž nezpůsobí kumulaci chyby)
Existuje ještě poloviční řešení a sice, že kvadraturní a komutační signály si budu získávat tak, jak to dělám teď, s tim, že VroutekBox mi bude jen vyčítat z enkodéru tu aktuální polohu, to se mi ale vubec nelíbí, protože to je snad nejsložitější a nejzbytečnější varianta, když totiž ten svůj převodník budu mít stejně trvale pod napětím, tak si rovnou tu aktuální polohu můžu pamatovat pomocí něj
15.04.2020 (14:28:21)
SOB's obalka :
https://2i.cz/images/2020/04/15/IMAG1806.jpg
No a nebo je tu moje verze a sice, že u každýho serva bude jedna malá roztomilá destička, do který bude přivedeno pár drátků, který povedou z testpadů na desce enkodéru, která bude generovat komutační i kvadraturní signály a taky bude mít na sobě CAN modul, kterej bude při zapnutym napájení posílat informace o poloze, která mě bude zajmat nejvíc po zapnutí, procesor a enkodér budou trvale pod napětím z baterie, linkový drivery a CAN převodník budou pod napětím jen při zapnutym napájení, protože hrozně žerou a ve vypnutym stavu je nikdo nepotřebuje
15.04.2020 (20:14:34)
VroutekB:
Musel bych se zamyslet, jak emulovat enkodér interfejc. Komutační signály sou triv, ale ten kvadraturní pulsetrain ne ta úplně. Dám vědět, jestli se něčeho dohrabu. Pokud ne, jebat na to, sprav to jinak.
Předpokládám, že jinej vstup polohy do těch unidriverů neexistuje. (ach bože... přitom tak máááálo softwaru by tam navíc stačilo...)
15.04.2020 (21:14:50)
SOB's obalka :
ne, bohužel ne, je to uplně tupej defaultní driver, taky stojí na ebayi necelý 3 litry (potřebuju jich 6, takže si umíš představit, že je velkej tlak na cenu)
Abych se přiznal ani sem nezkoušel hledat jinej. Tenhle mi maxiálně vyhovuje.
Dva budu muset nabourat a pokusit se je předělat, aby budící část zvládla 170V (má deklarováno max. 80, ale serva na první a druhý ose sou na 170V)
16.04.2020 (00:39:10)
VroutekB:
Tak jo, asi vim jak ten emulátor enkodérů ve FPGA udělat. Zejtra něco lehce zkusim, ať mám nějakej tréning ve VHDL, potřebuju to jako sůl. **20
16.04.2020 (01:37:55)
VroutekB:
Tož poslušně hlásím, že generovat 2bitovej grayův kód s proměnným kmitočtem ve FPGA je tak triviální, až to bolí. **02
https://i.imgur.com/QWutp8s.png
Zbývá naroubovat UART/485 udělátor se stavovým automatem a PS regulátor. Teď už na to kašlu. **01
16.04.2020 (03:40:44)
SOB's obalka :
výborný
16.04.2020 (05:31:30)
8-bit obalka (web) :
Moc dlouhé **02

[A,B].d = [!B,A] $ dir;
16.04.2020 (09:37:52)
VroutekB:
A to co za nečitelnou prasárnu má bejt?
16.04.2020 (09:55:02)
VroutekB:
Po troše přemýšlení a hledání mi připadá, že sis tu utřel nějaký sopl v ABELu, akorát i s manuálem syntaxe mám poněkud problém vyluštit co dělá levá strana výrazu. Ještě že tyhle zkurrrr... HDL už vychcípaly. Nečitelná rakovina z dob, kdy se muselo šetiřit znaky v paměti počítače.
16.04.2020 (14:51:42)
8-bit obalka (web) :
Evidentně je to kvadraturní počítadlo **02 Výraz se dá rozložit na
A.d = !B $ dir;
B.d = A $ dir;
stačí přidat [A,B].clk = CLK50; a [A,B].ce = pocitej; a máš půlku práce hotovou **01
Jinak musím tě zklamat - ty jazyky nevychcípaly, xilinx má program XPORT který mi to přeloží do VHDL **02
16.04.2020 (15:24:51)
VroutekB:
A seru kABEL na ABEL **02 Nepotřebuju dělat v nějaké nečitelné staré rakovině, ve které se sám po napsání 20 řádků nevyznáš. Výhoda VHDL a i celkem Verilogu je, že to přečte a pochopí povětšinou i člověk, kterej v tom nemá zabořenej rypák od rána do večera. **13
(btw, Intel ABEL stále podporuje taky)
Btw, ač tomu ABELu nerozumim, tak stejně nějak postrádám, kde generuješ ten proměnnej kmitočet **02
16.04.2020 (15:58:02)
8-bit obalka (web) :
Na co proměnný kmitočet? Bych prostě použil maximum co podporuje ten driver.
delicka.d = (delicka == 0) & FREKVENCE # (delicka != 0) & delicka - 1; [A,B].d = [!B,A] $ dir; [A,B].ce = delicka == 0;
16.04.2020 (18:22:13)
VroutekB:
Co tam hulíš, že jsi tak totálně mimo? Karanténa ti zjevně nedělá dobře. **02
Ne, nelze použít fixní kmitočet na vstup servoměniče.
Stejně tak je k hovnu dělička, potřebuješ aby výstupní kmitočet pulzů odpovídal okamžitý rychlosti pohonu.
16.04.2020 (19:27:51)
SOB's obalka :
zaprvý a za druhý by tam nemělo bejt žádný velký zpoždění, jinak to nebude možný uregulovat
16.04.2020 (21:41:58)
8-bit obalka (web) :
Ale lze - prostě jak dostaneš pozici z enkodéru (tj. asi každých 100 us, což určitě není o moc víc než je perioda FOC smyčky toho driveru), naclockuješ mu počet pulzů o které se nová pozice liší od předchozí. Klidně maximální frekvencí kterou stihne počítat. Asi bys mohl pulzy rozdělit rovnoměrně do těch 100 us (použil bych něco na způsob Bresenhamova algoritmu), ale podle mě je to zbytečná práce.
17.04.2020 (12:48:38)
VroutekB:
Ale velký hovno, to by ti fungovalo kdybys věděl výpočetní periodu, se kterou to pulzy zpracovává. Jenže nevíš ani tu a nemáš ani synchronizaci na výpočet, tak jak si to pak představuješ, že by to fungovalo?
A místo vymýšlení konin s bresenhamem, stačí použít state observer 2. řádu, kterej prostě bude fungovat téměř zaručeně a z výstupu půjde prakticky totéž, co by šlo z normálního enkodéru. **13
17.04.2020 (12:56:24)
VroutekB:
Čemu není na následujícím obrázku rozumět?
https://i.imgur.com/gUV11Hw.png
Ten výstupní integrátor pak tvoří fázovej akumulátor "DDS", která mi generuje ty kvadraturní pulzy.
17.04.2020 (14:55:08)
8-bit obalka (web) :
Beztak by se hovno stalo kdybys to clockoval maximální frekvencí, servodriver má totiž vlastní observer, kupodivu. A jinak Bressenham používá pokud vím inkrementaci a odčítání, kdežto v té tvojí šílenosti vidím dokonce i násobení a dělení **02 Tak potom napiš kolik LE tohle sežere pro 1 enkodér hoď sem screenshot simulace, pravděpodobnost že to bude fungovat bude asi tak hození mincí **02
17.04.2020 (18:49:28)
VroutekB:
Připadáš mi nějakej natvrdlej. Když nevíš s jakou periodou a kdy probíhá výpočet toho observeru v servoměniči, tak mu to tam prostě nemůžeš ty pulzy srát kdy se ti zachce.
Mám v pr..i kolik LE to sežere, neb mám asi 1000 LE a 5 HW násobiček k tomu na jednu implementaci i v tom nejlevnějším FPGA, který se dá koupit za 50 korun.

A kde tam vidíš dělení, to si rád nechám vysvětlit. Snad nemyslíš to Ki/s nebo 1/s ... to radši jdi vrátit diplom. **02
17.04.2020 (19:40:30)
VroutekB:
A navíc, já to beru jako příležitost se naučit nějaký čitelný HDL, navíc na zajímavé a užitečné aplikaci. Takže je mi ve výsledku fakt jedno, kolik resourců to sežere.
17.04.2020 (20:12:12)
8-bit obalka (web) :
Jo, vysral bych tam ty pulzy VŠECHNY. Maximálně bych ten burst rozdělil na půlky pokud by to náhodou dělalo bordel - víc jak 20kHz výpočetní periodu ty sračkoměniče určitě nemají. Kolik LE to sežere by tě zajímat mělo, pač čím složitější ten paskvil navrhneš, tím větší je šance, že tam něco zkurvíš a tím větší kokino bude odsimulovat všechny stavy co můžou nastat. A dej mi prosím tě link na ta FPGAčka za 50 kč **02

Nechce se mi ty obdélníčky a kolečka luštit, ale znak '/' je obvykle znamená dělení. Jestli ne, tak to není můj problém - máte to napsat srozumitelně, ne nějaká zkurvená řecká písmena se stříškama a vlnovkama a do toho ještě jakési přetěžování operátorů **02 Měli jsme tyto srágory v jednom jediném předmětu který byl povinně jen jeden semestr a ještě na jiné fuckultě, takže se nemůžeš moc divit že jsem to všechno pozapomínal. Pokud se to totiž objevilo znova jako volitelný předmět, zapsal jsem se na cokoliv jiného místo toho, pač to byl děs už od začátku. Myslím že se tomu předmětu říkalo "Řízení a buzerace I - IV" **02
17.04.2020 (21:49:33)
SOB's obalka :
to je myslim [fí] a [omega] a podobný schéma si určitě viděl při příležitosti PID regulátoru, taky ti tam vstupuje žádaná veličina a porovnává se se skutečnou, vylejzá z toho chyba a pak se z tý chyby různejma způsobama vyrábí akční veličina...
19.04.2020 (12:05:39)
VroutekB:
Tak teď nevím, jestli ze sebe děláš blbýho naschvál 8bite, nebo máš ten diplom jít fakt vrátit. To nevíš co znamená v laplacce 1/s a jak to vypadá po Z-transformaci do diskrétu?
Slabší odvar z "řízení a buzerace" sem měl taky, ale považuju to za jednu z nejužitečnějších věcí, co mě v tý škole naučili, když nepočítám jiný základy k pochopení pokročilý matematiky s klikatými hady a jinými divnými symboly, který se občas někde potkají,

1/s je integrátor. kapiš? Tam žádný dělení neptořebuješ. Po Z transformaci to znamená: "Vemu starou hodnotu a přičtu k ní novou, zapamatuju co vyšlo." To fakt nevede na žádný operace dělení. nejsložitejší operace je tam to násobení a na tu máš ve FPGA obvykle dedikovanej HW.

Celá diferenciální rovnice pro PS regulátor v přírůstkovým tvaru je y(n) = y(n-1) + A0*x(n) + A1*x(n-1), kde A0 a A1 jsou konstanty (A0 = Kp+Ki, A1 = Kp). Já na tom nevidím nic, co by se nedalo v HW triviálně spravit.
https://i.imgur.com/p8x51rK.png
A na to aby to fungovalo, potřebuješ akorát neuvěřitelně složitej stavovej automat o 3 stavech: Dělej howno, násob A0, násob A1.

Na implementaci 16bit fixedpoint PS regulátoru potřebuješ akorát jednu 16x16 násobičku, jeden 32bitovej akumulátor (registr + sčítačka), jeden 16b registr stavový proměnný x(n-1) a pár multiplexerů, abys na vstupu sčítačky mohl prostřídat ty dvě konstanty a na druhým vstupu x(n) a x(n-1).

Pořád ti na tom připadá něco neuvěřitelně složitýho a nerealizovatelnýho? Možná to, že je v tom schématu dlouhá kombinační cesta zleva až k tomu ACCumulátoru, ale tak HWová násobička ve FPGA má volitelný dedikovaný registry v sobě, takže jí oregistrovat ze všech tří stran stojí ve fabricu přesně 0 resourců navíc a jen to přidá asi dva stavy do toho řídícího automatu. A i bez těch registrů to poběží víc než dost rychle, na to co je potřeba.

Snad jsem to srozumitelně vysvětlil.

Ultralevný FPGA máš třeba EP4CE6E22C8N, nebo cokoliv menšího od Lattice, třeba LCMXO2 řada.
19.04.2020 (15:29:25)
8-bit obalka (web) :
No tak dal jsem na myšoseru hledat LCMXO2 a nejlevnější je LCMXO2-256HC-4SG32C s 256 LUT za $2.83. Další má 1280 LUT za $5.45 a další 2112 (1 LE = obvykle 2 LUT) za $9.95. EP4CE6E22C8N je za $12. Jsou to pořád dobré ceny, ale bohužel se ani nepřibližujeme k 50 Kč.

Ok, z nového obrázku tomu už rozumím, díky. Akorát je sice pěkné že máš 5 HW násobiček, nicméně jich budeš potřebovat celkem 6 **02 Takže ta poslední bude vyskládaná z logiky bude mít úplně jiné časování než ostatní. Bressenham by potřeboval jenom sčítání. Evidentně tě na té škole nenaučili, jak to udělat efektivně **23
19.04.2020 (19:27:03)
VroutekB:
A já někde psal, že jich tam je 5? EP4CE6E22C8N na kterým bych to poskládal, je 15 kusů 18bitových násobiček.

Ty, majstr přes šmelení z číny mě budeš říkat, že nevíš, kde se dá koupit FPGA levně? **38
Jinak, další zajmavej tip, levný hezký CPLD máš třeba EPM240T100C5N **22
19.04.2020 (19:38:32)
8-bit obalka (web) :
Jo, tak to potom OK, ale psal jsi že jich máš 5 v postu z 17.04.2020 (18:49:28). A stejně by s Bressenhamem bylo minimálně daleko míň práce **23

Aha, teď koumám že na LCSC mají těch CPLD a FPGA mrtě - myslel jsem že tam toho moc nebude ale evidentně jsem se spletl. Tak dík za nakopnutí **02
19.04.2020 (19:57:42)
VroutekB:
Asi sem do tý jedničky na klávesnici málo třískl, většinou to po sobě nečtu. Klidně si ověř v datasheetu, že jich tam je 15, nevěříš-li. LCMXO2 jdou taky pošmelit z číny, když se dobře díváš. Ale s těma jinak neporadim, s Lattice nedělám.
A i kdybych měl tu jednu násobičku multiplexovat, jen se rozroste multiplexer v tom dolním vstupu násobičky na té čmáranici výše.
No to sem rád, že se ti konečně rozsvítilo **02
Některý dnes oblíbený druhy FPGA nejsou drahý, pokud se kupují někde, kde to není exkluzivní zboží na kterým hrabou zlomyslný markeťáci místních distributorů/židů. **01
19.04.2020 (20:18:08)
8-bit obalka (web) :
Jo, mají tam pěkný výběr, třeba spartany 6 (byť je to asi nejmenší verze co existuje, ale i tak) za $5.4775. Jinak nevíš o něčem malém co moc nežere a má pár LVDS vstupů a aspoň jednu PLL? Jak jsem se naposled díval tak na chybějící PLL právě hřešily ty levné Lattice.
19.04.2020 (20:46:52)
VroutekB:
LCMXO2 mají PLL aspoň jednu snad všecky ne?
https://cz.mouser.com/datasheet/2/225/FPGA-DS-02056-3-4...
No dobře, tak všechny nemají. Líbí se mě třeba LCMXO2-1200HC-4SG32C, je to v QFN32, máš tam 1 PLL, 1200 LUTů a LVDS páry to má mít taky.
22.04.2020 (10:57:17)
VroutekB:
Tož co ten malej Lattice, líbí se? **02
22.04.2020 (14:27:08)
8-bit obalka (web) :
Jj, super. Ještě čím to programuješ?
26.04.2020 (12:19:24)
VroutekB:
Na Altery mám USB Blaster čínskej. Funguje zcela bezchybně, narozdíl od čínských kopií STLinku, který odchází křivým pohledem **02
Jinak, zajmavá věcička je tohle:
https://www.aliexpress.com/item/32956825881.html
a pak tohle:
https://www.aliexpress.com/item/4000790866984.html
Zvažuju, že ty Lattice brouky začnu používat (poměr ceny výkonu a pouzdra naprosto geniální), takže si tu větši univerzální krabičku asi pořídím.


Přezdívka:*
Heslo:*

███   ███   ███   
  █   █     █ █   
███   ███   ███   
  █     █     █   
███   ███   ███   
Opiš:*

Zde můžete smazat vlastní vlákno nebo kteroukoliv odpověď v něm. Můžete smazat vlastní odpověď v cizím vlákně, pokud na ni ještě nikdo jiný nereagoval. Mazat cizí vlákna a odpovědi v nich mohou pouze admini. Smazání příspěvku je nevratná operace! Smazáním vzkazu se smažou i odpovědi na něj.
Seznam uživatelů
Zpět na knihu