Délután megpróbálom ujra.

SZiasztok!

Nem éppen erre a problémára találták ki a SCADA-t? A Moellernek is van - ráadásul ha az eszközt megvetted a szoftverlicensz pontjaid miatt ingyenesen kapod. Ha jól emlékszem talán Galileo a neve. Nyilván az objektumok készen vannak de a rendszert neked kell felépíteni. Ha kész akkor már akár webről is nézegetheted. Azt nem tudom, hogy éppen az Easy 820 ezt mennyire támogatja.

Helló kameleon2!

Szerintem te is félreértetted a kérdést.
A SCADA-val meg lehet csinálni (én is olyasmivel, konkrétan HMI-vel csináltam ilyet) , de hogy erre találták volna ki, az túlzás...

Hali Szirty

Hogyan tudnék ilyen rendszer üzenetet amit írtál beletenni a projectembe?

Hali mazso1988!

Ami megjeleníti a HMI rendszer üzeneteit, hogy kiderüljön felvette-e a kapcsolatot?

Azért tettem oda egy képet a mellékletbe, mert számítottam erre a kérdésre.

Tehát leraksz egy"Alarm View" nevű objektumot és beállítod úgy, hogy a képen van.

Megvan köszi.
Meg is próbáltam de nem tudott kapcsolódni az S7-200 CPU-hoz.

Set PG/PC Interface fülnél MPI (Wincc) PC/PPI cable van kiválasztva.

Hali!

Alakul ez. majd állítsd két sorosra az alarm view-et, vagy szélesebbre az ablakot, hogy kiderüljön hova is nem tudott írni.
Egyébként az acces pointra panaszkodik. olyan, mint ha olyan access pontot adtál volna meg, ami nem létezik.

(Miért MPI? Az S7-200 nem tud MPI-t, csak PPI-t)

Olvasgatom az oldaladon a HMI részt nagyon jó.

Ahogy a csatolt képeken van jelenleg így próbálom csatlakoztatni.

Hali mazso1988 !

Ez így jó nyilván ha a Microwin látja a PLC-t, akkor a PG/PC interface-ben jól van beállítva.
Már csak az a kérdés mit adtál meg access pointnak a Wincc Flex-ben és hogy a WinCC Flex milyen kommunikációs interfészt kapott.

Ezekkel lehet a probléma. De újra megjegyzem, hogy S7-200-assal nem szoktam foglalkozni.

Az Acces pointot a vezérlőpult set/pg interface-nél tudom csak állítani vagy magában még a Wincc-ben is tudom ezeket a paramétereket külön állítani?

Én Wincc-ben csak a communications fülnél állítottam.

Hali!

Tehát az access point lényege a következő:
A PC-n a Set PG/PC interface-nél létre tudsz hozni access pointokat illetve van pár gyári is.
Mindegyiknek van egy neve és mindegyikhez be lehet állítani egyet a felsorolt interface-ek közül.

Az access point egy preset lényegében. A nevével lehet rá hivatkozni és mindazokat a beállításokat képviseli, amiket hozzá állítottunk be PG/PC interface beállításoknál.

A Flexible projectnek megadhatod, hogy melyik access pointot használja. Az access point pontos nevét kell beírni neki. Ha van olyan nevű access point beállítva a set PG/PC interface-ben, akkor annak megfelelően próbál meg kommunikálni.
Ezen a képen látható hol van megadva neki az access point neve.

Mivel az access pointok lényege nem csak az, hogy különböző beállításokat képviselhetnek, hanem függetlenek is egymástól, meg lehet velük csinálni pl. azt, hogy futtatsz egy WinCC Flex runtime-ot egy gyárban a saját gépeden, ami egy vagy több berendezésről ad neked infót és mondjuk a PLC-kkel etherneten keresztül kommunikál. Eközben te elindítod a Step7-et és MPI buszon keresztül programozni, monitorozni kezded. A két eltérő kommunikáció párhuzamosan, egymástól függetlenül zajlik (ethernet és MPI). Ha az említett Flex runtime is az alapértelmezés szerinti S7ONLINE nevő access pointot használná, amit a Step7 környezet, akkor ezt nem lehetne megcsinálni, mert a flexible is MPI-n akarna kommunikálni.

Itt írtam róla régebben
Meg itt is

Ha te a flexible-ben az alapértelmezés szerinti S7ONLINE-on hagytad az access pointot, akkor hiába működik jól a Microwined S7-200-al, a Flex runtime az S7-300-hoz beállított interfészen keresi!

Hali Szirty
Szépen lassan már kezd világos lenni számomra ez az egész, akkor ezen a csatolt képen látszik hogy nálam az Acces point neve Micro/Win ha ezt én a Wincc-ben átírom S7ONLINE-ról Micro/Win-re akkor már működhet?

Hali mazso1988!

Pontosan!
Vagy a Set PG/PC interface-ben az S7ONLINE access pointhoz tartozó beállítást állítod be ugyanúgy, ahogy a Micro/Win nevű van beállítva.

Szia Szirty

Hát valahogy nálam sajnos nem akar kommunikálni a Wincc az S7-200 CPU-val, végső esetben megtudnám próbálni amiket kiszeretnék jeleníteni Siemens OP3 Operator panelon is.

Megtudnád esetleg mondani hogyan lehet adatátviteli módba tenni az OP3-at, OP7-nél tudom de ennél sajnos nem.

Közben megtaláltam

Adatfeltöltést az RJ csatlakozóján keresztül kell?

Hahó valaki Yokogawa DCS-ben nincs otthon véletlenül. Ebben írom a szakdolgozatomat és lehet el kellene egy kis segítség mert egyedül több idő rájönni a dolgokra.
Amit használok az a centum cs300 progi.

Előre is köszi a segítséget.

Szia Szirty
Szeretném megkérdezni hogy azon kivül hogy a WinCC-ben a communication fülnél beállítom a megfelelő protokolt + az Acces pointnál is hozzárendelem a megfelelőt utána működni kéne neki elvileg igaz?
Ennek ellenére nálam továbbra sem hajlandó a Runtime kommunikálni az S7-200 ezközzel és már egyszerűen nemtudom mihez kezdjek.
De én úgyveszem észre hogy már a kapcsolat sem akar felálni mert nem is látszik a kommunikációs kébelem sem semmi.

Hali!

Ha ugyanazon azon az S7-200 kommunikációs porton, ugyanazokkal a beállításokkal használod, amivel ugyanazon a gépen a MicroWin zavartalanul kommunikál, akkor gondolom elvileg igen.

De S7-200-al még soha nem próbáltam WinCC flexet összehozni, nem tudok több tippet adni!

Sziasztok!
Lehet tudni, hogy a PLC-k MODBUS protokolon milyen formátumban szokták a lebegőpontos számokat átadni a masternek(OPC szerver, SCADA rendszerek)? RTU vagy ASCII mód a szokásos?
Egy 4(vagy több) bájton ábrázolt lebegőpontos számot csak akkor lehet értelmezni, ha a master is igyanúgy írja le(értelmezi), de ráadásul az ilyen számokat bájtonként nem is nagyon lehet írni, csak unionos trükközésekkel, így elképzelni nem tudom, hogy RTU módban hogyan szokták ezt megoldani.
Én meg tudnám oldani a magam módján, nem is ez a gond, hanem az, hogy hogyan szokták! Nekem most egy olyan megoldást kéne választanom, ami elterjedt, és fel vannak készítve rá az OPC szerverek, illetve a SCADA rendszerek!
Köszönöm előre is, ha valaki utánanéz, vagy tippet ad, hogy hol lehetne ilyen infót nyerni!

Üdv!

RTU-t szoktak alkalmazni az én tapasztalatom alapján. A formátum az IEEE szerinti 32 bites lebegőpontos szám, vagyis ez 2 regiszterben (2 szóban) tárolódik.

Példa egy MODBUS RTU-t használó eszköz pdf-jéből:

Registers 16 and 17: "Setting 1 cooling (P121)"

A 17-es szóban van a magas helyiérték (ezt ellépteted 16 bittel balra), a 16-osban pedig az alacsony helyiérték, ezt meg beteszed a DWORD alsó 16 bitjébe.

Itt egy példa ST nyelven:

(* fg. deklaráció *)
FUNCTION DW_TO_REAL : REAL
VAR_INPUT
hiWORD: WORD;
loWORD: WORD;
END_VAR
VAR
temp: DWORD;
pt: POINTER TO REAL;
END_VAR

(* kód *)
temp := SHL(WORD_TO_DWORD(hiWORD), 16) OR WORD_TO_DWORD(loWORD);

pt := ADR(temp);
DW_TO_REAL := pt^;

Imi.

Ez haszon infó. Most már csak az a gondom, hogy a C18 (PIC C nyelv) úgy tűnik nem ezt a formátumot használja. Viszont ha kell átkonvertálható.

Még azon gondolkodom, hogy az OPC szerver hogyan kérdezheti le a lebegőpontos számot? Melyik funkciókóddal? Fel, vannak-e készítve szerinted arra, hogy ha pl, a Coils funkció nincs támogatva a slave által, akkor a Holdig(03) funcióval próbálkozzon?

Elképzelhető, hogy a PLC-k eltérő módon kommunikálnak, már ami az OPC szerverekhez való illesztést illeti? Vagy erre is van talán valami szabvány? Esetleg az OPC szerverek fel vannak készítve a nagyobb gyártók megoldásaira, amit ki kell adott esetben választani, azaz nekem egy ilyen gyártót kéne utánoznom, ha nem akarok problémát a kommunikációban, ha több SCADA megoldáshoz akarnám használni a slavemet(pl. DeltaV, iFix, OPTO)?

Hol lehetne ilyen infókat beszerezni?

Hali nekem van FEC34-em ha komojan gondolod írj.

Sziasztok egy kis segítséget kérnék
FEC34-hez kellene programozó kábel...
Az ára borzalom, így csináltam eggyet de az istennek nem megy. Átnéztem a bekötést: jó, kimértem: nincs szakadás. Az 5V-ot külön táprol adtam neki.
De mint említettem nem igazán megy.
Ha valaki tudna segíteni nagyon megköszönném.

Azt már kiderítettem, hogy a C18 is az IEEE 754/1985 -öt használja, csak a VB6 nem, vagy elírtak valamit a max-min értéktartományon, mindegy...

A Modbus protokoll nem határozza meg a real értékek ábrázolását, ezért viszonylag gyakori megoldás az is, hogy int-ként ábrázolják, és leírják, hány tizedessel kell eltolni, illetve hogyan kell azt értelmezni.

Az okos SCADA vagy HMI alkalmazások egyébként töggnyire minden elterjedt ábrázolási módot kezelnek, vagy lehetőséget biztosítanak azok programozására. Mindenesetre az IEEE 754 formátumú real ábrázolás elég jó megközelítésnek tűnik.

A legutóbbi alkalommal a REAL konverziónál nekem pusztán a leíró bájtok sorrendje okozta a problémát... valami ilyesmi lett a megoldás:

(* Reverse Data Array for easier access *)
barTemp[0] := RX_PACKET.barData[3];
barTemp[1] := RX_PACKET.barData[2];
barTemp[2] := RX_PACKET.barData[1];
barTemp[3] := RX_PACKET.barData[0];


ptrREAL := ADR(barTemp[0]);

Üdv!

Ezek szerint kiderült, hogy a C18-as fordító is IEEE-t használ.

Amit biztosan tudok saját tapasztalatból, hogy IEEE-t használ:

- Codesys alapú PLC-k V2.xx CodeSys-el
- Windows alatti mingw fordító
- linux alatti gcc (az új verziók biztosan)
- armcc V4.1 (Nuvoton Cortex M0-hoz használom Keil alatt)
- Visual Studio 2005 (gondolom a 2008 is) alatt lévő WindowsCE-re fordító

Szóval ha IEEE a közös nevező, akkor csak annyi dolgod van, hogy áthozd a 4 byte-ot (2 szót), és a másik oldalon figyelj a byte sorrendre, és kész is. FC3-al és FC4-el lehet szavakat olvasni. Az, hogy melyik eszközben melyikkel, az eszközfüggő.

Ha az eszközben IEEE, de a másik oldal nem, akkor is olvasd ki őket, alakítsd IEEE-re, aztán utána hozd IEEE-ről a kívánt formára, ilyen függvények biztosan vannak a neten.

Egyébként Strucc-nak igaza van, a modbus nem írja elő a REAL értékek ábrázolásást, az általa felvetett int-es megoldás is jó.

Imi.

Köszönöm mindenkinek a válaszokat!

Igen, azt tudom, hogy a MODBUS nem ír elő ilyet. Ezért kérdeztem, hogy esetleg van e valami megállapodás az OPC szerverekkel kapcsolatos adatformátumokra.

Próbáltam úgy fogalmazni a kérdéseket, hogy világos legyen, én nem kiolvasni akarok, hanem egy eszközt építek, aminek illeszkednie kéne a SCADA rendszerekhez.

Közben rájöttem, hogy nem jól közelítettem meg a problémát. OPC collectort minden gyártó maga ad a termékéhez, ha ad. Tehát a megoldás, hogy a termékhez OPC Collectort írok. Úgy tűnik ez támogatva van, csak nem tűnik túl egyszerűnek. Bővebben: Link

A másik megoldás az lehet, hogy rábízom a SCADA programozójára, hogy mazsolázza ki az általam leírt protokol szerint átadott értéket.
Végül is sok olyan eszközt ismerek, ahol nem vitték túlzásba az illeszthetőséget, azaz interfészeket kellet beiktatni. Utópia lesz azt hiszem, hogy csak rádugom és működik...

A C18 fordító az IEEE 754 standard-ot követi, két kivétellel:

1. A azámolás során keletkező "subnormal" számokat nullának veszi.
2. A kerekítésnél a C18 a Round to Nearest módot használja.

Bővebben a C18 Lib Help-je ír róla (Floating Point kulcsszóra keress).