Mert nem működik!

A poént nem szabad lelőni, mégis ez kívánkozott címként. A telefonbeszélhgetés így zajlott le:
- Látom, van Önöknek soros Ethernet átalakítójuk..
- Igen, van.
- Mennyibe kerül?
- Az 1 portos eszköz ára kb. 26eFt plusz ÁFA.
- Hát az nagyon drága!
- ...
- Van egy magyar cég, amelyiknél sokkab olcsóbban lehet kapni hasonlót!
- Akkor miért nem azt vásárolja meg?
- Mert nem működik.

Mennyibe is kerül?

Mindig attól függ, csak még nem tanultuk meg, hogy mi a drága és mi az olcsó. Egy másik történet, zintén telefonbeszélgetés:
- Szia X vagyok, itt állok egy PC-nél ....-n, van benne egy 8 portos soros kártya, biztos olcsó volt, ami hol működik, hol nem, nem tudsz segíteni?
- Hát, nem tudom; mi a tipusa? Ki a gyártó?
- Sajnos, nem tudom, valami ABCDEF, amikor újra indítom a gépet, egy darabig megy, aztán leáll a kommunikáció. A ti CP-168 kártyátokkal még nem volt bajom..
- Adunk egyet, leviszed, beüzemeled, ha megy, leszámlázzuk, ha nem, akkor visszahozod. Rendben?
- Ez jó ötlet, már harmadszor vagyok itt emiatt, háromszor négyszáz kilométer, benzin, munkaidő, bosszúság.
- Akkor az drága kártya - olcsó kártya árkülönbözetét már párszor eltankoltad!
- Sajnos el.

Elvitte a kártyát, üzembe helyezte, azóta nincs gond. A CP-168 kártya tehát olcsó, vagy drága?

A nyájas olvasó

talán hallott, látott, megélt hasonlókat. Vagy csak az én túlzó megfogalmazásom? Végülis mi a drága?
Első eset:
- a termék gyártója (az egyik) piacvezető, több millió darabot a világpiacon értékesítő világcég
- az eladó (akármilyen boltban) ért az általa értékesített termékekhez, segít a megfelelő kiválasztásában
- 5 év garanciát ajánl
- "ha baj van, hívjon fel, segítünk az installálásban"
- "ha elromlik, elintézzük Ön helyett a garanciális ügyeket"
az ár: mondjuk száz!
A másik lehetőség:
- a termék gyártója egy öt fős hazai cég, több mint száz darabot értékesített
- az eladó (akármilyen boltban) nem tudja mire jó, de olcsó
- a garancia 1 év, de a gyártóhoz kell mjad menni, ha baj van
- ő nem ért az installáláshoz, de van egy ismerőse, aki kisebb összegét megteszi ezt
- ha elromlik, vegyen másikat, úgyis olcsó (ez velem megtörtént!)
az ár: mondjuk hetven!
Ön szerint melyik a drága?

És végezetül a legkedvesebb:
- Látom, van maguknak soros USB konverterük, van hozzá driver is?
- Igen, van.
- Mennyi az ára?
- Hétezer kétszáz.
- Ugye, ÁFA-val?
- Nem, ez a nettó ára.
- Micsoda? Amikor a beépített chip csak kétezer forintba kerül? Felháborító! Én sokkal olcsóbban megcsinálnám magamnak!
- Miért nem teszi ezt?
- Hát... mert meg kellene írni az illesztő szoftvert, ahhoz meg nem értek..

Szóval sokszor vicces

ilyenkor mindig a régi anekdota jön elő: Kérek egy kiló banánt, mennyi lesz? Száz forint. Micsoda!? a szemben lévő boltban csak ötven! Miért nem ott veszi? Mert ott elfogyott. Na majd ha nálam is elfogy, akkor nálam is ötven lesz!

Tanulság

épp most nézegettem az átdolgozott web-lapunk kapcsán a réges-régi Bubu lapján leírt szösszeneteket. Lehet, hogy még mindig érvényes (tíz év múltán) is, hogy miért vegyünk olcsó szoftvert? azér mer olcsó? és miért jó? mert olcsó...

Vagy inkább ne vegyünk!?

Három kívánság: teljesítve egy kuPACban

A korszerű irányítási rendszerek megvalósítása során sokszor egymásnak ellentmondó követelményekkel kell szembe nézni. Míg a hagyományos irányító rendszerek egyszerű érzékelőkkel és beavatkozó szervekkel voltak kapcsolatban, a legtöbb modern alkalmazás esetén ez csupán a kezdet. A fejlett algoritmusok, a hálózati illesztések, az eszközök összehangolt együttműködése és a vállalatot átfogó adatintegrálás a korszerű megoldások esetében jelentős követelménynövekedést jelentenek. Képzeljük el, hogy egy komplex aritmetikai műveletet (PID szabályozó, lebegő-pontos öntanuló algoritmus) létradiagrammal kell megvalósítani, vagy adatot kell cserélni OPC felületen keresztül. Elég nehézkes. Vagy a PC-n megszokott vizuális felülettel szeretnénk multitaszkos, pontos időzítést kívánó sorrendi vezérlést megvalósítani. Ahogy mondják: bármit meg lehet oldani akármivel, de…
Legyen a PLC inkább PC!
Amikor Önnek PLC-t kell használnia egy korszerű rendszerben, azonnal felmerül a hálózati kapcsolatok, különböző eszközök protokoll illesztésének, a vállalati üzleti rendszer illesztése és más kívánságok kielégítésének problémája. Az ilyen típusfeladatok inkább a PC képességeihez illeszkednek. PLC-alapú alkalmazásokban ilyen esetekben további processzorokra (mint eseménysorrend elemző kártya), hálózati átjárókra vagy konverterekre, elkülönült PC-n futó „middleware” szoftverre, és a vállalati rendszerekhez történő integrálását megoldó szoftverekre van szükség.
Legyen a PC inkább PLC!
Másrészt viszont az ipari környezetben a PC, bár a legkorszerűbb képességeket nyújtja az adatfeldolgozás és a hálózati kommunikáció terén, mégiscsak igen védtelen, még ipari PC használatakor is. Ahogy egy PLC is csak nehézkesen oldja meg a PC-szerű feladatokat, a PC sem képes teljesíteni a PLC-szerű feladatokat: például az időkritikus, determinisztikus ütemezésű lefutó vezérlés megvalósítása elég kilátástalan. A külső I/O egységekről, bővíthetőségről nem is beszélve.
Legyen integrált, mint egy DCS!
A DCS rendszerek használói nagyra értékelik a hardver és a szoftver integráltságát. Mivel egyetlen pontból látható a fejlesztői környezetben minden I/O pont, változó és érték, a megjelenítések szorosan kapcsolódnak az algoritmusokkal, a fejlesztés, a beüzemelés és üzemeltetés során egy szempontrendszer szerint kell eljárni.
Legyen akkor PAC!
Az automatizálási rendszerek gyártóinak meg kell felelniük a fenti az elvárásoknak. A PLC-stílusú, determinisztikus gép és folyamatvezérlés kombinálása rugalmasan konfigurálható, és az üzleti rendszerekhez integrálható PC-alapú megoldásokkal új korszakot teremtett: eljött a PAC (Programmable Automation Controller) kora. Az elv persze itt is régebbi, már korábban is megjelentek az úgynevezett “add-on” típusú megoldások, azonban igen alacsony integráltság mellett. A PAC sokkal szélesebb spektrumot fog át, hiszen már a tervezése is ezek szerint történt. Például az olyan feladatok, mint számlálás, tárolás, PID szabályozás, adatgyűjtés és feldolgozás, egy tipikus PLC rendszerben nagyon sok kiegészítőt igényel. A PAC-ba mindezt beépítették. A PAC alapvetően moduláris felépítésű, nyílt architektúrát használ, így bővíthető és a más rendszerekkel történő kommunikáció is beépített. Pontosabban szólva, a PAC rendszerek egyszerre képesek hatékony feldolgozásra és I//O műveletekre. A PAC többfunkciós, egyszerre kérdezi le az analóg és digitális jeleket és vezérli azokat, mialatt akár soros jeleket fogadhat más eszközökből is.
A SNAP PAC rendszer
Az OPTO 22, az Ethernet alapú irányítórendszerek innovatív gyártójának rendszere teljes mértékben kielégíti a fenti elvárásokat.

1. A SNAP PAC System™ négy komponensből épül fel: szoftver, vezérlőegységek, fejegységek és I/O. Az alkalmazások fejlesztése, belövése és hibakeresése lényegesen egyszerűbb egy integrált rendszer esetében, drasztikusan csökkenti a ráfordított időt, pénzt és fáradságot.
2. Alacsony bekerülési és hosszú távú költségek. A SNAP PAC rendszer kevesebbe kerül, mint a legtöbb általános célú PLC rendszer. A szoftver ingyenes, ezért indulási költségei alacsonyak. Mivel a tréning és a támogatás is ingyenes, így a hosszú távú karbantartási költségek is alacsonyak maradnak.
3. Egyetlen rendszer sok automatizálási projekthez. A SNAP PAC rendszer több célú. Ön egy olyan rendszerrel kezelheti összes projektjét, amely jól illeszkedik a folyamatirányítás, gépvezérlés, hajtásvezérlés, adatgyűjtés, sőt a távoli monitoring és SCADA rendszerek megvalósításához is. Ma egy kis projekttel kezdhet, később bővítheti azt. Nem dob ki pénzt az ablakon, a flexibilis hardver megmaradhat hosszú évekig.
4. Fejlett programozási eszközök. A SNAP PAC rendszer grafikus folyamatábrákkal, vagy a kifinomultabb, Basic-szerű script nyelvvel, vagy akár a kettő kombinációjával programozható. Mindkét módszer tartalmazza az összes irányítástechnikai funkciót, sőt, a lebegő pontos matematikát, a string kezelést, tömböket, szubrutinokat, mutatókat és más fejlett eszközöket is.
5. Egyetlen, integrált tagnév adatbázis. Amikor Ön létrehozza a PAC Control alkalmazást, tetszőleges emlékeztetető néven nevezheti el változóit. Ezután a PAC Display HMI fejlesztő környezetben ugyanezeket a neveket használhatja, nem kell újra begépelnie azokat, nincs szükség kereszt referencia táblázatra sem. Ezzel a hibalehetőségek és a fejlesztési idő is jelentősen csökkenthető.
6. A világ legjobb I/O eszközei. Nem túlzás, hiszen a legtöbb SNAP I/O™ modult életre szóló garanciával szállítjuk. Minden modul egyedileg tesztelt, nincs szükség statisztikára.

A SNAP PAC rendszer a néhány I/O pontostól a több ezerig alkalmazható. Ön megbízható analóg, digitális, soros vagy speciális I/O modulokból választhat a legkülönbözőbb ipari jeltartományokra. Áram, feszültség, AC, DC, hőelem, ellenállás hőmérő, RS-232 és RS-485, Profibus®, hajtásvezérlő modul, nyúlásmérő bélyeg, teljesítménymérő és még sok más modul, és mindegyik együttműködik a SNAP PAC rendszerrel.
A beépített Ethernet hálózati illesztőt minden SNAP PAC elem tartalmazza, így nem kell azzal törődnie, milyen kommunikációs processzort (CP modult) - és milyen áron - válasszon. Emellett minden soros eszközzel, mint vonalkód olvasó, RFID olvasó, soros kijelzők és mérlegek, modemek, képes kommunikálni. Mivel a standard Ethernet hálózatot használja, minden natív protokollt ismer, ide értve a TCP/IP, UDP/IP, SMTP (email), SNMP (hálózat menedzsment) és a Modbus®/TCP protokollt is.
+1: Legyen a szoftver ingyen
A PAC Project™ Software Suite — egyszerűen használható, folyamatábra alapú vezérlőegység programozó eszköz, a HMI fejlesztő és futtató szoftver, valamint az opcionális OPC szerver és adatbázis illesztő szoftver adja meg a szoftver alapokat. Mindez (opciók nélkül) ingyenes. Nem hiszi? Járjon utána, próbálja ki! És hogy ne kelljen hardverre sem költenie, használja az ingyenes SNAP PAC szimulátort! Próbálja ki még ma ingyenesen: http://www.comforth.hu/PAC/

Protokoll konverzió - kész

„Van két mérlegünk, egy vonalkód olvasónk,
és még egy áramlásmérőnk is”. Ülünk a tárgyalóasztalnál és beszélgetünk arról, hogyan lehet a mért értékeket megjeleníteni, tárolni, és ami ilyenkor még szokásos. Akkor az iFIX SCADA szoftver megfelelő lesz - egyezünk meg. De hogyan jut el minden mért adat a SCADA számítógépbe? „Minden eszközünknek van RS-232 illesztője” – meséli büszkén a felhasználó. És ismertek a protokollok is, ahogyan az eszközök beszélnek? „Erre gondol?” - kérdezi, és mutatja a gépkönyveket; természetesen mindegyik más protokollt támogat és egyik sem Modbus. „Ezt meg tudják oldani?” Természetesen, sok fejlesztőeszközünk van rá –hangzik a válasz; a legjobb lenne, ha minden eszközzel Modbus/TCP felületen kommunikálnánk, mert (i) szabványos, későbbi eszközöknél még jól jöhet; (ii) kihasználhatjuk a meglévő Ethernet hálózatot; (iii) később az üzemi intelligencia rendszer kialakításhoz (hatékonyság elemzés, termék- és termeléskövetés) is megteremti.

Van egy ügyes fiú, aki jól tud programozni, biztos olcsón, gyorsan és jól megírja ezt is. Ekkor kicsit eluralkodik a szkepszis: és készített már hasonló alkalmazást? Milyen eszközzel? A valós idejű programozásban is jártas? Elég kényes kérdések… A szokásos csönd. Mi lenne, ha nem kellene programozni senkinek, elég lenne a protokollokat egy eszköz tudomására hozni, amelynek a Modbus/TCP felülete már készen van. Aztán egyszerű generálás után minden terepi eszköz már beszélne. „Mi ez az eszköz?” A MOXA legújabb szoftverterméke, a Protokoll Konverter (rövidítve MPC). „Ez igazán érdekes, és milyen PC-n lehet futtatni a kész alkalmazást?”.
Akkor most PC vagy IPC? Egyik sem: EC!
Hol helyezzük el a protokoll konvertert? –hangzik a kérdés. A „műszerterem megfelelő hely lenne”, ahol a SCADA gép fog működni, ezen futhatna az összes illesztő program is. „De még jobb lenne, ha a terepi szintre tennénk egy ipari PC-t!” Mi lenne, ha nem kellene az eszközillesztéshez sem mozgó alkatrészt, sem merevlemezt, sem ventillátort tartalmazó, hagyományos – akár ipari - PC? „Ez lehetővé teszi, hogy közvetlenül a technológia mellé tegyük a számítógépet? És a hőfok, rázkódás, illetéktelen hozzáférés?”. A beágyazott számítógépek (EC: embedded computer) erre lettek kitalálva: akár extrém hőmérsékleti tartományban, a terepen alkalmazhatóak, és mivel nincsen kijelző és billentyűzet (hacsak valaki nem igényli), így védett is. Egyszerűen az Ethernet hálózatra csatlakoztatjuk, és az adatok már száguldanak is az adatgyűjtő számítógépbe. „És ez a megoldást támogatja az MPC? És az operációs rendszer?” Lehet akár Windows CE, akár Linux, ki melyiket szereti: az MPC mindkettőn működik.

Délután öt óra – a protokollok elkészültek - mondja Gergő kollégám. De hát csak reggel kezdtél hozzá! Az MPC három előnyét kihasználva igen gyorsan haladtam. Mik ezek az előnyök?
1. Az MPC motorba a soros és a hálózatos kommunikáció egyaránt beépítésre került. A felhasználó részéről semmilyen programozás nem szükséges, hiszen az MPC motor transzparens módon kezeli az adatátvitelt mind a két tipusú kommunikációs port tetszőleges kombinációjában.
2. A port-port kommunikációt ellátó driver programozható. A legtöbb terepi rendszer illesztésénél csak kisebb simításokra van szükség: csak ki kellett próbálni, és működtek. Az MPC motor használatával ezek a módosítások gyakorlatilag azonnal elkészülnek, akár a driver módosításáról, akár a meglévő driverhez történő új csatorna hozzáadásáról van szó.
3. A motor többszörös driver használatát is támogatja egy csatornán belül – ez egyszerűsíti és modulárissá teszi a tervezést, ezáltal az alkalmazás konfigurálása hihetetlenül egyszerűvé válik.
Másként szólva, a rendszer 85%-ban kész, mielőtt a munkát elkezdenénk.

Ha én rendszerintegrátor lennék… Akkor erősen elgondolkodnék a fenti példán. Költség oldalról: mennyibe kerül egy fejlesztőnek egy illesztő driver megírása, ha akár magas szintű, ugyanakkor real-time programozói eszközt használ. Hogy is szól az ököl-szabály tétel: „minden programsor megírása (teszteléssel, belövéssel) legalább 10 dollárba kerül: akár gépi kód, akár C++; ezért érdemes magas szintű nyelvet használni, persze, hogy milyen gyorsan fog futni, az más kérdés …). Vagy számoljunk órabérrel? Mennyi idő kell egy ilyen program megírásához? 200 óra? Vagy több?
A másik kérdés: egy rendszerintegrátor hogyan tudja befektetéseit megsokszorozni, magyarul: hogyan és hányszor lehet eladni egy drivert? Egyszer, mert úgyis lemásolják? Védőkulcsot gyártat hozzá (kerül, amibe kerül)? Vagy a MOXA EC család hardver eszközeibe tölti le a kész programot, ahonnan csak ő tudja kiolvasni, és módosítani?
Tehát egy szolgáltatást nyújt egy eszköz értékesítésével!

Aki lejegyezte: Bóna Vilmos.
Aki a rajzot készítette: Kovács Gergely (akinek még erre is maradt ideje a protokollok elkészítése mellett).
Ha Ön többet szeretne megtudni az MPC szoftverről, kattintson ide.