Dik. byl sem se ženou na vodní dýmce a teprve teď sem přišel domu.
M
Linuxcnc vs SSERIAL
Díky za tohle vlákno, hodně pomohlo.
Už u toho pár dní sedím, kouří se mi z hlavy ale podařilo se mi rozblikat ledku
Narazil jsem na nějaké nejasnosti v chování LinuxCNC když poslouchám mou 7i73:
1, moje verze LinuxCNC ( 2.9.8 ) při startu režimu (v discovery po 0xBB) čte nejdříve PTOC parametry, což by mělo být ve výsledku jedno ale je to k zamyšlení a způsobuje to možná následující jevy:
2, u GTOC když čte parametry 0xB0 tak se zasekne, vrátí se a začne číst sadu parametru (řádek) znovu (nedočtené řádky jsem označil červeně). Kromě delšího času čtení to ale asi ničemu nevadí
3, u některých sad parametrů nečte string s popisem a hned skočí do další sady parametru (označeno žlutě). Chybí mi tak Output, Input, ENC, enc a NVBaudRate. Kromě NVBaudRate mi ale v Halshow nic nechybí. Možná to je tím že LinuxCNC již tyto parametry načetl v PTOC (parametry v PTOC mají stejnou ADDRESS OF PARM) a tak si název přenese z PTOC?
Zkoušel jsem různé HW a SW mody, LinuxCNC 2.9.8 na mašině vedle, 2.9.2 na jiné mašině ale nikdy jsem v Halshow NVBaudRate neviděl. Dokonce i 7i84 se projevuje stejně.
Né že bych NVBaudRate u 7i73 postrádal ale ze stránky správné integrace SSERIAL do STM32 musím znát co vše se děje a proč.
Vím že už je to spoustu let zpět, ale nevzpomeneš si jakou jsi používal verzi LinuxCNC?
Pokud se mi vše podaří oživit tak zde hodím zase nějaké své poznatky na které jsem narazil
Už u toho pár dní sedím, kouří se mi z hlavy ale podařilo se mi rozblikat ledku
Narazil jsem na nějaké nejasnosti v chování LinuxCNC když poslouchám mou 7i73:
1, moje verze LinuxCNC ( 2.9.8 ) při startu režimu (v discovery po 0xBB) čte nejdříve PTOC parametry, což by mělo být ve výsledku jedno ale je to k zamyšlení a způsobuje to možná následující jevy:
2, u GTOC když čte parametry 0xB0 tak se zasekne, vrátí se a začne číst sadu parametru (řádek) znovu (nedočtené řádky jsem označil červeně). Kromě delšího času čtení to ale asi ničemu nevadí
3, u některých sad parametrů nečte string s popisem a hned skočí do další sady parametru (označeno žlutě). Chybí mi tak Output, Input, ENC, enc a NVBaudRate. Kromě NVBaudRate mi ale v Halshow nic nechybí. Možná to je tím že LinuxCNC již tyto parametry načetl v PTOC (parametry v PTOC mají stejnou ADDRESS OF PARM) a tak si název přenese z PTOC?
Zkoušel jsem různé HW a SW mody, LinuxCNC 2.9.8 na mašině vedle, 2.9.2 na jiné mašině ale nikdy jsem v Halshow NVBaudRate neviděl. Dokonce i 7i84 se projevuje stejně.
Né že bych NVBaudRate u 7i73 postrádal ale ze stránky správné integrace SSERIAL do STM32 musím znát co vše se děje a proč.
Vím že už je to spoustu let zpět, ale nevzpomeneš si jakou jsi používal verzi LinuxCNC?
Pokud se mi vše podaří oživit tak zde hodím zase nějaké své poznatky na které jsem narazil
- Přílohy
-
- Parameter_7i73_2.9.8_Meki.pdf
- (293.06 KiB) Staženo 7 x
Ahoj,
tak prvně gratulace k úspěchu, ikdyž ještě kousek do cíle chybí.
hrál sem si s tím v roce 2017 a většinou jsem fungoval na oficialni verzi a vedle toho nejnovejsi kompilovanou dev verzi, takže tipuju neco jako 2.7.8 a vedlo toho 2.8.x ale fakt netuším. Jestli si matně vzpominam, tak neco v jedne verzi chodilo a v druhe ne, ale to byla dřevní doba a sserial v plenkach. predpokladam, ze dneska uz to bude chodit na vsem. vzpominam si, ze se treba zvysil limit z96 bitu na 196b nebo tak něco.
Bohužel už jsem se k tomu moc nedostal, řešil jsem jiné hádanky.
M
tak prvně gratulace k úspěchu, ikdyž ještě kousek do cíle chybí.
hrál sem si s tím v roce 2017 a většinou jsem fungoval na oficialni verzi a vedle toho nejnovejsi kompilovanou dev verzi, takže tipuju neco jako 2.7.8 a vedlo toho 2.8.x ale fakt netuším. Jestli si matně vzpominam, tak neco v jedne verzi chodilo a v druhe ne, ale to byla dřevní doba a sserial v plenkach. predpokladam, ze dneska uz to bude chodit na vsem. vzpominam si, ze se treba zvysil limit z96 bitu na 196b nebo tak něco.
Bohužel už jsem se k tomu moc nedostal, řešil jsem jiné hádanky.
M
Zajímavé, o tom jsem nevěděl, dočetl jsem se jen že jsou na straně LinuxCNC 3 registry pro data po 32bit.
Řešil jsi nějak příchozí crc? v kódu jsem našel jen výpočet pro Transmit.
Zítra se asi zase napíchnu na 7i73 a budu zkoumat jak vlastně funguje rx a tx většího balíčku dat než kolik je nastaveno počet rx a tx byte pro jeden přenos. Nejdříve jsem myslel že budou chodit data a příkazy co se má s daty dít, tak je to zakreslené myslím i v návodu, a při zaplnění rx nebo tx byte se data rozloží do více přenosů. Teď jsem ale zjistil že po lince běhají jen holé data v pořadí vedle sebe v jakém se při discovery deklarovaly. Co mě ale zarazilo - když jsem ze zvědavosti zkusil poslat z LinuxCNC víc byte než jsem nastavil příkazem 0xBB, nenastalo automaticky přepínání a rozložení do více přenosů jak jsem si myslel ale všechny data nad se usekly a zahodily.
Buď mám něco špatně nastavené, nebo něco nastavené nemám a nebo hold musím mít tak široký přenos aby se vešly všechny data - ale vím že 7i73 ty data točí ve více přenosech, i v manuálu je něco popsané, budu rád za jakékoliv nakopnutí
Řešil jsi nějak příchozí crc? v kódu jsem našel jen výpočet pro Transmit.
Zítra se asi zase napíchnu na 7i73 a budu zkoumat jak vlastně funguje rx a tx většího balíčku dat než kolik je nastaveno počet rx a tx byte pro jeden přenos. Nejdříve jsem myslel že budou chodit data a příkazy co se má s daty dít, tak je to zakreslené myslím i v návodu, a při zaplnění rx nebo tx byte se data rozloží do více přenosů. Teď jsem ale zjistil že po lince běhají jen holé data v pořadí vedle sebe v jakém se při discovery deklarovaly. Co mě ale zarazilo - když jsem ze zvědavosti zkusil poslat z LinuxCNC víc byte než jsem nastavil příkazem 0xBB, nenastalo automaticky přepínání a rozložení do více přenosů jak jsem si myslel ale všechny data nad se usekly a zahodily.
Buď mám něco špatně nastavené, nebo něco nastavené nemám a nebo hold musím mít tak široký přenos aby se vešly všechny data - ale vím že 7i73 ty data točí ve více přenosech, i v manuálu je něco popsané, budu rád za jakékoliv nakopnutí
Nemáš nějaký lehčí otázky. já si nepamatuju nic.
Dokonce se mi stalo, že sem něco řešil, našel článek kterýmu sem pěkně rozumněl a nakonci sem zjistil, že sem ho psal já před x lety a neměl sem ani páru že sem se danému tématu v minulosti věnoval.
Ale myslím že CRC na příjmu tvoji desticky není úplně na testování/rozběhání potřeba hlídat. jiná otázka je při vysílání, tam když ti nebude sedět CRC tak to protistrana odmitne. Ve finále bych ale hlidani CRC použil at neprijmes nejakou blbost. logika je stejna jako pro vysílání.
https://www.forum.linuxcnc.org/27-drive ... ons#219072 tady je zminka o tom rozsireni na 224bitu.
ted sem letmo kouknul sem
https://github.com/fupe/sserial-template/ tam nejaky crc kontroly jsou v obou smerech.
Martin
já si nepamatuju nic. Dokonce se mi stalo, že sem něco řešil, našel článek kterýmu sem pěkně rozumněl a nakonci sem zjistil, že sem ho psal já před x lety a neměl sem ani páru že sem se danému tématu v minulosti věnoval.
Ale myslím že CRC na příjmu tvoji desticky není úplně na testování/rozběhání potřeba hlídat. jiná otázka je při vysílání, tam když ti nebude sedět CRC tak to protistrana odmitne. Ve finále bych ale hlidani CRC použil at neprijmes nejakou blbost. logika je stejna jako pro vysílání.
https://www.forum.linuxcnc.org/27-drive ... ons#219072 tady je zminka o tom rozsireni na 224bitu.
ted sem letmo kouknul sem
https://github.com/fupe/sserial-template/ tam nejaky crc kontroly jsou v obou smerech.
Martin
Díky za odkaz na github, tuto verzi jsem přehlídl. To je teda pořádný upgrade oproti předchozím verzím zde v tomto vlákně. Krásný kus práce, přehledné i popsané.
Docela láká vzít Ctrl+C Ctrl+V a slíznout jen smetanu ze tvých xx hodin práce , ale chtěl bych se naučit STM32 a prokousat se tím. Stavím teda osekanější verzi, jen jeden hw a sw mod (stavím to pro konkrétní aplikaci, univerzálnost neplánuju). Koukám že v té github verzi do LinuxCNC v discovery taky servíruješ virtuální adresy PTOC a GTOC, vydal jsem se taky touto cestou. Tx i Rx crc počítám a špatné data mám zatím nastavené zahazovat, později možná napojím na CRCerror aby měl LinuxCNC echo, v tvé předchozí verzi jsem neviděl že by jsi příchozí crc počítal tak mě napadlo se zeptat jestli jsi to neodpojil kvůli nějaké nestabilitě nebo tak.
To rozšíření na 224bit jsem musel hned testnout na LinuxCNC 2.9.8 a zdá se že to není tak žhavé. nad 15tx bajtu neseděl z LinuxCNC crc součet ale do 15 se to tvářilo funkčně. Když jsem ale chtěl odesílat data tak se to stejně ořezalo na 12bajt. Ještě je ale ve hře jeden faktor- protože příkazy do SmartSerial neposílá přímo LinuxCNC ale FPGA a je možné že (konkrétně v mé 5i25) nemám nejaktuálnější .BIN file. Měla by to mít na starosti tuším tato komponenta: https://github.com/LinuxCNC/hostmot2-fi ... serial.vhd
Docela mě láká to zjistit, nejprve ale oživím to stm32.
Na můj panel mi vychází že bych potřeboval posílat 390bit do STM32 (jen 264bit sežerou 7seg displeje) a 129bit do LinuxCNC, pokud ty data nerozložím do více přenosů tak by mě ani 224bit nespasilo. Přehlídl jsem ale jednu vychytávku DATA_TYPE 0x06 = STREAM takže by to mělo jít rozložit do více přenosů. Pokud to bude fungovat tak jak si myslím, tak by odpadl ten limit s šířkou jednoho přenosu 96bit.
STM32 které používám má 4uarty takže by teoreticky šlo nastavit aby se choval jako 4virtuální Smartserial karty, to je ale jen takové záložní řešení.
Jinak po načtení PTOC a GTOC (to už zde fupe popsal) nastane další část - načtení hodnot pro konkrétní parametr (např. NVWatchDogTimeout atd.). LinuxCNC se dotazuje přes příkazy 0x4x 0xyy 0xyy . Kde 0xyy 0xyy je ADDRESS OF PARM kterou se LinuxCNC dozvěděl z ADDRESS OF PARM z PTOC a GTOC předešlé discovery fázi.
- Příkaz 0x4C je specifický tím, že Slave (7i73 v mém případě) odpovídá 1byte + CRC a LinuxCNC data skládá tak jako když načítal PTOC a GTOC tabulku jen v tomto případě už zná délku z DATA SIZE IN BITS takže nečeká na 0x00. Tzn pro větší data než DATA SIZE IN BITS = 08 se LinuxCNC dotazuje opakovaně na ADDRESS OF PARM, ADDRESS OF PARM + 1 atd. Je na to třeba myslet a nechat mu dostatečné místo aby se ADDRESS OF PARM dalšího parametru PTOC nepřekrylo s předchozím.
- Příkazy 0x44, 0x45, 0x46, 0x47 už jsou chytřejší a slave na ně odpovídá 0x44 - 1byte, 45 - 2byte, 46 - 4byte, 47 - 8byte. Po a před těmito příkazy se ještě vyskytují 0xEC 0x00 a 0xEC 0x01, netuší co znamenají, v dokumentaci 0xEC není popsaný, ale vidím že fupe to rozluštil
Nechápu proč se volatile čtou tak podivně 0x4C po 1 byte když existuje daleko chytřejší přenos 0x44-7 (třeba to nějak souvisí s staršími čipy, rozdílným adresováním různých pamětí, netuším)
Až se LinuxCNC dozví všechny parametry přes příkaz 0x4x , začne druhá fáze - posílání parametrů do slave příkazem 0x6x yy yy zz ... . x je zase stejné jako minule - 0x64 - 1byte, 65 - 2byte, 66 - 4byte, 67 - 8byte, y je ADDRESS OF PARM také jako minule, a z je hodnota (o délce podle x). Posílají se pouze parametry s DATA DIRECTION 0x40 a 0x80 (vstupně/výstupní a výstupní) a z nich pouze parametry které mají v LinuxCNC jinou hodnotu než v Slave
Jakmile se vše dokončí, ukončí se discovery, nastane normální komunikace 0xBD a LinuxCNC už se k žádnému parametru nevrací. Pokud se jakýkoliv parametr který chceme dostat do slave změní, musí nastat znovu discovery = restart LinuxCNC nebo restart komunikace příkazem:
halcmd setp hm2_....sserial.port.0.run 0
halcmd setp hm2_....sserial.port.0.run 1
Celý proces discovery u 7i73 trvá okolo 0,5s u jiných karet i rychleji. Discovery je hotové dřív než se rozběhne GUI
Snad mě někdo opraví/upřesní pokud jsem napsal něco špatně
Docela láká vzít Ctrl+C Ctrl+V a slíznout jen smetanu ze tvých xx hodin práce
, ale chtěl bych se naučit STM32 a prokousat se tím. Stavím teda osekanější verzi, jen jeden hw a sw mod (stavím to pro konkrétní aplikaci, univerzálnost neplánuju). Koukám že v té github verzi do LinuxCNC v discovery taky servíruješ virtuální adresy PTOC a GTOC, vydal jsem se taky touto cestou. Tx i Rx crc počítám a špatné data mám zatím nastavené zahazovat, později možná napojím na CRCerror aby měl LinuxCNC echo, v tvé předchozí verzi jsem neviděl že by jsi příchozí crc počítal tak mě napadlo se zeptat jestli jsi to neodpojil kvůli nějaké nestabilitě nebo tak.To rozšíření na 224bit jsem musel hned testnout na LinuxCNC 2.9.8 a zdá se že to není tak žhavé. nad 15tx bajtu neseděl z LinuxCNC crc součet ale do 15 se to tvářilo funkčně. Když jsem ale chtěl odesílat data tak se to stejně ořezalo na 12bajt. Ještě je ale ve hře jeden faktor- protože příkazy do SmartSerial neposílá přímo LinuxCNC ale FPGA a je možné že (konkrétně v mé 5i25) nemám nejaktuálnější .BIN file. Měla by to mít na starosti tuším tato komponenta: https://github.com/LinuxCNC/hostmot2-fi ... serial.vhd
Docela mě láká to zjistit, nejprve ale oživím to stm32.
Na můj panel mi vychází že bych potřeboval posílat 390bit do STM32 (jen 264bit sežerou 7seg displeje) a 129bit do LinuxCNC, pokud ty data nerozložím do více přenosů tak by mě ani 224bit nespasilo. Přehlídl jsem ale jednu vychytávku DATA_TYPE 0x06 = STREAM takže by to mělo jít rozložit do více přenosů. Pokud to bude fungovat tak jak si myslím, tak by odpadl ten limit s šířkou jednoho přenosu 96bit.
STM32 které používám má 4uarty takže by teoreticky šlo nastavit aby se choval jako 4virtuální Smartserial karty, to je ale jen takové záložní řešení.
Jinak po načtení PTOC a GTOC (to už zde fupe popsal) nastane další část - načtení hodnot pro konkrétní parametr (např. NVWatchDogTimeout atd.). LinuxCNC se dotazuje přes příkazy 0x4x 0xyy 0xyy . Kde 0xyy 0xyy je ADDRESS OF PARM kterou se LinuxCNC dozvěděl z ADDRESS OF PARM z PTOC a GTOC předešlé discovery fázi.
- Příkaz 0x4C je specifický tím, že Slave (7i73 v mém případě) odpovídá 1byte + CRC a LinuxCNC data skládá tak jako když načítal PTOC a GTOC tabulku jen v tomto případě už zná délku z DATA SIZE IN BITS takže nečeká na 0x00. Tzn pro větší data než DATA SIZE IN BITS = 08 se LinuxCNC dotazuje opakovaně na ADDRESS OF PARM, ADDRESS OF PARM + 1 atd. Je na to třeba myslet a nechat mu dostatečné místo aby se ADDRESS OF PARM dalšího parametru PTOC nepřekrylo s předchozím.
- Příkazy 0x44, 0x45, 0x46, 0x47 už jsou chytřejší a slave na ně odpovídá 0x44 - 1byte, 45 - 2byte, 46 - 4byte, 47 - 8byte. Po a před těmito příkazy se ještě vyskytují 0xEC 0x00 a 0xEC 0x01, netuší co znamenají, v dokumentaci 0xEC není popsaný, ale vidím že fupe to rozluštil
Jestli to správně chápu tak (podle dokumentace mají příkazy NV (např. NVWatchDogTimeout) dvojníka v ramce (WatchDogTimeout) o stejné adrese) a tyto příkazy po příchodu z LinuxCNC čekají někde v proměnné v slave ale až po 0xEC se rozhodne do které paměti se zapíšou? RAM (0x00) / EEPROM (0x01)?LBP_COMMAND_LOCAL_WRITE_NVMEM_FLAG = 0xEC, // 0x01 nvacces 0x00normal acces
Nechápu proč se volatile čtou tak podivně 0x4C po 1 byte když existuje daleko chytřejší přenos 0x44-7 (třeba to nějak souvisí s staršími čipy, rozdílným adresováním různých pamětí, netuším)
Až se LinuxCNC dozví všechny parametry přes příkaz 0x4x , začne druhá fáze - posílání parametrů do slave příkazem 0x6x yy yy zz ... . x je zase stejné jako minule - 0x64 - 1byte, 65 - 2byte, 66 - 4byte, 67 - 8byte, y je ADDRESS OF PARM také jako minule, a z je hodnota (o délce podle x). Posílají se pouze parametry s DATA DIRECTION 0x40 a 0x80 (vstupně/výstupní a výstupní) a z nich pouze parametry které mají v LinuxCNC jinou hodnotu než v Slave
Jakmile se vše dokončí, ukončí se discovery, nastane normální komunikace 0xBD a LinuxCNC už se k žádnému parametru nevrací. Pokud se jakýkoliv parametr který chceme dostat do slave změní, musí nastat znovu discovery = restart LinuxCNC nebo restart komunikace příkazem:
halcmd setp hm2_....sserial.port.0.run 0
halcmd setp hm2_....sserial.port.0.run 1
Celý proces discovery u 7i73 trvá okolo 0,5s u jiných karet i rychleji. Discovery je hotové dřív než se rozběhne GUI
Snad mě někdo opraví/upřesní pokud jsem napsal něco špatně
