CNC Fórum

zz912 píše: ↑5. 1. 2023, 7:03 Jsem ženatý, mám hypotéku, nedostatek času. Tudíž se svítícím displejům vyhnu. Mám svých starostí dost, než abych promr(h)ával čas s nějakýma dalšíma babama. Doma mám 2ks bab.

Zdraví, peněz a bab není nikdy dost.

zz912 píše: ↑5. 1. 2023, 7:03 Zatím pracuji s vývojářem LinuxuCNC Chrisem Morley na přidání karty 7i96 s firmwarem pro 7i74 do PNCconfigu. Pro ty z Vás, kdo PNCconf nepoužívají to nebude mít žádný přínos. Pro LCNC začátečníky si myslím, že to bude dobrá berlička pro začátek. Jsem první, kdo se pokusil do PNCconfigu přidat konfiguraci s víc jak 6-ti SmartSerial. S tímto Chris nepočítal a teď to upravuje, aby to šlo. Abych někoho z vývojářů navnadil pro opravu PNCconf, tak jsem slíbil, že napíšu a otestuji i konfiguraci 7i96S+7i74 pro PNCconf. Když už jsem to slíbil, tak to budu muset splnit. Zatím čekám na Pipíka až mi pošle 5ks 7i84 na hraní.

Mezitím bojujem s kamarádem s převodníkem USB-RS232 pro ladění stepper-online serv. Převodník, který mi s Arduinem spolehlivě funguje, se s tím jejich programem nekamarádí. Už jsme objednali originál, takže uvidíme.

Koncepčně bych chtěl stroj držet v koncepci 7i96(S) + 7i74 + dostatečné množství 7i84.
Když jsem zjistil, co vše umí 7i84 https://zz912.webnode.cz/mesa-7i84/ , tak mě přešlo řešení jakýchkoliv vlastních elektro - hardwarových komponent. jsem rád, že jsem si prošel obdobím, kdy jsem se o vlastní elektro-hardwarové komponenty pokoušel, ale nedostal jsem se na úroveň, abych byl schopný u těchto komponent ručit za kvalitu a spolehlivost.

Mex píše: ↑5. 1. 2023, 5:40 Pokud vezmeš jako trigger okamžik změny prvního z bitů, tak se asi celkem snadno dá zařadit nějaké malé zpoždění, a teprve pak vrátit přečtený stav.
Možná by to šlo dokonce poskládat i z hotových komponent

Už jsem se o to pokoušel. Poskládal jsem to z hotových komponent. Přišel jsem na to, že to řešilo, jen příjezd na pozici. Je potřeba řešit i podmínku pro odjezd z místa čtení.
Pokud nějaký bit zmizí, už nic nečti po nějakou dobu. A to už se mi ze standardních hall komponent psát nechce. Navíc jsem na osciloscopu přišel na to, že některé bity se v řádu 1ms zachvějí.

Nejvíce by se mi líbilo, přidat parametry zpoždění čtení bitů (pro odjezd a příjezd) přímo do komponenty.
https://github.com/LinuxCNC/linuxcnc/bl ... ousel.comp
Chtěl jsem se zeptat zkušených programátorů, zda mohu zdrojový kód této komponenty považovat za vzor pro to "jak to dělat", nebo pro další psaní hal komponent se inspirovat někde jinde?

Mex píše: ↑5. 1. 2023, 5:40 Svítící displeje jsou sexy. To by se pak na Tebe baby jenom lepily, když umíš udělat tak pěkný stroj.

Jsem ženatý, mám hypotéku, nedostatek času. Tudíž se svítícím displejům vyhnu. Mám svých starostí dost, než abych promr(h)ával čas s nějakýma dalšíma babama. Doma mám 2ks bab.

Ahoj kup si u papoucha jejich prevodnik, je to jediny ktery mi funguje naprosto se vším, jo cena neni lidova

Tento?
https://papouch.com/sb232-prevodnik-usb-na-rs232-p2048/

zz912 píše: ↑5. 1. 2023, 8:12 Tento?
https://papouch.com/sb232-prevodnik-usb-na-rs232-p2048/

to je on, mám ho asi tři roky a paráda a hlavně konfiguruje se jako com1, takže staré softy, co neumí třeba com19, nemají problem

Tohle je to správné řešení. Použil jsem jich asi 10 kousků a vždy bez problémů. Když si vezmu těch hodin měření a ladění, tak je ta cenovka naprosto v pohodě.

Pokud něco nefunguje (a mělo by fungovat), tak je jistě možné zkusit použít nějaký jiný výrobek (podle mě dámské, mlaďošské nebo černošské řešení).
Nebo je možné (a podle mě mnohem lepší) se zamyslet proč to nefunguje. A případně to opravit nebo upravit (podle mě řešení starého bílého muže).

Nepochopil jsem z toho popisu, co znamená "s Arduinem spolehlivě funguje, s tím jejich programem nekamarádí".
Arduino RS232 nemá. Pokud se k němu připojuje nějaký USB převodník, tak je to USB/serial na TTL úrovních.
A pak jde o to, co teda nefunguje. Jestli ten nějaký program neumí používat daný USB/RS232 převodník (tj. např. používá nějaké nestandardní volání služeb systému).

Nebo (a to asi spíš) nefunguje to RS232 s daným hardware.
Laciné převodníky na RS232 mají ošizené záporné úrovně. Podle normy mají být signály v mezích -3..-12V a 3..12V.
Ale levné převodníky vevnitř nemají nábojovou pumpu a používají signály na úrovních 0V a 5V.
S většinou přijímačů to funguje, ale občas s některým ne.
Takže není třeba kupovat nějaké Papouchy a jiné drahé převodníky, ale chce to koupit nějaký (třeba i čínský), který má nábojovou pumpu.

Mex píše: ↑5. 1. 2023, 12:16 Nebo je možné (a podle mě mnohem lepší) se zamyslet proč to nefunguje. A případně to opravit nebo upravit (podle mě řešení starého bílého muže).

Kdyby ten program byl v Linuxu a měl otevřený kód, tak bych se o to alespoň pokusil. Bohužel je to Windows záležitost.

Mex píše: ↑5. 1. 2023, 12:16 Nepochopil jsem z toho popisu, co znamená "s Arduinem spolehlivě funguje, s tím jejich programem nekamarádí".

S programem "Arduino IDE" ten převodník funguje.
S programem "Tuning Software: iSV-T_STEPPERONLINE" ten převodník nefunguje.

Programátoři "Tuning Software: iSV-T_STEPPERONLINE" se ani nezabývali tím, aby někde definovali počet bitů, paritu.

Mex píše: ↑5. 1. 2023, 12:16 Nebo (a to asi spíš) nefunguje to RS232 s daným hardware.
Laciné převodníky na RS232 mají ošizené záporné úrovně. Podle normy mají být signály v mezích -3..-12V a 3..12V.
Ale levné převodníky vevnitř nemají nábojovou pumpu a používají signály na úrovních 0V a 5V.
S většinou přijímačů to funguje, ale občas s některým ne.

Dík za rozšíření mých vědomostí.

Mex píše: ↑5. 1. 2023, 12:16
Ale levné převodníky vevnitř nemají nábojovou pumpu a používají signály na úrovních 0V a 5V.
S většinou přijímačů to funguje, ale občas s některým ne.
Takže není třeba kupovat nějaké Papouchy a jiné drahé převodníky, ale chce to koupit nějaký (třeba i čínský), který má nábojovou pumpu.

Takže si nekoupím drahého papoucha, o kterém víme že funguje, ale krabici různých z číny a budeme testovat, jestli zelený, růžový, modrý, žlutý převodník udělali správně

Tak tolik času na planetě fakt nemám, ale jestli cesta je cíl...

Aha. Takže ne s Arduinem (jako s HW), ale s Arduino IDE (tedy s vývojovým SW).
A co to teda hlásí nebo dělá, resp. nedělá?

Pak to může být jen problém driverů. A to žádný drahý převodník nevyřeší.
Standardní USB/serial chipy se dneska používají od FTDI, Prolificu, Silicon Labs a čínské WCH (ty jsou podle mě nejlepší, pokud to jde, tak jim dávám přednost).
Nějaký ten Papouch má v sobě určitě FTDI. Tyhle chipy jsou nejdražší, tak je "značkoví" výrobci rádi používají.

Pokud daný SW nenastavuje ve vlastní režii komunikační parametry, tak je třeba je nastavit na úrovni operačního systému.
To opět drahý převodník nevyřeší.
Ale vyřeší to člověk rukama.

Použili jsme dámské a mlaďošské řešení. Objednali jsme převodník od stepperonline a on fungoval. Bohužel mám málo životů, abych přišel u všech věcí jak fungují a uměl je opravit. Budu spokojenej, když se do konce života stihnu aspoň trochu naučit něco o LinuxuCNC.

Taková malá podělávka byla, že stepperonline používá pro své drivery řady T6 RJ45 konektor s 8-mi piny a tenhle kablík https://www.omc-stepperonline.com/1-5m- ... er-rs232-1 je 6-ti pinovej, takže jsme si z převodníku do driveru museli kablík vyrobit.

Momentálně se zabývám přemapováním funkce M6.

Na tomto stroji je vše řešeno mechanicky, takže zjednodušeně stačí:
1) Vyjet vřetenem úplně nahoru
2) zatočit revolverem do správné polohy
3) Sjet vřetenem do horní polohy obráběcího prostoru

V G-kódu by to mohlo vypadat takto:
M19 R90 Q10 (natoceni vretene)
G49 (vypnuti korekce nastroje)
G53 Z195 (vyjetí vřetene do horní pozice pro otáčení vřetene)
M62 P0 (nastaveni carousel.0.enable na TRUE => spuštění rotace revolveru)
M66 P0 L4 (čekání na carousel.0.active == FALSE => čekání na dotočení revolveru)
G53 Z0 (sjetí vřetene do pracovní pozice)
G43 (zapnuti korekce nastroje)

Ovšem tento G-kód je jen teoretickej a nefungoval by.
1) mám problém s tím, že softwarové limity pro osu Z mám MAX 0 a MIN -135
Ovšem abych zajel do pozice pro výměnu nástrojů, musím najet G53 Z195
2) nejsem obráběč a nevím zda je správně, že jsem použil příkazy G49 a G43.
Myslím si, že použití G49 je správné. Ale jak je to s G43? Má se ukončovat cyklus výměny nástroje G43? Neměl bych i kvůli G43 sjíždět níže, aby si nástroj cuknul? Kolik?

Dovolil bych si poreferovat o průběhu retrofitu.

Co se týče ATC, tak jsem upravil HAL componentu carousel, tak aby fungovala. Byl to takový maminkovský styl řešení problému. "Dokud ten oběd nesníš, nejdeš od stolu" V mém podání to bylo "Dokud nenajdeš správnou polohu, budeš hledat dál." Sice při hledání správné polohy, se to občas zastavilo někde jinde, ale ze strachu z naštvané maminky to hledalo dál. Dal jsem tuto úpravu do pull requestu na github LCNC, ale moje maminkovské řešení se jim nelíbilo. Ovšem na základě mého řešení přišli s řešením babičkovským "nejdřív se N krát ujistí co chce dítě jíst a nemají problém, že by dítě už nechtělo oběd dojíst". V praxi to znamená, že komponenta carousel byla doplněna o parametr debounce, který vyfiltruje zákmity nesmyslných čísel pozic. Tato úprav už je ve verzi 2.9. a funguje fakt pěkně.

Co se týče serv na osy, tak tady bych poděkoval, Pipikovi za pomoc při rozchození. Zklamala mě firma Stepperonline. U serv řady T6 má chybu v konfigurátoru (lze řešit přes ruční namačkání parametrů). Mizerná dokumentace. Komunikovat přes e-mail, nebo přes facebook nemají zájem. Pro hobby použití, jsou jejich ceny super, ale pro komerční projekty je asi používat nebudu. Dodavatel, který ani neumí odpovědět na mejly, není pro mě zajímavý. V tom jsou i někteří číňani dále.

Co se týče naladění DELTY driveru C2000 plus na synchronní vřetenový motor:
- chtěl bych poděkovat packovi, za pomoc při volbě resolveru. Původní resolver měl jiný transformační poměr budícího a výstupního napětí a ještě byl na jinou frekvenci než požadovala resolverová karta PG. Použili jsme resolver firmy ATAS a funguje to pěkně.
- dále jsme využili služeb Jirky Pavelky a nechali jsme si pohonnou část naladit od něj. Je super pracovat s někým, kdo je stejně LCNC naladěn. Nastavil nám rychlostní a polohový mód. Na jednom fyzickém vstupu je nastaveno, že když se na něj přivede logická 1, tak se vřeteno natočí pro ATC. Nastudování pohonařiny, by bylo nad moje časové možnosti
- co se týče firmy Profcom, tak můžu potvrdit, to co je profláklé. Jejich podpora je na Evropské úrovni, poradili, berou telefony a v případě problému pomohli.
- na co jsem se těšil, je rozchození driveru s LCNC přes Modbus RS485. No někdo mi nepřál, ale popral jsem se s tím. Po Jirkovým odjezdu:
1) pondělí odpoledne - nešlo se připojit s konfiguračním nástrojem DELTY ve Windows s driverem. Asi 30x jsme kontrolovali zapojení převodníku s konektorem RJ45. Už jsme byli nešťastní. Pak jsme zavolali Jirkovi a zjistili jsme, že na tom driveru jsou 2 vstupy RJ45 krásně viditelně a další 2 vstupy RJ45 trošku schované. Samozřejmně, že ty schované byli pro Modbus. Bohužel při zapojení kabelu do správných vstupů to nefungovalo dále. Při pátrání jsme přišli na to, že ty krásně viditelné RJ45 byla z rozšiřující karta CanOpen a asi zničila převodník USB/RS485 (cena 60Kč).
2) úterý odpoledne - dovezl jsem nový převodník a potvrdila se teorie se zničení toho původního převodníku. Začal jsem si hrát s konfigurátorem od Delty a pokusil jsem se komunikovat přes mb2hal s driverem a nedařilo se.
3) středa odpoledne - bojoval jsem s komunikací mb2hal s driverem. Vše jsem zase 30x prošel a nemohl najít chybu. pak jsem začal dekódovat hexadecimální zprávu, co šla z konfigurátoru Delta a porovnával jsem ji ze zprávou z mb2hal. Po odhalení a vyřešení chyb v decimal/hexagonal zápisu adresy jsem přišel na to, že konec zprávy je jiný. Po studiu Modbusu na netu, jsem přišel na to že konec zprávy je kontrolní součet. Zjistil jsem , že existuje kontrolní součet LRC a CRC. Když jsem zjistil, že to má souvislost s ASCII a s RTU, tak jsem to hned zkontroloval. No mb2hal umí jen RTU a driver byl v ASCII. Když jsem pak přepnul driver na RTU, tradá začalo to fungovat. Takový pocit blaha jsem už dlouho nezažil.
4) čtvrtek odpoledne - to už byla třešnička na dortu, nakonfiguroval jsem mb2hal, propojil potřebné HAL signály a už mi funguje M3,M4,M5,S . Spindle at speed - porovnávám hodnotu zadanou přes mb2hal z výstupem PG karty, která mi jde do encoderového vstupu Mesy.

Dále mě čekají rozchodit HAL signály pro závitování a pro polohování.

Stává se mi, že mi vyskakuje hláška, že není vyhovující latence.
Počítač jsem zadarmo dostal:
Optiplex 755
Než jsem se rozhodl počítač dát do PC, tak jsem dělal testy RAMek (24 hodin), Hard-disku s výsledkem 0 chyb. Pak jsem dělal latency test (12 hodin) bez zatížení do 50 000, pak s pořádným zátížením (24 hodin) CPU 100% s přeplněnýma RAMkama a vyšlo to do 140 000.

Ovšem vzpomněl jsem si, že jethornton měl "nějaké" testy ve svém konfigurátoru:
https://github.com/jethornton/mesact

Testy nevyšly, ale paradoxně z toho mám radost, protože nejsem v situaci kdy "diagnostika nehlásí žádnou závadu a auto nejede". V konfigurátoru je napsáno, že mám zvýšit Servo Thread Period. Toto se mi opravdu nechce, takže asi budu muset pořídit nový PC? Nebo v něm vyměnit například jen procesor?

Chtěl jsem se zeptat, jestli by byl někdo ochotný mi laicky vysvětlit, co tyto testy znamenají a jak fungují?

Dále jsem se chtěl zeptat, jestli se dá dělat něco udělat s tím že:
Current Speed: 2333 MHz
ale:
Max Speed: 5200 MHz
Nikdy jsem počítače nepřetaktovával, takže se v té problematice nevyznám. Četl jsem někde, že od nějaké doby, se procesory přetaktovávají sami. Šlo by PC říct ať jede neustále na plný výkon? A je to dobrý nápad?

Já ti něco vyhrabu ve skladu, pokud budeš potřebovat na pokusy

Podobný problém jsme měli taky. Problém byl v síťovce...

Lukas_2 píše: ↑27. 2. 2023, 6:04 Podobný problém jsme měli taky. Problém byl v síťovce...

Podobný problém v Machu?

Používám integrovanou síťovku co tam v to počítači byla. Zkusím.