...
Podporované typy a verzie zariadení
Konfigurácia komunikačnej linky
Konfigurácia komunikačnej stanice
Konfigurácia meraných bodov
Scheduler v zariadeniach Siemens Desigo
Scheduler v zariadeniach Delta Controls
Informácie o eventoch
Informácie o alarmoch
Poznámka k cachovaniu adries
Poznámka k zariadeniam Delta Controls
Poznámka k zariadeniam E-DDC3.1
Poznámka k zariadeniam Klimasoft MBG-MSTP
Poznámka k zariadeniam Siemens Desigo
Poznámka k iLON 10 Ethernet adaptéru
Poznámka k implementácii BACnet MS/TP
Poznámka k podpore BBMD (BACnet Broadcast Management Devices)
Tell príkazy
Literatúra
Zmeny a úpravy
Revízie dokumentu
...
Resubscribe interval: Čas v sekundách, po uplynutí ktorého sa znovu posiela stanici žiadosť o posielanie zmien meraných bodov. Tento parameter sa týka meraných bodov s Request type rovným SubscribeCOV alebo SubscribeCOVProperty.Kotva resubscribe resubscribe - Max APDU: Maximálna veľkosť správy (APDU=application protocol data unit), ktorú KOM proces posiela. Prednastavené hodnota je:
- 1467 oktetov pre linku TCP/IP-UDP
- 487 oktetov pre linky SerialOverUDP Device Redundant alebo Serial (BACnet MS/TP)
- 55 oktetov pre linku LonWorksiLON 10 Ethernet adaptéra)(obmedzenia sú dané veľkosťami paketov, ktoré sú schopné protokoly siete Ethernet a LonWorks prepraviť, v prípade LonWorks je maximálna hodnota 206 a hodnota 55 je kvôli obmedzeniam
Menenie prednastavenej hodnoty má zmysel kvôli testovaniu a na prispôsobenie sa staniciam, ktoré sú schopné spracovať iba menšie správy. V súčasnosti zmenšenie parametra Max APDU má vplyv iba na veľkosť a množstvo správ ReadPropertyMultiple-Request. Tieto správy slúžia na periodické čítanie hodnoty meraného bodu (viď konfigurácia meraného bodu).
Poznámka: Nastavenie Max APDU nemá vplyv na veľkosť parametra max-APDU-length-accepted v APDU BACnet-Confirmed-Request-PDU, ktorým KOM proces oznamuje partnerovi, akú najväčšiu správu je schopný spracovať. Tento parameter je konfigurovaný pomocou parametra protokolu stanice Segment-Response. - Priorita: priorita správy v BACnet protokole. Existujú 4 priority, prednastavená je Normal, vyššie sú Urgent, CriticalEquipment a LifeSafety.
- Rpt_timer & reply: (iba pre LonWorks): parametre Repeat timer a Retry protokolu LonTalk. Prednastavené hodnoty sú 1 a 1.
- Tx_timer: (iba pre LonWorks): parameter Tx_timer protokolu LonTalk. Prednastavená hodnota je 3.
- Timeout a retry: timeout v milisekundách na potvrdenie správy. Prednastavená hodnota je podľa protokolu BACnet 3000 ms. Po vypršaní timeoutu sa správa posiela opäť a to až retry-krát. Ak nie je prijaté žiadne potvrdenie, zvýši sa počítadlo chýb na stanici.
Poznámka: Pri testovaní zariadenia Siemens PXC64-U (komunikácia cez LonTalk) bolo potrebné nastaviť Retry=8, Timeout=300 (viac opakovaní s kratším timeoutom), v dôsledku toho bolo treba zvýšiť aj hodnoty COM_ERR=10, HARD_ERR=20, aby pri opakovaní posielania správy neprechádzala stanica do chybového stavu.
...
Po kvitovaní alarmu a následnom načítaní zoznamu alarmov a eventov pomocou requestu GetEventInformation bude vidieť, že alarm bol kvitovaný, pretože sa zmení:
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
na
acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
Pokiaľ by bol objekt v stave normal, tak sa v zozname alarmov neobjaví vôbec, ale v tomto príklade bol v stave low-limit, takže ide o aktívny kvitovaný alarm.
Na načítanie zoznamu alarmov, ich výpis do browsera a kvitovanie alarmu je potrebné napísať obslužné skripty na parsovanie textovej hodnoty requestu GetEventInformation a skladanie textovej hodnoty pre AcknowledgeAlarm.
Pozn: v konkrétnom prípade pri potvrdzovaní alarmu vyžadovalo zariadenie DESIGO PXC 100E.D, aby v rámci dátumu bol zadaný aj deň v týždni (napr. D8.6.2020.1 pre pondelok). Hodnota 255 (unspecified) dňa v týždni, ktorá sa posiela, keď deň nie je zadaný, zariadeniu pri potvrdzovaní alarmu nevyhovovala.
| Kotva | ||||
|---|---|---|---|---|
|
...
Pri použití iLON 10 Ethernet adaptéra na komunikáciu si treba uvedomiť, že komunikačný procesor tohto zariadenia (Neuron 3120) má prednastavené pomerne krátke buffre (network buffer je 66 bajtov), preto nebude prijímať dlhšie pakety. Prejaví sa to vo webovom rozhraní iLON 10, kde bude v záložke Status narastať číslo Missed Messages pri pokuse čítať hodnotu (napr. vždy po uložení meraného bodu, pokiaľ má zaškrtnuté Subscribe/read). Pri testovaní sa tento problém prejavil, keď časový plán schedulera obsahoval viac ako 4 dvojice čas, hodnota. Pri štyroch hodnotách bola celková dĺžka prijatej LON správy 63 bajtov, po pridaní ďalšej dvojice cez terminál PXM20 sa už časový plán načítať nepodarilo.
Pozor! Pomocou utility Nodutil Nodeutil je možné zväčšiť veľkosť prijímaného paketu zväčšením network buffra a aplikačného buffra, ale rovnako dobre je možné nastavením nevhodných hodnôt zariadenie iLON 10 zničiť (Neuron 3120 prestal komunikovať s užívateľským procesorom).
Ak sa rozhodnete prestaviť veľkosť buffrov, postačí zmeniť sieťové a aplikačné buffre z 66 bajtov na 88 bajtov (a zredukovať počty buffrov), pretože KOM proces v svojich paketoch oznamuje, že je schopný prijať 50-bajtovú ASDU (+ 3 bajty hlavička BACnet + 16 bajtov hlavička LON)
Adaptér PCLTA-10 ISA (postavený na komunikačnom čipe Neuron 3150) mal dostatočne dlhé buffre (255 bajtov).
Po zakúpení nového zariadenia iLON 10 bola úspešná konfigurácia vykonaná s nasledovnými parametrami:
...