Dalkove ovladani vrat

[Petr Labaj]

Pro LinuxCNC se používá Linux s RT rozšířením.
Nejlepší latence se dají dosáhnout se systémem RTAI, hůř to vychází s 
Preempt-TR nebo Xenomai.
Podle různého HW se dá dosáhnout latence (resp. Jitteru, což je zde 
mnohem podstatnější)
někde na úrovní od 5us výš (výjimečné kousky HW i trochu níž).

Jsou různé přístupy, jak se to řeší.
1 - Nejnižší je, že procesor přímo přes bit-bang řídí krokování motorů.
Levné, použitelné pro nižší rychlosti do rychlosti kroků tak kolem 20-25 
kHz.
Typicky LinuxCNC nebo na Windows Mach 3,4 bez interpolátorů.

2 - Použití interpolátoru na vysoké úrovni, který řídí pohyby sám. 
Nadřízený systém mu
dodává jen údaje o dráhách.
Nevýhoda je, že tady dost záleží na tom, jak dobře je implementovaný ten 
interpolátor.
Protože to bývá deska s nějakým ARMem, tak tam jsou přece jen možnosti 
trochu nižší
než na tom velkém mateřském systému.
Výhoda je, že to poběží na libovolně mizerném PC.
Typicky Windows s Mach 3,4 s nějakým SmoothStepper nebo nebo jiným. 
Nejlevnější
připojitelné po USB (uživatelé pak naštvaně píšou, že mají problémy), 
dražší po Ethernetu.
LinuxCNC takto nepracuje.

3 - Nechá se řízení stále na PC, ale použije se interpolátor pro 
generování nejnižší
úrovně, tj. pro vlastní generování kroků, čtení enkodérů atd.
PC pak s ním komunikuje a úkoluje ho typicky na frekvenci 1kHz. Říká se 
tomu servocyklus.
Typicky systémy Mesa na LinuxCNC. Připojitelné jako karta do PCI/PCIex, 
pro Ethernetu, po LPT.

4 - Použití inteligentních serv, které se pak obsluhují také v 
servocyklu, podobně jako v bodu 3.

PL

*******************

Dne 23.3.2024 v 13:40 Miroslav Mraz napsal(a):
> Řekl bych, že na multitasking systému celkem nezáleží jak na hardware 
> přistupujete, samotné latence systému vám do toho hodí vidle.
> Někde na netu má dr. Píša přednášku, kde na Linuxu řídí motor PID 
> regulátorem a aby se dostali pod cca 1 ms museli upravit plánovač. Na 
> normálním Linuxu jako je Ubuntu jsou běžné latence 10 ms.
> Asi se tam dá čarovat s prioritou tasku, nastavením plánovače, ale mám 
> takový dojem, že posílat příkazy do nějakého malého MCU, kde je dobře 
> napsaný firmware, bude mnohem jistější.
>
> Mrazík
>
> On 23. 03. 24 12:50, Petr Labaj wrote:
>> USB transport je v tomto případě (pro bit-banging na rychlostech CNC) 
>> kvůli latenci nepoužitelný.
>> Možná s nějakým superrychlým USB3 už by to šlo, ale tam zase nepojede 
>> FT245.
>>
>> Pro ms rychlosti (tedy někde na úrovní max. stovek Hz) pro nějaký 
>> programátor možná ano.
>> Ale chtělo by to, aby ten programátor fungoval přes služby systému, 
>> nikoli přes přímý zápis na porty.
>> A to takto téměř jistě fungovat nebude.
>>
>> Existuje projekt (myslím nějakého Němce), který LPT na úrovní HW 
>> zápisů emuluje. Není to
>> přes FT245, ale přes nějaký MCU s příslušným firmware.
>> Zřejmě odchytáváním zápisů na I/O adresy, což způsobí výjimku, kterou 
>> on obslouží zavoláním
>> systémové obsluhy.
>> Na pomalé věci by to pak fungovat mohlo.
>>
>> PL