Poslední příspěvky

[posílání hodnot]

Pro posílání hodnot z XCOMu do CCPU použijeme modul ModbusEx Tx, který opět umožňuje nastavit veškeré potřebné parametry. Komunikační parametry musíme nastavit stejné. Ve výsledku nastavujeme tyto parametry:

adresa = 1 - adresa jednotky CCPU

comNr = 0 - kanál, přes který bude XCOM-21 komunikovat s CCPU (zaškrtnutý simplexní režim, protože se jedná o RS-485)

Baud = 38400 - komunikační rychlost na hlavním kanále CCPU

Parita = 0 - parita na hlavním kanále (zde žádná)

Offset = 256 - číslo registru, ze kterého se bude číst - skládá se ze dvou částí horní bajt tvoří číslo instance modulu (v případě modulu Comport v projektu pro PL2 je to 1) a z indexu čtené/zapisované části (první výstup má index 0) -> výsledkem je číslo 0x100 hexa, nebo-li 256 dekadicky

Points = 2 - počet položek, které se mají zapisovat - na straně PL2 zapisujeme jednu 4 bajtovou položku, takže musíme zapisovat 2 dvoubajtové položky ModBus (celkem 4 bajty)

Dialog s nastavením parametrů a projekt jsou v příloze.

(připojené soubory vidí pouze registrovaní uživatelé)

Není to jak píšete. V podstatě je to součtové hradlo se vstupy Switch1 a Switch2. A je jedno, kterým vstupem dáte povel ke střídání.

Je to tak proto, že většinou řešíte úlohu tak, že vytvoříte signál pro automatické střídání kotlů/čerpadel - ten dáte např. na vstup Switch1.

Pak potřebujete střídat kotle/čerpadla ručně, proto vytvoříte obvody pro ruční střídání a výsledek přivádíte na druhý vstup Switch2.

[STRIDAC]

Umíte mi blíž popsat zmíněné vstupy modulu STRIDAC? V nápovědě je napsáno jenom, že jsou na střídání. Není mi však jasné jestli např. vstup SWITCH1 řadí zařízení v pořadí od 0 do 7 a SWITCH2 od 7 do 0. Nebo je to jinak?

[čtení parametrů]

Projekt do XCOMu nebude o nic složitější. CCPU a XCOM-21 spojíme přes RS-485, tj. na XCOMu použijeme kanál COM0 (RS-422/485). Komunikační parametry jsou dány hlavním kanálem jednotky CCPU.

Pro čtení parametrů z CCPU protokolem ModBus použijeme modul ModbusEx Rx, který nám umožňuje nastavit všechny potřebné parametry. V dialogu jeho parametrů nastavíme tyto hodnoty:

adresa = 1 - adresa jednotky CCPU

comNr = 0 - kanál, přes který bude XCOM-21 komunikovat s CCPU (zaškrtnutý simplexní režim, protože se jedná o RS-485)

Baud = 38400 - komunikační rychlost na hlavním kanále CCPU

Parita = 0 - parita na hlavním kanále (zde žádná)

Offset = 288 - číslo registru, ze kterého se bude číst - skládá se ze dvou částí horní bajt tvoří číslo instance modulu (v případě modulu Comport v projektu pro PL2 je to 1) a z indexu čtené/zapisované části (první vstup má index 32) -> výsledkem je číslo 0x120 hexa nebo-li 288

Points = 6 - počet položek, které se mají číst - u PL2 předáváme tři 4bajtové hodnoty, ale jedna položka v protokolu ModBus má 2 bajty, takže počet přenášených registrů je 6 (celkem 12 bajtů)

Všechny ostatní parametry necháme implicitní. Nastavení dialogu je příloze.

(připojené soubory vidí pouze registrovaní uživatelé)

[modul Comport]

Projekt do CCPU bude mimo "povinných" modulů (Sysmon, Flash, Timdat a CCPU-xx dle dané centrály) obsahovat pouze a jenom modul Comport - komunikaci si ukáže na něm.

Nastavení všech modulů můžeme nechat implicitní a projekt do jednotky můžeme nahrát.

Důležité je pouze znát komunikační parametry pro protokol ModBus slave. Ty jsou stejné jako nastavení hlavního kanálu, které je implicitně COM0, 38400Bd, bez parity. My si nastavíme (buď přes CKDM nebo přes utilitku pro nastavení hlavního kanálu) kanál 1, tj. RS-422/485.

Přenos si ukážeme na 2 floatových hodnotách a jedné celočíselné, které bude přenášet z CCPU do XCOMu a na jedné celočíselné, kterou budeme přenášet z XCOMu do CCPU. Projekt pro PL2 je v příloze příspěvku.

(připojené soubory vidí pouze registrovaní uživatelé)

[Comport]

Podle helpu ke knihovně PL2 (u jednotek CCPU-02, CCPU-03 nebo CCPU-21) lze provozovat komunikovat s jednotkou CCPU zjednodušeným protokolem ModBus, který zapisuje/čte data do modulů Comport a/nebo Screen.

Součástí tohoto vlákna budou projekty pro jednotku CCPU a jednotku XCOM, která bude demonstrovat možnost komunikovat mezi těmito 2 typy jednotek protokolem ModBus (XCOM jako master a CCPU jako slave).

Jednotky propojíme přes RS-485 (tj. např. COM1 na CCPU-02 a COM0 na XCOM-21).

Je možné provozovat jednotku CCPU jako ModBus slave? A jakým způsobem?


Dotaz zákazníka (viz výzva).

[modul CAIO12]

Předpokládejme, že máme centrálu CCPU a k ní připojenou jednotku CAIO-12 s adresou 1 a v pozici AD0 zasunutý domeček EBI-11.

K zjištění změny vstupu X1 postačí v projektu do FREDa modul CAIO12, na jehož příslušném výstupu je sepnutí tohoto vstupu signalizováno jako nenulová analogová hodnota. Změnu na vstupu X0 nelze modulem CAIO12 zjistit.

Pro zjištění změny vstupu X0 i X1 (ze všech pozic AD0 až AD11) se musí použít v projektu modul SDO. V manuálu Komunikační protokoly periferních jednotek (mkomprot.pdf ke stažení na této stránce) si v tabulce OBJECT DICTIONARY – SEZNAM OBJEKTŮ nalezneme Binární vstupy jednotky xAIO-12/PAIO-32, kde se dozvíme, že hodnotu získáme pomocí těchto komunikačních parametrů:

Kód:

index = 6120
subindex = 1
length = 4

Hodnoty jsou v hexadecimálním zápisu, takže do dialogu parametrů modulu SDO je musíme přepočítat (0x6120 = 24864). Vyplněný dialog vidíte na přiloženém obrázku. Nesmíme zapomenout nastavit parametr init na hodnotu 0, aby se hodnota načítala periodicky.

Po překladu a sepnutí vstupu X0 a/nebo X1 se bude načtená hodnota měnit, a tím  i hodnota na labelech za modulem Int_to_Bin (všimněte si zaměněného pořadí X1 a X0).

Přiložený projekt obsahuje oba způsoby.

(připojené soubory vidí pouze registrovaní uživatelé)

[CAIO-12]

Na CCPU-03 mám napojen modul CAIO-12 a v něm zásuvný modul EBI. Jak mám ve FREDovi naprogramovat čtení takového binárního vstupu?

Požadavky se se v tomto ani jiném módu neztrácejí, "pouze" zůstávají ve frontě k vyřízení a jsou neustále "předbíhány" nově příchozími požadavky, které je přeskočí v rámci třídění.

Třídění požadavků se provádí podle čísla bloku a následně podle offsetu, takže po setřídění jsou ve frontě nejprve požadavky z bloku 1, pak z bloku 2, pak z bloku 3 atd. Postupně se tyto požadavky odebírají a komunikují.

V případě řízené komunikace se počká, až se požadavky vyřídí všechny a pak se pokračuje dál. Ovšem například v aplikaci typu data_driven je vyřízený požadavek téměř ihned vrácen k vyřízení ovladači.

Řekněme, že máme požadavky na data z bloku 1 a z bloku 2. Požadavky nejsou ve spojitém bloku, takže na vyčtení dat z bloku 1 potřebujeme například 4 komunikační relace a na vyčtení dat z bloku 2 potřebujeme 3 komunikační relace. Požadavky se setřídí, vyřídí se první relace pro blok 1, data se vrátí CW a pokračuje se druhou relací, pak třetí ... Mezitím CW data zpracuje a vrátí ovladači požadavek data z bloku 1. Ovladač si požadavky setřídí a opět vyřídí požadavek na data z bloku 1. Následně by pokračoval dále, ale CW opět vrátí požadavek na data, která ovladač vykomunikoval druhou relací, takže ovladač opět vyřídí tento požadavek. Výsledkem může být to, že na data z bloku 2 se nikdy nedostane.

V takové případě tedy platí, že je nutné nastavit mód na ITEM. Mód BLOCK na takový typ způsob komunikace není určen.