Egy számítógép mennyi szenzor jelét tudja kezelni?

Akármennyit, egyszerre úgyis csak annyit tud feldolgozni, ahány magos (szálas) a proci.

Azt találd ki először, hogy milyen paramétereknek kell megfelelni és ez alapján milyen hálózati rétegekből akarod felépíteni az átvitelt. Elég jó ipari megoldások léteznek.

Elméletileg nincs felső korlátja, csak bírja kezelni az adatfolyamot. Amúgy konkrét műszaki paraméterek nélkül nem lehet megválaszolni a kérdést.

Például egy "néhány" megapixeles kamera 3-szor "néhány" szenzort jelent, melyekről egyenként 200 bit-nyi adat van begyűjtve másodpercenként. Ma ezt már egy mezei PC valós időben fel tudja dolgozni adattömörítő programmal!

Ha nagyon erőltetjük a felső korlátot, akkor mondjuk az analóg jelek digitalizálása vagy a port sebessége ad egy korlátot. De akkor még ott van az algoritmus és maga a progi, hogy milyen tempóval tudja feldolgozni. Nem mindegy, az aritmetikai műveleteket másodpercenként 10-szer vagy 100 000-szer akarod elvégezni, és hogy ez mennyire van szinkronban a csatorna kapacitásával.

Mi a pontos cél? Pontosan definiáld magát a feladatot, utána jöhet a tervezés, megvalósítás.

5: pozíció szenzorból megfelelő célhardverrel néhány ezer darabot fel tudunk így dolgozni, úgy, hogy az adatokat át tudjuk adni a vezérlőnek, amelyik kiszámítja a szerszám pályát. Még szervó hajtás esetén is bőven van idő feldolgozni ennyi szenzor jelét. Persze megfelelő célhardver és illesztett szoftver kérdése.

Ha ez pl. egy CNC megmunkáló központ, és a kérdés, hogy hova került pontosan a munkadarab, és az alapján korrigálni a szerszám pályákat akkor egyre gyakoribb, hogy a megmunkálás előtt lézerrel leszkennelik, elkészül a tényleges munkadarab tényleges 3D térmodellje, és az alapján korrigálják a szerszám pályát (ez is pár mp. alatt megvan, addig el se indul a szerszám, ezt egyedi és kisszériás gyártásnál használjk, nagy szériánál ütköztetik a munkadarabot és az ad pontos pozíciót).

A fentieken kívül segítséget adhat a bitráta, 64 biten sokkal hatékonyabban tudsz kezelni egyidejűleg ötven szenzort, mint nyolc biten, főleg, ha nem egyidejűek a lekérdezések, de még úgy is, ugyanis az eleve elkülöníti a műveleteket és hihetetlenül megnő a variációs lehetőséged.

A processzor sebessége többnyire megfelelő, inkább az adatbuszok azok, amelyek korlátozhatnak, de megfelelő szelektálással például a grafikus kijelző numerikus felé tendáló használatával, vagy a cash memóriákra támaszkodva ezeket a korlátokat lehet csökkenteni, lévén a számítások folyamatát komplexé, vagy definíció szintűvé téve csak a végeredmény kijelzésére vagy felhasználására törekedve, továbbá a sebesebb háttértárolók alkalmazására is lehet támaszkodni, illetve nagyobb adatcsomagot feltölteni a memóriába, mivel ennyi feldolgozandó adathalmaz esetén ez szokott lenni a kritikus pont.

Nemegyszer kell ilyenkor virtuális memóriára támaszkodni, ami mindenképpen komoly lassítást okoz, de elegendő memória megoldhatja a problémát minden ilyen esetben illetve az objektumorientált programozási módszerek, feltéve, hogy az kellően letesztelt és hibamentes folyamatokat vezérel.

A viszonylag nagyszámú input adat kezelése más programozási módszereket kíván, de ez nagymértékben függ az alkalmazott környezettől, aelyet érdemes a feladatnak megfelelően eleve megválasztani és teljesen más lehetőségekre tudsz támaszkodni.

8: Nem biztos, hogy kell ennyire eszetlen sebesség. És pont ezt írtam, hogy sokan a "valós idejű feldolgozást" és a "nagyon gyors" feldolgozást keverik (itt fontos, hogy itt valami gépről van szó, és az ipari automatikák esetén mást értünk valós idejű feldolgozáson, mint a "programozók"). Itt ilyen automatikáknál nem kell a "nagyon gyors" csak azt kell tudni (és ettől lesz valós idejű), hogy mik azok az események amik egyszerre történnek és mik azok amik nem. Pl. nem egyszer már az érzékelőben rákerül az időbélyeg az eseményre, és azzal együtt kerül továbbításra. És néha egészen meglepően kis teljesítményű gépekkel (akár 8 biten is) több száz érzékelő jelét fel lehet dolgozni így. Itt nem arról van szó, hogy 10 GSPS sebességet érjünk el, hanem arról, hogy lehessen tudni, hogy mi az ami egyidőben jelen volt a rendszerben, és alapvetően msec-es esetleg usec-es időbélyegek elegendőek.

Pl. egy nem nagyon gyors (nyilván vannak gyorsabbak is) mozgásvezérlés esetén pl. egy 4mm-es menetemelkedésű vonóorsót /ez at jelenti, ha egyszer megfordul a vonó orsó a szerszám 4mm-t mozdul/ egy léptető motor hajt, és 2000mm/perc sebességet kell elérni /nyilván vannak ennél gyorsabb gépek, de ez már egy egészen baráti sebesség/, a léptető motor (és vezérlője) 3200 (mikro)lépés/fordulat az amire képes. 2000mm/perc=>33mm/sec egy fordulat alatt 4mm-et mozog a szerszám, ez azt jelenti, hogy kb. 8 fordulat/sec az amit el kell érni. Egy fordulathoz kell 3200 db. impulzus ez azt jelenti, hogy az impulzus frekvencia 25kHz körül lesz. Tehát az egész cuccosnak egy másodperc alatt 25 000x kell lefutnia. Azért ez nem egy irtózatosan nagy sebesség amit el kell érni. És ez egy teljesen gyakorlati példa. Ez idő alatt vidáman fel lehet dolgozni több ezer érzékelő jelét, kiszámolni, hogy mit kell tenni (főleg ha nem kell túl sok mindent csinálni, de ha meg igen, beteszünk valami DSP chipet, ami elvégzi a számolást, és a proci tehermentesítve van).