Jak jsi prosím přišel k tomuto výpočtu?CZ_Pascal píše:.. pokud tech 16 bitů nepřetočíš celých během jedné servoperiody (tedy nepožaduješ rychlost vyšší než 32,7 metrů za sekundu), tak není problém aby Ovladač MESY (Tedy HostMot2) přetečení ošéfoval.
LinuxCNC už se dozví polohu jako FLOAT tak jak očekává a nic neřeší.
To, co píšeš by platilo, kdyby těch 16 bitů byla poziční informace v mikronech, kterou má motor za jeden servocyklus ujet.
Ale dřív tady zaznělo, že Mesa dostává od HALu rychlostní informaci, nikoli poziční. Platí to?
A u rychlostní to přece nezáleží na délce servocyklu. Navíc to snad bude závislé i na rozlišení motorů v počtech kroků na otáčku, na stoupání šroubu, narozlišené enkodéru atd., ne?
Ten přepočet na fyzické kroky snad dělá HAL, tedy procesor. Nebo to taky nechá na FPGA, aby to přepočítavalo, a informace se posílá v absolutních jednotách?
Tak pokud se to skutečně počítá na úrovni HALu, tak pak o nějaké omezení na kokrétní rychlosti nelze snad bez znalosti daného stroje mluvit (takže pak by i RaS mohl být uklidněn).
Já jsem chtěl využít ten hotový HostMot2, určený pro Mesu, protože jsem se nechtěl nořit do dalších vrstev na LinuxCNC. Tak proto se snažím zjistit, co běhá mezi PC a kartou Mesa za stávajícího stavu.
Nejasností mi ale moc neubývá, takže budu muset najít nějakou primární dokumentaci nebo pak použít tu nepracnější cestu, tj. louskat zdrojáky od HostMot2 (a tomu jsem se chtěl rozhodně vyhnout).
, protože to není tak triviální kus hardware a software jak si pořád myslíš. Už jenom enumerace co se kde má inicializovat a vygenerovat do HAL pinů na základě načteného Firmware a jeho nastavení je na pos...