@cleve
OK, díky, myslel jsem si to, že EN bude ta cesta, ale chtěl jsem se ujistit.
Latest posts made by ladmanj
-
RE: chyba komunikace s Unipi Extension xS51
-
RE: chyba komunikace s Unipi Extension xS51
@cleve said in chyba komunikace s Unipi Extension xS51:
@ladmanj
Dobrý den,
teplý restart je možné provést zavoláním funkce reloadapplication s parametrem flags (příznaky restartu, 1 - cold restart, jinak warm). Funkci je možné přidat pravým tlačítkem nebo zavolat z ST.Omlouvám se, ale není mi jasné jak se ve FBD zavolá ta funkce reloadapplication (nedokumentovaná) tak, aby se restart provedl jen při true boolean proměnné. Kdyby flag 0 byl "žádná akce", 1 "warm restart", 2 "cold restart", tak bych věděl, ale když 1 je cold a vše ostatní je warm restart, tak nějak nevím co dělat.
Chápu že je to míněno tak, že v takovém případě se funkce vůbec nemá volat, ale já nevím jak takovou věc ve fbd nakreslit. Pokud to nepůjde, pokusím se to nadatlovat v ST, ale zatím ho stále neovládám. Dokážu C, C++, python, pascal, assembler pro různé platformy, Verilog, tak se nakonec zvládnu i ST. Zatím mi ale způsobuje nevolnost.
-
RE: chyba komunikace s Unipi Extension xS51
@cleve said in chyba komunikace s Unipi Extension xS51:
Softwarové řešení hw problému není snadné. Můžete zkusit detekovat chybu linky pomocí její proměnné
commerror
a následně zkusit restartovat extension nebo IO desku Neurona pomocí proměnnýchreboot
.V tom máte jistě pravdu. Napájení i celkové zapojení je provedeno pečlivě. Nicméně chybu nelze vyloučit v žádném případě.
Komunikace běží na 57600 8N1. Sběrnice je dlouhá cca 5m, na obou koncích zakončená. Na neuronu je zapnut příslušný DIP switch, na opačném konci je 120R rezistor.Na sběrnici je kromě neurona unipi extension modul a jedno zařízení mé vlastní konstrukce, které interně používá libmodbus.
Použitý kabel je https://www.jablotron.com/cz/produkt/kabel-sbernice-2x20awg-2x24awg-676/
Obě zařízení jsou tímto kabelem také napájená.Potenciálně problematické je, že v mém vlastním modulu je vzduchový kompresorek s kartáčovým stejnosměrným motorem, ale ten je napájen z (analogového) regulátoru proudu a běží se zlomkem jmenovitého proudu a taktéž se nekoná standardní rozběhová proudová špička.
Ano připouštím, že moje zařízení může teoreticky něco ošlivého poslat do sběrnice. Ano připouštím, že moje zařízení se může "rozhodnout", že do sběrnice bude už navěky bez přestání vysílat a pak komunikace zdechne.
Jenže, jak je v takovém případě možné, že pomůže pokaždé teplý restart mervisu?
Nerestartuje se linux ani nic jiného. Nevypíná se napájení sběrnice.Mimochodem: už k tomu opět došlo a to i po updatu firmwaru v neuronu. V extension jsem fw ještě neupdatoval. Z bezpečnostních důvodů to nechci dělat přes ssh na dálku.
Díky za případné další informace.
-
RE: chyba komunikace s Unipi Extension xS51
Díky, vyzkouším uvedené rady. Firmware jsem od nákupu neuronů neupdatoval, tak v tom vidím naději. Ty proměnné k detekci chyby také považuji za dobré nasměrování.
-
RE: chyba komunikace s Unipi Extension xS51
Opravdu pro mě nemáte žádnou odpověď?
Teď jsem zařízení našel ve stejném stavu. Neuron ukazoval v ladění proměnné červeně a neměnné.
Po teplém startu vše běží.
Není možné komunikaci (s Extension xS51) nějak hlídat a vyvolat teplý restart, pokud se zastaví?
Díky
-
chyba komunikace s Unipi Extension xS51
Dobrý den,
Mám Unipi Extension xS51 připojený k Neuron S103 asi pěti metry kabelu.
RS-485 je na obou koncích řádně zakončena.
Na sběrnici je ještě jedno zařízení mojí vlastní konstrukce.
Po čtvrt roce bezproblémového provozu se komunikace zastavila a výstupy zůstaly viset na konstantních hodnotách.
Je mi známo, že extension samotný má v dokumentaci uvedenu nějakou watchdog funkci, ale pro tentokrát bych rád řešil stranu kontroléru.Jsem od instalace daleko, ale když jsem po několika dnech zaznamenal, že se děje něco divného, Neuron jsem restartoval a vše se plně rozběhlo.
Lze nějak hlídat komunikaci/obnovování vstupů a v případě problému to nějak reinicializovat, nebo komplet restartovat automaticky?
Děkuji
-
RE: načtení času v DT (unix sekundy od 1.1.1970) z modbus páru registrů
Díky po drobné úpravě to funguje:
Stejně si myslím, že je škoda, že se nedá z modbusu rovnou načíst správně, ale to už "přežiju".
JL
-
RE: načtení času v DT (unix sekundy od 1.1.1970) z modbus páru registrů
@zdenek_rusek
Dobrý den,
Bohužel ani jeden z navrhovaných bloků neposkytuje to co je třeba.- B98 - očekává vstup DT a ne UDINT (já mám UDINT načtený z modbusu kde je počet sekund od 1.1.1970)
=> kompilace končí neúspěchem - B100 - nemám datum v komponentách jako rok, měsíc, den, ..., ale mám počet sekund od roku 1970, pokud to vyplním takto => kompilace je úspěšná, ale výsledky jsou vadné.
Chápu-li definici datového typu DT správně, je to právě UNIX čas, tedy počet sekund od 1.1.1970, ale chybí mi legální "cast" mezi UDINT a DT.
Nejlepší by bylo, kdyby se v definici modbus registrů dalo nastavit, že data jsou typu DT a hotovo. Problém by byl vyřešem. Ale tato možnost v IDE není, a když to změním ruční editací XML souboru (definice_modbus.hw) a naimportuju, tak to tam sice ve formátu DT je, ale data jsou chybná.
Obávám se že to bude chtít bugfix od energocentra ... :-(
S pozdravem
Jakub Ladman - B98 - očekává vstup DT a ne UDINT (já mám UDINT načtený z modbusu kde je počet sekund od 1.1.1970)
-
načtení času v DT (unix sekundy od 1.1.1970) z modbus páru registrů
Dobrý den
Dokážete mi poradit jak načíst 32 bitů, které nesou datum a čas v unix formátu, který je podle dokumentace kompatibilní s typem DT z modbus registrů?Mám dva modbus registry, které dohromady tvoří 32 bitů. Dokážu je načíst jako UDINT, nebo DWORD, ale transformaci na DT nenacházím.
Nenacházím ani knihovní blok UDINT_TO_DT, nebo DWORD_TO_DT.
Vůbec už nevím co s tím dělat.Děkuji za pomoc
-
RE: řízení třícestného ventilu podlahového topení s feedforwardem
Dobrý den,
není to přesně to, co jsem hledal, ale zaujalo mě to. Jen mi není jasné co přesně se tam děje.
Pokud je měřená venkovní teplota menší, než uživatelem nebo správcem systému zadaná hodnota reqTemp_HC1, pak se použije tato hodnota místo údaje z vnějšího čidla?Předpokládám, že by se spíš mělo být možné použít jinou křivku a tu výjimku nedělat. Nicméně jistou inspirací to je.
Předběžně jsem se rozhodl začít se standardním PID/PI kontrolérem.
Ona se ta teplota vstupní vody nebude měnit tak rychle aby si to bez kompenzace neporadilo.Co se týká složitějšího řešení pro možné nasazení v budoucnosti, začal jsem si hrát s implementací přenosové funkce pomocí StateSpace v diskrétním čase (v Z-doméně) v jazyce ST.
Něco už to dělá, ale k nasazení v reálu to má hodně daleko.