Potřebuji pochopit chování PLC v různých scénářích selhání spojení s TecoRoute.
NA CP-2000 s aktuálním FW jsem ověřil
- Když vypadne síťová komunikace, je timeout 25s, tj. položka .serviceTim struktury TTecoRouteStat se opakovaně dekrementuje od 25s k nule.
- Ale když je příčinou selhání chybné TecoRoute heslo, tj. dojde k 'Account doesn't exist or incorrect PLC name or password', dekrementuje .serviceTim nejprve od 50s, pak od 100s, 200s, 400s atd.
Na jakém limitu se timeouty zastaví?
Platí stejný limit timeoutů i pro CP-1006 s firmwarem cca z roku 2020 (CPU Type: 100 CP1006K 10.9) ?
Pokud jsou ještě další podobné scénáře retry/timeout, bylo by možné je doplnit do dokumentace?
Odpovědi 5
Tady je rozdíl v tom, jestli se PLC nepodařilo připojit nebo jestli ho server odmítnul. Při opakovaném aktivním odmítnutí PLC prodlužuje intervaly, po jejichž uplynutí se snaží znovu připojit. Časovače jsou u systémů CP-10xx a CP-20xx nastaveny odlišně. U CP-10xx se prodlužování intervalů zastaví asi na 17 hodinách, u CP-20xx na 20 hodinách. Jestli to platí stejně pro všechny verze fw zpětně, to si nejsem jist a znamenalo by to delší hledání.
Požadavek na doplnění dokumentace v tomto smyslu jsem předal dál do vývoje SW.
OK, děkuji.
Ještě detail: Protože .serviceTim je typu UINT, měla by max. hodnota být 65535 sekund tj. 18,2 hodiny. Nebo je to složitější a u CP-2xxx je to skutečně cca 20 hodin?
Máte pravdu, v případě dosažení maximalníhu času dojde v .serviceTim k přetečení hodnoty a indikovaný počet sekund neodpovídá skutečnosti dokud čas neklese pod těch 18,2 hodiny.
Prověřím, zda by nebylo možné v nových firmware čas zkrátit, aby indikace v .serviceTim vždy odpovídala skutečnosti
Děkuji. Já žádnou změnu nepožaduji, jen by bylo skutečně dobré chování zdokumentovat. Dotaz možno uzavřít.
Tento dotaz je vyřešený.