Nahrál jsem tam nový FW z 6.6.2023 a ono se to spravilo
. Čas z NTP serveru se synchronizuje hned po startu a zatím se neprojevuje ani žádné zpomalování.
Ano, obě tyto věci se v novém FW řešili.
]]>Jak provedu RSTD?
Každý modul SDS má na sobě (na základní desce) jumper, označený jako RSTD,
specificky pro BIG: stačí jej zkratovat na více než 10 sec a pak odpojit, a provede se reset akce
(ostatní SDS to mají jinak, musí se zkratovat ve vypnutém stavu zařízení, nechat a zapnout zařízení, a pak jumper po chvíli odpojit).
Tohle se má dělat ve výrobě, ale zdá se, že pár kusů odešlo z testu bez provedení úvodního resetu.
Proto doporučím, bez ohledu na stav v jakém to z výroby přijde, udělat si vždy poprvé ten RSTD, u každého kusu.
Nahrál jsem tam nový FW z 6.6.2023 a ono se to spravilo
Ano, obě tyto věci se v novém FW řešili.
]]>Zkuste provést RSTD. Někdy jsem zachytil moduly SDS, které měli podobné chování, a provedení RSTD (= zapsání tovární konfigrace do DF (NVM) paměti) to vyřešilo. Problém tam byl v tom, že tam nebyla některá z důležitých položek (nikdy od výroby) nastavena, a zařízení na to takto reagovalo. Nikdy se mi to nedostalo do ruky abych si to vyzkoušel u sebe, ale dle informací alespoň vím, že jedno provedení RSTD to plně vyřešilo.
Nahrál jsem tam nový FW z 6.6.2023 a ono se to spravilo . Čas z NTP serveru se synchronizuje hned po startu a zatím se neprojevuje ani žádné zpomalování. Nevím, zda je možné, že se nějak nepovedla předchozí aktualizace nebo byl soubor FW poškozený nebo se něco nenastavilo, v každém případě to "zatím" vypadá dobře. Nicméně, pokud bude zase něco zlobit, zkusím ještě vaši radu, V každém případě dobrá zkušenost pro příště.
Index 138 funguje. Jde mi ale stále o to zařízení, na kterém přestala fungovat synchronizace s NTP. Je to správně, když je hodnota na indexu 44 nenulová a čas na indexu 139 nemá správnou hodnotu? Mám ještě testovat index 138?
Na to se podívám a odpovím.
Jinak zařízení projevuje i jiné velice podivné změny chování (jakoby se skutečné ovládání výstupů zpožďovalo oproti programu), uvažujeme vyměnit celou jednotku. Pokud zjistíme nějaké definovatelné problémy, ještě napíšu.
Zkuste provést RSTD. Někdy jsem zachytil moduly SDS, které měli podobné chování, a provedení RSTD (= zapsání tovární konfigrace do DF (NVM) paměti) to vyřešilo. Problém tam byl v tom, že tam nebyla některá z důležitých položek (nikdy od výroby) nastavena, a zařízení na to takto reagovalo. Nikdy se mi to nedostalo do ruky abych si to vyzkoušel u sebe, ale dle informací alespoň vím, že jedno provedení RSTD to plně vyřešilo.
]]>Jinak zařízení projevuje i jiné velice podivné změny chování (jakoby se skutečné ovládání výstupů zpožďovalo oproti programu), uvažujeme vyměnit celou jednotku. Pokud zjistíme nějaké definovatelné problémy, ještě napíšu.
]]>Lze to sledovat i na webové administraci - stránka "Log".
Hned v úvodu je stav RTC (aktualizováno pro každé spuštění/reboot SDS).
Typicky je zde "BL: RTC-OK-empty" - a to v případě, kdy došlo ke studenému startu zařízení SDS, které nemá zálohované své vlastní interní RTC.
Ruční nastavení času přes funkci SDS_set_RTC() pak zapíše čas do interního RTC v SDS. Pokud dojde k restartu SDS (bez výpadku napájení), hodnota času v interním RTC je zachována,
a na stránce "Log" je následně napsáno "BL: RTC-OK+time".
Hodnota v indexu 138 je pak na 1 (což je správně, protože interní RTC má nastavenu hodnotu času).
Hodnota na indexu 44 je v obou případech nenulová. Zpráva "System time synchronized from NTP server" se vypíše poprvé, co se tato hodnota změní z nuly na něco. Podaařilo se nám navodit i situaci, kdy čas systému byl stále špatně, ale na stránkách sdsweb byl status OK (čas 1.1.2020 xx:xx bez DST) - nebyl zde text ONLY RTC. SDS BIG2 s interním zálohovaným RTC zatím nepoužíváme. Jako by se synchronizace s NTP provedla, ale nezapsala do vnitřního RTC. Zkoušeli jsme různé varianty, se zasunutým i vysunutým RTC s jeho obsluhou programem i bez obsluhy (zakomentářované).
]]>Pozn. Stav NTP je k dispozici pod indexem 44, jaké jsou tam hodnoty v jednotlivých situacích ?
Ve SDS je (při rozpadech na lokální čas) rok brán vždy od čísla 2000, takže pokud je interní RTC prázdné, tak v něm bude takto podobný datum (samozřejmě źe postupně načítává sekundy atd. od zapnutí zařízení). Do interního RTC se zapíše až buď když se získá čas z NTP serveru, nebo když zavoláte funkci SDS_set_RTC().
Detekovat správný čas - lze i tak, že se program podívá, zda-li má epoch time (UTC) má hodnotu v sekundách větší než 1684411952 (hodnota získána v době psaní tohoto příspěvku). Ovšem není to samozřejmě ideální řešení.
Proto je vhodné si přečíst systémovy index 138, který dává programu informaci, o tom, v jakém stavu bylo interní RTC po zapnutí zařízení SDS - zda-li v něm byl platný čas, nebo zda-li je RTC "prázdné". Pokud máte SDS bez možnosti provozu interního RTC z baterie (při vypnutém napájení), pak si to můžete zjednodušit a předpokládat že po zapnutí vźdy interní RTC platný čas nemá.
]]>Jinak se nám dnes vyskytl jiný problém s NTP, který asi nesouvisí s tím prvním. Oživovali jsme novou jednotku s vlastním I2C RTC. Zařízení evidentně nastaví příznak synchronizace času, ale v systémové proměnné EPOCH_TIME ještě nějakou dobu zůstává stará hodnota. Po vytažení RTC vše funguje, jak má.
S RTC obvodem se komunikuje pouze úplně na začátku programu (vyčtení hodnoty a zápis do system time), pak až po první synchronizaci s NTP serverem (uložení času do RTC - což je nesprávná hodnota). Může to souviset i s tím, že v RTC je na počátku nějaký výchozí čas (1.1.2000?). Pokud je v RTC uložen správný čas, pak z výpisu ani nepoznáme, jestli je to správně.
Přikládám výpis. Čas v logu se bere z epoch_time. Vypadá, že to není náhodné, ale opakovatelné.
S RTC:
01.01.2000 01:00:04 [SYSTEM] System time synchronized from RTC.
01.01.2000 01:00:04 [SYSTEM] Device cold start (0), program version 1.0.0.15
01.01.2000 01:00:12 [SYSTEM] SD Card ready, block size=512
01.01.2000 01:00:12 [SYSTEM] System time synchronized from NTP server.
01.01.2000 01:00:12 [SYSTEM] RTC time synchronized from system.
18.05.2023 12:18:04 [SYSTEM] Resolved reservation server (restapi.inrs.cz) IP adress: 176.98.244.77.Bez RTC:
01.01.2000 01:00:04 [SYSTEM] Cannot synchronize time from RTC.
01.01.2000 01:00:04 [SYSTEM] Device cold start (0), program version 1.0.0.15
01.01.2000 01:00:12 [SYSTEM] SD Card ready, block size=512
18.05.2023 12:21:07 [SYSTEM] System time synchronized from NTP server.
18.05.2023 12:21:07 [SYSTEM] RTC time synchronized from system.
18.05.2023 12:21:23 [SYSTEM] Resolved reservation server (restapi.inrs.cz) IP adress: 176.98.244.77.Napadá vás, čím by to mohlo být?
]]>Synchronizaci skutečně provádí interní firmware v SDS, a je tam implementována jediná možná podmínka, která by tomu mohla zabránit - a to že se (záměrně) IP adresa pro NTP server nastaví (v administraci SDS) na 127.0.0.1
Pokud to tak v daném SDS není, tak musí (do 15 sec od prvního získání LAN spojení, a pak periodicky) SDS posílat NTP dotazy.
To by právě potvrdil ten záchyt komunikace (pokud by tam přesto tyto pakety z SDS nebyly, tak by pak byla chyba v SDS).
Text "rtc only" ukazuje na to, že skutečně SDS dosud nedostalo odpověď z NTP serveru. Proč ji nedostalo, to je ta otázka - jestli proto že se SDS ještě nezeptalo (ale mělo by), nebo pro jiný důvod (a to je potřeba zjistit).
Interní stav NTP serveru by měl jít zjistit i přes některé ze systémových indexů ve FULLC programu, třeba by pomohlo i tohle.
]]>