Fórum témák
» Több friss téma |
Fórum » PLC kérdések
Témaindító: Thomas10100, idő: Nov 12, 2005
Szia!
Nem ismerem a nyelvet, amin a példákat írod, de úgy vélem a bájtok sorrendjét fordítottad meg, majd egy lebegópontos típusú mutatóba tetted a tömb kezdő címét. Ezt a programot milyen rendszer alatt írod? Mi volt ami az adatokat átadta? Én azt az oldalt építem, ami átadja az adatokat...  Igen, ez többnyire utópia. Egyébként éhenhalnánk.Btw.: Talán a legjobb megközelítés egy fejlesztendő eszköz kommunikációs felületének meghatározásához annak megvizsgálása, hogy az eszközt milyen környezetben, milyen berendezésekkel együtt fogják használni. Tehát, például ha a szomszédos eszközök Modbus-on működnek - célszerű Modbust implementálni. És - ebben az esetben nyugodtan át lehet testálni a megjelenítés, adatgyűjtés stb. feladatokat a megfelelő PLC-re, OPC szerverre, stb. Ha Modbus felületet adsz, semmi mást nem definiálsz, csak register-eket, illetve coil-okat. Ha Canopen-t akkor DO-kat... De lehet IP felület is... na itt már sok variáció van ... Pl. Modbus IP felett... A lényeg az az, hogy az eszköz nem foglalkozik a megjelenítés, adatkonverzió problémájával, csak "adatpontokat" definiál (a legtöbb automatizálásban használatos protokoll így működik). Esetleg megpróbálja kényelmesen kialakítani. Ezért említettem korábban pl. az INT ábrázolást: Például, az említett frekvenciaváltó leírása azt mondja, hogy az XXX regiszter az aktuális kimenő feszültséget tartalmazza, 1 tizedes pontossággal. Ezek után az már a program, ill. megjelenítés feladata, hogy ezzel valamit kezdjen.
Kicsit off, de engem az zavart meg, hogy több helyen eltérő értéktartomány olvashattam a Float típus esetében. Aztán más helyen, ahol az ábrázolást részletezték bit szinten, felcserélték a leírásban az Előjel Mantissza Karakterisztika sorrendjét pont ilyen módon.
Ezek a dolgok elég egyszerűek, még is nagyon kevés a pontos infó és ezért az ember csak szenved, amíg meg nem találja a megfelelő forrást. Egy OPC szerver leírásában az van, hogy csak rá kell kötni a hálózatra, és már is elérhetőek az adatok. Ebből azt következtetné az ember, hogy van egy szabvány, ami leírja a lebegőpontos számok átadásának módját. Remélem kitisztul a kép, mert most csak a káoszt látom az ügyben. Idézet: „Nem ismerem a nyelvet, amin a példákat írod, de úgy vélem a bájtok sorrendjét fordítottad meg, majd egy lebegópontos típusú mutatóba tetted a tömb kezdő címét. Ezt a programot milyen rendszer alatt írod? Mi volt ami az adatokat átadta? Én azt az oldalt építem, ami átadja az adatokat...” Ó, ezt csak azért írtam, mert említetted, hogy fura eredményeket kapsz, ha megpróbálod a REAL 4-bájtos adatát felépíteni. Nos, néha ami eltér csak a bájtok sorrendje. Mint a Little / Big endian. Ez is örökké bekavar. Hát van ilyen a lebegőpontosnál is, érdemes kicsit molyolni vele. (először amikor nem működött, gondoltam írok egy konverziós eljárást, aztán rájöttem: csak a bájtok vannak fordítva) (btw, nagyon más gond nem lehet a VB-6-tal sem, kicsit csodálkoznék, ha teljesen egyedi módon ábrázolná a lebegőpontos számokat... Vagy estleg LREAL-t használ? Nem tudom. A nyelv egyébként CoDeSys - azaz IEC 61131-3 - ST, a probléma meg egy NicoBus átjáróról érkező adatok (pl. hőmérséklet) kezelése volt. Az adatok soros vonalon érkeznek... Hát véletlenül pont fordítva. Az élet már csak ilyen.
Tehát ha én azt mondom, hogy IEEE 754/1985 formátumban ezen a regisztercímen ilyen sorrendben található a 4 leíró bájt, akkor legyen a megjeleítést programozó gondja, hogy az kiolvassa és úgy kezelje, ahogy én leírtam? Végül is logikus, nem is értem miért akartam elvenni a munkáját valakinek!
Ha mindenképp lebegőpontosan akarod ábrázolni, akkor igen. Ennek csak akkor van értelme, ha a leírt értékben a tizedespont helye is erőteljesen változik.
Egyébként, az IEEE 754 ábrázolás kapcsán, nekem ez az oldal segített sokat: http://babbage.cs.qc.edu/IEEE-754/Decimal.html Addig próbálgattam, míg jó nem lett.
Az eltérést valószínű a hibás információk miatt gondoltam, amik az értéktartományokra vonatkoztak.
Én PIC C18-ban ütköztem abba, hogy a lebegőpontos számokat nem lehet shiftelni, ami a soros porton való elküldéshez szükséges lenne. Ezért egy uniont hoztam létre így:
Ezután már a
Ezt a módszert VB6 alatt még nem sikerült megoldanom, de ez más kérdés... Végül is a MODBUS kommunikáció a PLC- témába vágott, de azt hiszem kezd kilógni a dolog innen, ezért nem is szeretném nagyon tovább terhelni a türelmeteket. Esetleg egy javaslat, hogy van-e olyan topic, ahová ez a téma beférne? Mert ez nem C (PIC program), nem VB6(az eszköz kliensét ebben írnám), nem MODBUS, nem PLC, nem egy eszköz. Ez mindennek a keveréke... 
Igen, ahogy mondod, ez így szokásos. Tessékj egy példa egy dokumentációból - pontosabban az az alapján készült API-ból: (ez egy ENUM, ami az adattípusokat írja le, és a kommentekben szerepel azok pontos leírása)
Idézet: „Ez mindennek a keveréke...” ... Csakúgy, mint a legtöbb valós probléma. Én nem érzem innen annyira kilógónak a témát, de nem vagyok hivatott ebben nyilatkozni.
Kezd tisztulni a kép, nagyon sokat segítettél, köszönöm!
A MODBUS protokolnál nekem elsőre nagyon furcsa volt, hogy a Coils formátumot bitenként kezelik címzik és nincs igazi bájt formátum, csak word. Bennem valószínű azért okozott zavart a megoldás, mert úgy gondolkodtam, mint ha egy memória valós címeit kéne elérni MODBUS-on keresztül, holott nem valós memóriákat címeznek a Funkciók, hanem az eszközökben virtuálisan létrehozott regisztereket, biteket. Ezért is volt nehéz megérteni, hogy a SCADA oldalról hogyan is lesz értelmezve egy átküldött lebegőpontos szám, ami a memóriában tárolódik a PIC-ben adott formátumban. Valójában nem IEEE formátumot küldök át, hanem négy bájtot, amit majd úgy kell értelmezni, ha úgy akarom. Az is külön rész, hogy az értelmezést is én határozhatom meg az eszközöm adatlapjában, amit utána a rendszer programozója lekezel. Igazából egyszerűbb lenne a felhasználónak, ha még is lenne egy kialakult szabvány minden számtípushoz, mert akkor nem minden esetben lenne szükség egy új eszköz becsatlakoztatásához programozóra.
Üdv!
Idézet: „ Tehát ha én azt mondom, hogy IEEE 754/1985 formátumban ezen a regisztercímen ilyen sorrendben található a 4 leíró bájt, akkor legyen a megjeleítést programozó gondja, hogy az kiolvassa és úgy kezelje, ahogy én leírtam? ” Szerintem is, ez így rendben van. Például egy folyadékhűtő modbus panel doksija ezt mondja: Idézet: „ Coding of analogue values: Standard 32-bit IEEE format (2 registers). ” Egy példa a változólistájából: Idézet: „ Register 3 and Register 4: Outdoor temperature. Format: Float. Type: Read-only. ” Neked is ennyi dolgod van az adatszolgáltató cuccal. Imi.
Van ilyen szabvány, de az az OSI hálózati szintek között feljebb van / lehet definiálva. Pl. az OPC kliens és szerver között már nyilván vannak egyéb adattípusok.
A Modbus valamelyik alsó szinteken tanyászik, az alkalmazás meg a felső szinteken... A modbus nem foglalkozik az ábrázolással, csak nyers adatról beszél. Mindenesetre megkönnyíted a programozó dolgát, ha standard számábrázolást használsz, a regiszterek sorrendjében, és azon belül a bájtok sorrendjében. Például RegXXX1.0 - Float byte1 RegXXX1.8 - Float byte2 RegXXX2.0 - Float byte3 RegXXX2.8 - Float byte4 Ez ugye egyszerű, mert a beolvasott bájtok sorozatára simán rá lehet mutatni egy float (real) pointerrel. De kics*szel a programozóval, hogyha: RegXXX1.0 - Float byte2 RegXXX1.8 - Float byte1 RegXXX2.0 - Float byte4 RegXXX2.8 - Float byte3 Na persze ez sem annyira vészes azért... :p Ha meg a szabványos megjelenítő eszközökre hajazol valóban javasolnám az INT alapú ábrázolást! Én leginkább ezekkel találkoztam eddig.
A sorrendben én is gondolkodtam, miután ez nem egy szokásos soros kommunikáció, ahol a Hi megy elöl, hanem egyedi és a MODBUS felett álló protokol, ezért az átadás is lehet felhasználóbarátabb.
Az INT alapú a tizedespont helyét meghatározó formátum? Végül is ez se rossz, bár kicsit fura és konvertálni kell az IEEE-ről az elküldés előtt. Ez akár komolyabb erőforrást is igényelhet egy 8bites eszköztől ha belegondolsz.
Nem feltétlenül. Ráadásul a mai vezérlők CPU idejét firtatni a leggyakrabban szőrszálhasogatás. Amellett, hogy mondjuk TCP/IP kommunikációval, stringek kezelésével, fájlkezeléssel, néha még megjelenítéssel is foglalkoznak, egy int-to-real konverzió talán elhanyagolható. Ráadásul nem is mindig kell.
Például egy konkrét ismert gyártó által mellékelt folyamatszabályzó funkcióblokkok... mind a mai napig nem használnak REAL-t. Még a PID szabályzó sem. A jól bevált 12 bites jeleket veszik, és kezelik a mellékelt diagnosztikai biteket. Tehát... az eszközöd kialakításánál esetleg az is érdemes figyelembe venni, hogy az adott mérési eredményt: hőmérséklet, nyomás, feszültség, stb... hogyan szokták ábrázolni... Itt bizony gyakran használatos a 12+4 bit... (Ó, értem... utólag olvastam... tehát, hogy a PIC erőforrásainak okozhat esetleg problémát... Miért? Hogyan keletkezik az érték?)
Az érték eleve Float típusként él a PIC-ben. Esetemben egy polinom együtthatói, amit írni olvasni kell tudni a kalibrációhoz.
Lehet, hogy a PIC esetében is eltúloztam, de ha belegondolsz elég sok lépésből lehet egy lebegőpontos alakból előállítani a számsort és kiszámolni, hogy hová kerüljön a tizedespont. A PC-nek abszolut nem gond a lebegőpontos alakot konvertálni bármivé.
Sziasztok!
Néhány nap múlva kimegyek külföldre nyári munkára. A főnököm tudja, hogy a suliban tanultam programozást (C, C++) ezért már előre szólt, hogy meg fog bízni azzal, hogy írjak neki egy programot (amúgy nem ez lesz a munkám, ez csak amolyan plusz dolog). Ma tudtam meg, hogy mit kell csinálnom: Van egy gépe, amely egy szalagot futtat. Írni kéne egy olyan programot, amely óránként beindítja a gépet és 5 percig futtatja a szalagot. Annyit tudok még, hogy ez a gép egy PLC. Namármost a probléma az, hogy én csak C-ben illetve C++ -ban tudok programozni. PLC-ről még semmit sem tudok. Maga a program így elsőre nem hangzik túl nehéznek, viszont fogalmam sincs hogy hogyan álljak neki... Egyáltalán lehet PLC-t C-ben vagy C++ -ban programozni? Esetleg tudnátok adni egy irányt, hogy merre induljak el? Vagy esélytelen a dolog és inkább hagyjam? Minden ötletet, tanácsot, választ köszönök előre is!
Hello, létezik olyan PLC szimulátor amelyhez nem szükséges hogy rendelkezzem PLC hardverrel, ha igen melyik az? Köszi
Azt, hogy C-ben lehet-e programozni nem tudom, de egy ilyen feladathoz kicsit túllövés lenne C-ben küzdeni vele. Mi Festo PLCkel foglalkoztunk a suliban, egyszerű létraprogramokat lehet csinálni hozzá, ha jól érted a programozást, akkor egy kis gondolkodással menni fog a dolog maximum 1 nap alatt. Jelzőlámpás kereszteződést olyan 1 óra alatt írtunk, amikor benne voltunk a dologban, ne ijedj meg tőle, a google meg a dokumentáció sokat tud segíteni
Hello! Én is FESTO PLC-n tanultam programozni. Az alapfeladatok elég egyszerűen, hamar elsajátíthatók.
Porgramot írhatsz: - Utasításlistás programozással, - Funkcióblokkal, - Áramúttervel A programod lehet: lépésprogram, logikai, vagy mixelt Egyébként nem ártana tudni a teljes problémát! (allokációs listához a szenzorok/aktorok típusait, teljes leírás) A FESTO-ék weboldalán nézz szét. Múltkoriban ott láttam mintafeladatokat.
Szijasztok
Nemrég találtam egy SIEMENS SIMATIC S5 101U nevezetű PLC-t. Azonban a programozója nincs meg:S Ebben szeretnék segítséget kérni valaki nem tud-e egy kapcsolást amivel kilehetni váltani a hiányzó programozót! Itt egy link a PLC-ről http://www.wallerath.com/assets/Doku%20S5-101x/S5-101U_Operating-In..._e.pdf Nekem az első képen lévő baloldali PLC van meg.
Van itt a hobbielektronikán is S5 fórum, ahova már tettem fel én is működő átalakító kapcsolást.
Sziasztok.
PLC-vel kapcsolatban lenne kérdésem. Most tanulgatom a használatát az egyetemen és úgy döntöttem ebből írok szakdolgozatot. Még csak éppen hogy elkezdtem kóstolgatni, ezért bocsánat ha túl triviálisat kérdezek. Szóval amit kitaláltam az lényegében az, hogy egy flash-ben írt kijelzőn keresztül vezéreljem a plc-t. (OMRON típusú) A kijelző már elkészült, és a plc vezérlés egyes részeit is megírtam, viszont a kettőt összekötni még nem tudtam. Valaki tudna ajánlani valamilyen megoldást erre a problémára (lehetőleg úgy, hogy úgy is működhessen, hogy szimulálom a plc-t a nyárra nem tudok sajnos bemenni a laborba). Olvastam, hogy OPC-vel lehetséges lenne, esetleg az omron termékcsomagjában a dde menedzserrel is, viszont ezeket még egyáltalán nem ismerem, és nem találtam hozzájuk használható példaprogramot, illetve ingyenes opc szervert. Megköszönném ha el tudnátok indítani a helyes irányba.
Szia!
A Qnx és az Adobe kifejlesztett egy közös, flashen alapuló rendszert, kifejezetten autóelektronikák vezérléséhez: Bővebben: Link . Amennyiben van konkrét megoldásod akár ez alapján - akár más forrásból, a végeredmény engem is érdekel. Én is találtam egyfajta megoldási lehetőséget, de műszaki falakba ütköztem. A Wayteq PNA képes flasht futtatni natívan. Írtam is rá egy kis gombvezérlést, de a beágyazott flash mindig felülbírálta a gombkezelést a sajátjával. Nyilván hackkel is mehetne, de több időm nem volt rá. WinCE6 fut rajta - nálam éppen egy totalcommanderből klónból érhető el. Maga a PNA a memóriakártya és az USB felől biztosan elérhető valahogyan és nem túl drága. De használhatsz IPC-t, PPC-t, TPC-t - amin fut a flash. Ha több infó kell keress meg. Sokat segíthet az OPC szerver használata, hiszen minden jobb érintőképernyőnek is van OPC szervere. De használhatsz célszoftvereket is pld. Galileo (Möller é.k.).
Szia.
Köszönöm a választ, amint jutottam valamire neked is megírom hogy mi lett végül a megoldásom.
Sziasztok
Érdeklődnék hogy aki használja a Wincc Flexible programot, találkozott-e olyan jellegű hibával hogy Runtime indításakor mindig (ÁLTALÁNOS KAPCSOLATHIBA 0X382) hibát ír bármely kommunikációra! Segítséget előre is köszönöm.
Hali!
Igen. A hiba kódja 140003 (ha ezt is leírod, hamarabb meg lehetett volna találni) Azt jelenti, hogy a runtime-nak nincs kapcsolata a PLC-vel.
sziasztok!
Siemens S200-zal programozgatok és kíváncsi lennék nincs e valakinek hozzá vmilyen anyaga a mélyebb programozáshoz.
Helló!
Minél mélyebb? Ez itt az S7-200 528 oldalas magyar nyelvű system manualja Vannak még további (magyar) leírások az oldalam linkgyűjteményében. nem idézem be mindet, nézz szét ha gondolod... |
Bejelentkezés
Hirdetés |
