A KEYENCE az LJ Developer sorozatot úgy pozicionálja, mint amellyel lerövidíthető az út a konfigurált 3D-s ellenőrzéstől a meghívható alkalmazáskódig. Az eredeti PLC ProTech-tervezet 2026 áprilisában készült; ez a 2026. augusztus 30-i változat a gyártó aktuális dokumentációja alapján tekinti át újra a terméket, és a kódgenerálás, valamint a gyártásra kész ellenőrzőállomás közötti mérnöki határvonalra összpontosít.

A szoftverrel a mérnök 3D-adatokon ellenőrzési régiókat és eszközöket határozhat meg, forráskódot generálhat, majd a mellékelt könyvtárat és forráskódot importálhatja egy alkalmazásba. Ez megszüntetheti a szabványos mérésekhez kapcsolódó ismétlődő integrációs munkák egy részét. Nem oldja meg azonban automatikusan a triggerelést, a munkadarabok követését, a kalibrálást, a selejtezés időzítését, a kivételkezelést, a felhasználói hozzáférést vagy a nyomonkövethetőséget. Ezek továbbra is a rendszertervezésért felelős szakemberek feladatai.

Az LJ Developer vizuálisan rendszerezi az ellenőrzés beállítását, mielőtt létrehozná az alkalmazás forráskódját.

Mit változtat a generált kódon alapuló munkafolyamat?

A hagyományos 3D-s látórendszer-integráció gyakran egyedi kódban egyesíti az érzékelő kommunikációját, a magasságtérképek kezelését, a geometriai számításokat, a megjelenítési logikát és az eredmények továbbítását. Még ha a gyártó szoftverfejlesztői készletet is biztosít, az integrátornak továbbra is jelentős időt kell fordítania arra, hogy az alacsony szintű funkciókból megismételhető ellenőrzési szekvenciát alakítson ki. Az LJ Developer e konfiguráció nagyobb részét grafikus környezetbe helyezi át.

A KEYENCE aktuális termékleírása szerint a munkafolyamat során az ellenőrzési eszközöket és a célterületeket 3D-s képeken kell beállítani, egy paranccsal forráskódot kell generálni, importálni kell a megfelelő könyvtárat és kódot, majd a mérési függvényt a felhasználó alkalmazásából kell meghívni. Ezt leginkább konfigurációvezérelt kódgenerálásként érdemes értelmezni, nem pedig univerzális, kódolásmentes gépi látórendszer-platformként.

A különbség a karbantarthatóság szempontjából fontos. A generált kódnak ugyanazon az ellenőrzési, verziókezelési, buildelési és kiadási folyamaton kell átmennie, mint a kézzel írt kódnak. A mérnököknek tudniuk kell, mely beállítások kerülnek be a kódba, melyek módosíthatók futás közben, és mit kell újragenerálni recept- vagy érzékelőcsere után. Ha a generálás felülírja a helyi módosításokat, a bővítményeket stabil interfész mögött, nem pedig a generált részekbe illesztve kell elkülöníteni.

Az ellenőrzési eszközök a gyakori 3D-s feladatokat fedik le

A gyártó a rendelkezésre álló funkciók között méret- és megjelenés-ellenőrzést, pozíciókorrekciót, zajeltávolítást, képkombinálást és 3D-s renderelést sorol fel. Ezek az építőelemek a rutinszerű, magasságon alapuló ellenőrzések jelentős részét lefedik: lépcsők vagy hézagok mérése, profilok vizsgálata, elmozdult munkadarabok helyének meghatározása, a nem kívánt pontok kiszűrése, adatok egyesítése, valamint az eredmény megjelenítése beállításhoz vagy diagnosztikához.

Ez az eszközkészlet ott értékes, ahol egy 2D-s kép nem tudja megkülönböztetni a magasságváltozást a szín- vagy fényváltozástól. Az elektronikai termékek, megmunkált alkatrészek, fröccsöntött elemek, ragasztási nyomvonalak és összeszerelt termékek mind tartalmazhatnak olyan jellemzőket, amelyeket könnyebb geometriaként értékelni. Az alkalmazhatóság továbbra is az érzékelő látómezejétől, magasságtartományától, ismételhetőségétől, a felület viselkedésétől, a sor sebességétől és a rögzítés stabilitásától függ.

A konfigurált mérési és megjelenés-ellenőrzési eszközök korrekcióval, szűréssel és 3D-s vizualizációval kombinálhatók.

Hol kezdődik továbbra is a mérnöki munka?

Adatgyűjtés és a munkadarabok követése

A gyártási rendszernek minden mérést a megfelelő fizikai munkadarabhoz kell rendelnie. Az alkalmazásnak determinisztikus triggert, a teljes profil vagy képkészlet beolvasásának megerősítését, valamint a sorokon és aszinkron feldolgozáson át fennmaradó azonosítót kell biztosítania. Ha a szállítószalag gyorsabban indexel, mint ahogy az ellenőrzés vagy a hálózat válaszolni képes, a pufferelést és a torlódáskezelés viselkedését már az üzembe helyezés előtt meg kell határozni.

A selejtezés időzítése külön vezérlési feladat. Egy hibás mérés több állomással a selejtezőmechanizmus előtt is bekövetkezhet. A PLC-nek a megfelelő munkadarabhoz kell rendelnie az eredményt, figyelembe kell vennie a hézagokat és az utómunkát, valamint biztonságos választ kell adnia hiányzó vagy későn érkező adatok esetén. Egy generált látórendszeri függvény visszaadhat egy eredményt, de nem tudja kikövetkeztetni a gyártósor anyagkövetési szerződését.

Kalibrálás és mérési bizonytalanság

Az eszközök konfigurálása nem szünteti meg a mérőrendszer kialakításának szükségességét. A mérnököknek dokumentálniuk kell a referencia-etalonokat, a kalibrálási időközöket, a rögzítés ismételhetőségét, a környezeti korlátokat és a tűrés által megengedett bizonytalanságot. A tiszta 3D-s renderelés nem bizonyítja, hogy a mérés alkalmas a feladatra. A mérőrendszer-vizsgálatoknak és próbadaraboknak le kell fedniük a gyártásban várható felületeket, pozíciókat és hibaméreteket.

A pozíciókorrekció csökkentheti a normál munkadarab-elhelyezésből eredő érzékenységet, a korrekció határait azonban korlátozni kell. A szélsőséges eltolódás szerelési problémára, nem megfelelő munkadarabra vagy kezelési hibára utalhat. Ha a szoftver minden képet normalizál, az elrejthet egy olyan folyamatproblémát, amelyet az üzemeltetésnek látnia kellene.

Receptek, hozzáférés és nyomonkövethetőség

Az ellenőrzési paraméterek gyártási receptek, ezért ennek megfelelően kell kezelni őket. Meg kell határozni, ki módosíthatja a küszöbértékeket, hogyan azonosítják a jóváhagyott verziókat, miként auditálják a változásokat, és mi történik, ha az alkalmazás és a generált kód nincs összhangban. Minden eredményhez elegendő körülményt kell tárolni a döntés utólagos rekonstruálásához, beleértve a recept verzióját, az érzékelő állapotát, a kalibrálási állapotot és a releváns mérési adatokat, nem csupán egy megfelelt vagy nem felelt meg bitet.

A szoftverkörnyezetnek is vannak telepítési korlátai. A 2026. augusztus 30-án áttekintett KEYENCE LJ-H1LP-modelloldal 64 bites Windows 10 vagy Windows 11 Pro rendszert ír elő, és Visual Studio 2017-es, C# 7.3-as vagy újabb könyvtári környezetet sorol fel. Az integrátoroknak az ipari PC-lemezkép szabványosítása vagy a fejlesztőeszközök frissítése előtt ellenőrizniük kell a licencelt modell pontos, aktuális követelményeit.

Gyakorlati cellaarchitektúra

A robusztus cella elkülöníti a felelősségi köröket. Az érzékelő és az LJ Developer által generált függvény gyűjti be és értékeli ki a 3D-adatokat. Az alkalmazás kezeli a recepteket, a képpuffereket, a diagnosztikát, a kezelői nézeteket és az eredményrekordokat. A PLC vezérli a gépszekvenciát, a munkadarab-azonosítást, az engedélyezési feltételeket és a selejtezés időzítését. A HMI olyan, végrehajtható állapotot jelenít meg, amely nem teszi lehetővé, hogy minden felhasználó szabályozatlan küszöbértékekhez férjen hozzá.

A mérőhardvert kiválasztó csapatok áttekinthetik az oldal ipari érzékelőkből álló gyűjteményét, míg a számítási és kezelői felületi lehetőségek a HMI és ipari számítástechnika kategóriában találhatók. A hardver kiválasztását reprezentatív munkadarabokkal, ciklusidővel, felületekkel és hálózati terheléssel végzett teljesítménytesztnek kell megelőznie.

A látórendszeri alkalmazás és a PLC közötti interfészt állapotfüggő kézfogásként kell meghatározni, nem egyetlen megfelelt bitként. Hasznos állapotok például a kész, triggerelt, foglalt, érvényes eredmény, eredményazonosító, hiba és a visszaállítás elfogadva. A sorszámok vagy munkadarab-azonosítók csökkentik annak esélyét, hogy egy késleltetett eredményt a következő termékre alkalmazzanak. Az időtúllépéseknek meg kell különböztetniük az adatgyűjtési hibát, a feldolgozási túlfutást, a kommunikáció megszakadását, valamint azt az esetet, amikor az alkalmazás fut, de még nem áll készen.

Miért fontos ez a 3D-s látásrendszerek bevezetése szempontjából?

A gépilátás-gyártók folyamatosan konfigurálható eszközökbe helyezik át a gyakori algoritmusokat, és magasabb szintű integrációs elemeket készítenek. Ez a tendencia csökkenti a programozási akadályt, és segíti az üzemeket abban, hogy az ellenőrzéseket több gyártósoron is megismételjék. Egyúttal megváltoztatja a ritka szaktudás jellegét: kevesebb időt kellhet a geometria megvalósítására fordítani, miközben nagyobb figyelem szükséges a validáláshoz, az adatkezeléshez, a változáskezeléshez, valamint az ellenőrzési eredmények és a gépmozgás közötti kölcsönhatáshoz.

Az integrátorok számára a legerősebb alkalmazási terület egy olyan szabványos ellenőrzési feladat, amelyhez továbbra is egyedi alkalmazási keretrendszer szükséges. Az LJ Developer felgyorsíthatja ezt a köztes réteget azzal, hogy a konfigurált eszközökből C#-kódot hoz létre. Kevésbé valószínű, hogy megszünteti a munkát ott, ahol a nehézséget az optikai hozzáférés, a kiszámíthatatlan felületek, a vegyes munkadarabokat kezelő logisztika, a nagy sebességű pufferelés vagy a szabályozási bizonyítékok jelentik.

Szerkesztői értékelés

A hasznos állítás szűkebb és hitelesebb annál, mint hogy „3D-s látás programozás nélkül”. A KEYENCE olyan munkafolyamatot hozott létre, amely csökkentheti a támogatott eszközöket használó alkalmazások ismétlődő fejlesztési feladatait. Az üzemek akkor profitálnak a legtöbbet, ha a generált kódot egy szabályozott ellenőrzési rendszer egyik validált komponenseként kezelik.

Üzembe helyezés előtt a csapatnak a legrosszabb esetet jelentő adatokkal kell igazolnia a ciklusidőt, minden hibautat végig kell tesztelnie, rögzítenie kell a jóváhagyott recepteket, fel kell jegyeznie a verzióinformációkat, és ellenőriznie kell, hogy a PLC késleltetett eredmény esetén a megfelelő munkadarabot selejtezi-e. A kódgenerálás gyorsabbá teheti a bevezetést; a fegyelmezett interfészek és a mérési bizonyítékok teszik megbízhatóvá a telepítést.