Poslední příspěvky

[hardwarové hodiny]

Základním prvkem udržujícím platný čas v centrále jsou hardwarové hodiny, tzv. RTC. Toto zařízení pracuje nepřetržitě, jeho provoz zajišťuje "knoflíková" baterie. V RTC je uchováván koordinovaný světový čas (UTC), což je prakticky čas platný na nultém poledníku Země (GMT). Při komunikaci s uživatelem (zobrazování nebo nastavování času) ale systém centrály přepočítává tento čas podle nastavené uživatelské časové zóny.

V centrále jsou připravené časové zóny dvě: středoevropský čas (SEČ, bez letního posouvání) a čas "ČR" (středoevropský čas, který automaticky přechází na letní čas a zpět). Je možné přidat časovou zónu jinou. Soubory s definicí připravených zón jsou /etc/localtime_SEC a /etc/localtime_CR, platná je ta, na kterou odkazuje symlink /etc/localtime, přednastavená je zóna ČR (s přechodem na letní čas). Platnou časovou zónu používají i časové moduly FREDa.

Má-li centrála funkční připojení do internetu, udržuje si přesný čas sama pomocí protokolu NTP a časových serverů. Vybrané časové servery (a další nastavení NTP) jsou v souboru /etc/ntp.conf.

Nemá-li centrála přístup k časovému serveru, musí správný čas nastavovat správce centrály. Aktuální čas a datum centrály se zjistí příkazem

Kód:

date

. Centrála odpoví výpisem typu

Thu Jan 16 10:11:53 CET 2014

. Nový čas a datum se nastaví příkazem "date MMDDhhmmRRRR", např. "10:30 hodin 16. ledna 2014" se zadá

Kód:

date 011610302014

. Tento nový čas se ale neukládá hned i do hardwarových hodin, uloží se tam až během několika minut. Bude-li centrála po zadání nového času aspoň 1/4 hodiny zapnutá, přepíše si nový čas do hardwarových hodin sama. Jinak je jistější ho tam přepsat příkazem

Kód:

hwclock -u -w

.

Poznámka pro zkoušení funkčnosti NTP:
Podle dostupných informací neopravuje démon NTP za běhu časové chyby větší, než 1000 vteřin, protože časové skoky sem-tam jsou pro mnoho služeb nepřípustné. NTP je ale teď nastaven tak, aby velký časový rozdíl (časový skok) opravil alespoň při svém startu (tzn. i při startu celé centrály). Menší chyby opravuje démon NTP změnou rychlosti systémového časovače, kterou se čas postupně zpřesňuje. Ta změna rychlosti opraví 1 vteřinu chyby za 2000 vteřin provozu. Nečekejte tedy žádné časové kotrmelce.

Poznámka o udržování času bez přístupu na internet:
Centrála, která nemá přístup na internet, si nemůže průběžně korigovat čas podle serveru NTP. V souvislosti s tím vznikají problémy s udržováním přesného času:

• Centrála už byla nějakou dobu (několik hodin) k internetu připojena:
  Je-li centrála dostatečně dlouho připojena k serverům NTP, uloží si démon NTP aktuální korekční hodnotu času do souboru a použije ji po příštím startu systému. To je za normálních okolností dobře, protože systém ihned po startu správným směrem dorovnává čas. V centrále to ale může vadit. Nově zakoupená centrála pravděpodobně zcela přesně nastavené hodiny nemá. Uživatel ji pak třeba nejdřív doma (s přístupem k internetu) nějakou dobu testuje, zkouší projekt apod. a démon NTP si mezitím uloží potřebu korekce (počáteční) odchylky času. Pak uživatel přemístí centrálu mimo přístup k internetu. Od té chvíle démon NTP nemá možnost opravit své nastavení, stále proto (oprávněně v dobré víře) používá uloženou velkou počáteční korekci a ta vyvolává poměrně velký nežádoucí posun času.
• Systém za provozu používá softwarově udržovaný čas:
  Při běžné práci s časem není dobré používat hardwarové hodiny. Operační systém si tedy udržuje čas softwarově. Ovšem dlouhodobá přesnost softwarových hodin bývá horší, než hodin hardwarových, po dlouhé době provozu může být nastřádaná odchylka dost veliká.

Ve snaze o co nejlepší přesnost času i v centrálách bez přístupu k internetu je (ve verzích od dubna 2017) při instalaci systému změřen programem adjtimex rozdíl softwarových a hardwarových hodin a příslušně se nastavují časové korekce sw hodin. Také je při každém startu centrály mazán korekční záznam démona NTP.

[X-CTU]

Řešením je konfigurace vysílacích modulů (XBee) pomocí SW X-CTU od firmy digi.com. SW je mimo jiné ke stažení na našich stánkách.

Všechny 4 piggy PWLC-10/868 je potřeba nakonfigurovat tak, aby komunikovaly pouze s jedním "protikusem", a to se dělá nastavení výrobního čísla XBee modulů do položky Destination Address.

Piggy PWLC-10/868 umístěte do nějakého sériového převodníku, který umožnuje plný duplex (např. SLC-21 připojený k PC přes USB kabel). Spusťte program X-CTU.

Na první záložce PC Settings je potřeba vybrat správný COM port a parametry připojení (rychlost atd.). Ověřit správnost nastavení lze tlačítkem Test / Query. Při správném nastavení dostaneme dialog s informacemi o XBee modulu, mezi kterými je výrobní číslo, které budeme následně potřebovat.

Tímto způsobem zjistíte výrobní čísla všech 4 piggy resp. XBee modulů.

Následně pokračujte v konfiguraci modulů na záložce Modem Configuration, kde je nejprve nutné vyčíst stávající nastavení stiskem tlačítka Read.

V zobrazené konfiguraci editujte nastaveni Destination Address (parametry DH - Destination Address High a DL - Destination Address Low), do kterých zapište číslo modulu, se kterým budete tento právě konfigurovaný komunikovat.

Posledních 8 znaků z výrobního čísla se zapisuje do DL a zbylé znaky se zapisují do DH. Pokud bude například výrobní číslo XBee modulu:
13A20040A27388

tak do DL zapíšete:
40A27388

a do DH:
13A200


Konfiguraci dokončete jejím zápisem do modulu XBee pomocí tlačítka Write.

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

Máme od Vás 4 převodníky SLC-41 s piggy PWLC-10/868Mhz a realizujeme tím spojení na 2 vzdálené stanice v různém směru z jednoho bodu, tj. v tomto jednom bodě jsou 2 převodníky SLC-41 + piggy + směrová anténa Yagi. Problém je v tom, že jsou oba převodníky připojené na jednu linku RS-485 a odpověď od vzdálené stanice zachytí obě antény, takže začnou do linky oba převodníky vysílat. Jde to nějak řešit?


Dotaz zaslaný mailem (viz výzva).

[GetReadValue]

Dobrý den,
v případě, že chcete zjišťovat nejenom aktuální stavy, ale i hodnotu čítače, tak je lepší načítat celý blok dat najednou a následně si z toho přes funkci GetReadData dostávat jednotlivé hodnoty. Takže příkaz na čtení by vypadal nějak takto (čteme místo 2 bajtů celých 36 bajtů):

Kód:

x = epsnet.Read(3, 0, 36);

následuje opět v bloku try přetypování na nData, kde zase jako předtím máme v nData[0] a nData[1] aktuální stavy jednotlivých vstupů. A nyní získáme hodnoty čítačů (jak jsem psal přes GetReadValue nebo to jde přes třídu BitConverter z C#):

(popis funkce GetReadValue z rozhraní IEpsnet je v nápovědě)

Kód:

ushort citac0 = epsnet.GetReadValue(4, 18);
ushort citac1 = epsnet.GetReadValue(6, 18);
ushort citac2 = epsnet.GetReadValue(8, 18);
ushort citac3 = epsnet.GetReadValue(10, 18);
ushort citac4 = epsnet.GetReadValue(12, 18);
// atd.

Kód:

// nebo přes BitConverter
ushort citac0 = BitConverter.ToUInt16(nData, 4);
ushort citac1 = BitConverter.ToUInt16(nData, 6);
ushort citac2 = BitConverter.ToUInt16(nData, 8);
ushort citac3 = BitConverter.ToUInt16(nData, 10);
ushort citac4 = BitConverter.ToUInt16(nData, 12);
// atd.

A jak jste asi správně pochopil, čísla 4, 6, 8, 10, 12, ... jsou offsety z tabulky již zmíněného PDF manuálu (strana 7). Číslo 18 u GetReadValue znamená typ (18 je typ VT_UI2 - 2 bajty jako neznaménkové celé číslo) - více v nápovědě IEpsnet.

Dobrý den,
děkuji za Vasí odpoved. Podle Vasich rad zjistim jestli je stav aktivni ci ne. Ale potreboval bych vedet jakym zpusobem hodnotu daneho citace na stavu nactu/zaznamenam. Dale mi neni presne jasna funkce offsetu. jak zjistime hodnoty citacu (jak je vymaskuji).


Dotaz zaslaný mailem (viz výzva).

[Driver.Epsnet]

Dobrý den,
jednotky SBI-12 komunikují protokolem Epsnet (případně Modbus - dle nastavení). Budu předpokládat, že máte nastavený protokol Epsnet.

Na této stránce je ke stažení Driver.Epsnet (fred-driver-epsnet.zip). Po jeho nainstalování dostanete nejenom testovací nástroj na ověření funkce komunikace (spuštění aplikace VP.RemoteDriver.exe, které je součástí instalace), ale také rozhraní IEpsnet, které umožňuje snadné používání protokolu Epsnet bez nutnosti jeho vlastní implementace.

Po nainstalování otevřete Váš projekt v C# a přidejte referenci na COM objekt - ve Visual Studio 2008 je to hlavním menu Project -> Add Reference.... V zobrazeném dialogu volte záložku COM a na ní vyberte Elsaco Epsnet 2.0 Type Library (viz přiložený obrázek reference-epsnet.png).

Nyní můžete používat rozhraní IEpsnet ve Vašem projektu. Detailní popis je v nápovědě, která je součástí instalace. Ve zkratce je to takto:

- potřebujete instanci objektu EpsnetLib.Epsnet, tj:

Kód:

// COM objekt - komunikace protokolem Epsnet
EpsnetLib.Epsnet epsnet;

- kterou potřebuje inicializovat:

Kód:

Type oType = Type.GetTypeFromProgID("Elsaco.Driver.Epsnet.2");

if (oType != null)
{
    // vytvoreni instance
    epsnet = (EpsnetLib.Epsnet)Activator.CreateInstance(oType);

    // nastaveni pripojeni (tj. COM, na kterem je pripojeno SBI-12)
    epsnet.SetConnection("serialPort:COM5/38400/8/2");

    // nastaveni adresy ciloveho zarizeni (adresy SBI-12)
    epsnet.SetCurrentStationAddress(1);               
}

- a pak už jenom čtení hodnot, dle manuálu k SBI-12 na straně 7, jsou nefiltrované stavy vstupů na prvních 2 bajtech v bloku 2 nebo 3 (to je jedno) od offsetu 0, tj. budeme tedy číst z bloku 3 a offsetu 0 pouze 2 bajty:

Kód:

object x;
// zkus nacist data
x = epsnet.Read(3, 0, 2);

// pretypuj vysledek na pole dat
try
{
    // nactena data uloz do pole (cteni z bloku 3, offset 0, delka 2)
    byte[] nData = (byte[])x;

    // ... dalsi zpracovani
}
catch
{
    // chyba (napr. chyba komunikace)
}

- zpracovaní hodnot ... po načtení dat a přetypování na datový typ byte máme v poli nData stavy všech vstupů. V nData[0] je prvních 8 vstupů, v nData[1] je druhých 8 vstupů. Stav vstupu je vždy jako jeden bit, tj. pro zjištění stavu jednotlivých vstupů je potřeba použít bitové operace, a to nejlépe logický součin:

Kód:

if ((nData[0] & 0x01) == 0x01) {
    // 1. vstup je aktivni
}
else {
    // 1. vstup neni aktivni
}

if ((nData[0] & 0x02) == 0x02) {
    // 2. vstup je aktivni
}
else {
    // 2. vstup neni aktivni
}

if ((nData[0] & 0x04) == 0x04) {
    // 3. vstup je aktivni
}
else {
    // 3. vstup neni aktivni
}

// atd...

if ((nData[0] & 0x40) == 0x40) {
    // 7. vstup je aktivni
}
else {
    // 7. vstup neni aktivni
}


if ((nData[0] & 0x80) == 0x80) {
    // 8. vstup je aktivni
}
else {
    // 8. vstup neni aktivni
}

a analogicky pro druhou osmici

Kód:

if ((nData[1] & 0x01) == 0x01) {
    // 9. vstup je aktivni
}
else {
    // 9. vstup neni aktivni
}

// ...atd.

Pokud by jste chtěl s jednotkou komunikovat protokolem Modbus, pak je postup stejný, jen je potřeba nainstalovat místo IEpsnet rozhraní IModbus.´

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

Dobrý den,
mám od Vás zakoupenou sběrnici SBI-12 se 16 logickými vstupy. Mám program vytvořený v C#. Potřebuji poradit. Existuje globální funkce, která přečte všechny logické vstupy najednou? Jde mi o načítání stavů.


Dotaz zaslaný mailem (viz výzva).

[Nastavení VirtualBoxu]

FRED a jeho ovladače se přímo v Linuxu provozovat nedají, použitelné nejsou ani ve wine. Přesto není nutné bootovat PC jen kvůli FREDovi do Windows, lze využít Windows ve virtuálním stroji. Vyzkoušeny jsou WIN XP ve VirtualBoxu (balík virtualbox). Trochu obtíží pak vzniká při komunikaci FREDa s centrálami, ale jejich možné řešení je popsáno dále.

Nastavení VirtualBoxu
Ve VirtualBoxu není nutné nastavovat nic zvláštního, kromě režimu sítové karty (Nastavení >> Síť >> Připojit_k). Síťovou kartu je nejlepší provozovat v režimu síťový most (bridge). Virtuální Windows by pak měly mít takovou IP-adresu, aby mohly normálně komunikovat v místní síti.
USB bez dalších doplňků z VirtualBoxu použitelné nejsou, tak mohou rovnou zůstat zakázány.

Centrály s připojením po ethernetu (např. XCOM), kromě CCPU-34
S těmito centrálami se kounikuje úplně stejně, jako z PC s Windows. V ovladači FREDa se jen nastaví jejich IP-adresa.

Centrály s připojením po USB (např. XCPU)
Centrála se připojí pomocí USB k PC, tím se v Linuxu vytvoří sériové zařízení, např. /dev/ttyUSB0. Je nutné upravit parametry tohoto zařízení následujícím příkazem (z balíku coreutils):

Kód:

stty -F /dev/ttyUSB0 38400 -icrnl -ixon -opost -onlcr -icanon -echo -echoe -crtscts cstopb

Dál se v Linuxu spustí program

Kód:

socat TCP4-LISTEN:1998,fork OPEN:/dev/ttyUSB0

(z balíku socat, testováno s verzí 1.7.1.3), kde 1998 je volitelný port TCP a /dev/ttyUSB0 je aktuálně připojená centrála.
Ve Windows v ovladači FREDa se nenastaví komunikace po USB, ale přes TCP (adresa Linuxu a port jako v programu socat). Ovladač pak vše posílá po TCP do Linuxu a tam to program socat přesměruje do /dev/ttyUSB0. Odpovědi jdou z centrály zpátky přes /dev/ttyUSB0 a TCP do fredovského ovladače ve Windows.

Centrála CCPU-34
Zdálo by se, že CCPU-34, vzhledem ke svému připojení ethernetem, nebude mít s komunikací problém. Komplikace ale nastávají kvůli nutnosti překladu fredovského projektu v linuxovém prostředí. Z důvodu jednoduchosti ponecháváme pro překlad i v linuxovém PC virtuální Linux.
Pro virtuální Linux lze opět využít VirtualBox (se síťovou kartou v režimu most a vhodnou IP-adresou), virtuální disky se použijí z windowsového virtuálního Linuxu. Virtuální Linux se musí provozovat v hlavním (hostitelském) Linuxu, ve virtuálním stroji (virtuální Windows) nelze vytvořit vnořený virtuální stroj.
Ve windowsovém PC s virtuálním Linuxem zpřístupňuje VirtualBox prostřednictvím roury (pipe) konzoli virtuálního Linuxu, na tuto rouru (linuxovou konzoli) se pak připojuje fredovský ovladač. Ovšem v linuxovém PC se dvěma virtuálními stroji (s Windows a s překládacím Linuxem) se tento přístup nepodařilo zprovoznit, proto je nutné spojení mezi virtuálními stroji vytvořit jinak, např. dále popsaným způsobem.
Začne se spuštěním obou virtuálních strojů. Pak se v hostitelském Linuxu spustí příkaz ve tvaru

Kód:

socat TCP4-LISTEN:7789 EXEC:'ssh fred@192.168.222.123',pty

, kde 7789 je volitelný otevřený port pro navázaní spojení z Windows a 192.168.222.123 je IP-adresa virtuálního Linuxu.
Pak se ve virtuálních Windows spustí program TCPPipeServer.exe ipadr ipport (program je v příloze nebo ke stažení na elsaco.cz), kde parametr ipadr je IP-adresa hostitelského Linuxu a ipport je otevřený IP-port programem socat, např.

Kód:

TCPPipeServer.exe 192.168.222.24 7789

. V tuto chvíli se vytváří přes hostitelský Linux spojení do virtuálního Linuxu, proto si socat v hostitelském Linuxu vyžádá heslo (uživatele "fred" virtuálního Linuxu). Heslo je "fred" (bez uvozovek). Tím by se mělo celé spojení otevřít a fredovský ovladač tak bude moci komunikovat jeho obvyklým způsobem s virtuálním Linuxem:
fredovský ovladač - pipe - TCPPipeServer - socat - konzole virtuálního linuxu přes ssh.
Ještě je ale nutné ve Windows v souboru

c:\Program Files\Common Files\Elsaco\drivers\iMXCPU\Driver.iMXCPU.config

opravit první řádek na

Kód:

<DriverSetting logout="disable">

, protože jinak by fredovský ovladač spojení po každé akci rušil.

Tato sada webových modulů je postavena na HTML, CSS, JavaScript/jQuery a CGI skriptech.


V knihovně je ještě modul WWW Page, který využívá pouze HTML. Jeho použití je vhodné v případě, že je nutnost umožnit přístup i ze zařízení, která nemají podporu JavaScriptu apod. tj. tento modul bude fungovat ve všech prohlížečích s jakýmkoliv nastavením.

[připojené soubory vidí pouze registrovaní uživatelé]

Pro administraci uživatelů je potřeba do projektu vložit modul WWW Admin Ex, který vygeneruje stránku admin.html dostupnou na:

Kód:

http://192.168.222.29/fred/admin.html

Z této stránky lze přidávat nové uživatele (zadáním neexistujícího jména, hesla a úrovně přístupu) nebo měnit heslo a úroveň přístupu stávajícím uživatelům (zadáním existujícího jména a nového hesla a nové úrovně přístupu) nebo uživatele mazat (zadáním existujícího jména a prázdného hesla).

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