Jaké jsou možné příčiny chyby 9380 u Foxtrot CP-1001?
Jaroslav Kutílek:
Jaké jsou možné příčiny chyby 9380?
93 80 pcpcpc SP cannot be set - system stack range exceeded
Platforma:
TECO FOXTROT CP-1001
Používám knihovny Lightslib_V16 pro ovládání světel, iControlLib_V2 5 pro ovládání zásuvek a detektorů, WeatherLib_V19 pro načítání počasí, InternetLib_V5 2 pro synchronizaci času přes NTP a EnergyLib_V24 pro čítání energií.
Číslo řádku chyby ukazoval na mé bloky, které obsahovali čisté volání knihovních bloků v CFC. Svůj program jsem musel drasticky zmenšit, abych dokázal dát PLC do RUNu. Nyní jsem ve stavu, že při přidání dalšího volání FB, jde PLC do chyby 9380. Číslo řádku ukazuje na knihovní bloky, podle toho, které volání vložím (světla, zásuvky, načítání počasí,...) .
Funkční program nyní obsahuje cca - 34 světel, 9 topných okruhů, 30 PIR detektorů. Jsem opravdu na CP-1001 příliš náročný a systémové prostředky už nedostačují pro další volání?
Milan Bydžovský:
Chyba 93 80 pcpcpc souvisí s prostorem na proměnné VAR_TEMP.
Systém disponuje 6kB paměti na tyto proměnné. Při volání bloku s VAR_TEMP se po dobu jeho vykonávaní z této paměti odebere velikost těchto proměnných. Pokud blok volá uvnitř další blok, který má VAR_TEMP odebere se další paměť.
Jinými slovy, při vnořeném volání se velikost VAR_TEMP sčítá. Jak se bloky ukončují paměť se opět uvolňuje.
Řešením problému, je omezení velikosti VAR_TEMP, využitím standardních VAR (Při převodu je třeba brát ohled na to, že VAR ve funkčních blocích a programech nejsou inicializovány při každém volání, ale drží hodnotu z volání předchozího. U funkcí je jejich chování shodné.)
Druhou možností je omezení hloubky vnoření volání.
34 světel, 9 topných okruhů, 30 PIR detektorů je velikost úlohy, kterou by systém měl bez problému zvládnout.
Jan Novotný2:
Zaujala mě věta "Druhou možností je omezení hloubky vnoření volání".
Mám totiž také problém s pamětí R registrů.
Vytvořil jsem si obsáhlý funkční blok, který ve finále zabírá velké množství paměti, a když ho použiji 3, tak jsem v problémech.
FB je postaven tak že je spousta funkcí za sebou, tak aby se plynule došlo k výsledku (od vstupní proměnné až k výstupní proměnné je to cca 50-60 fukncí.
Je toto tedy špatně kkdyž jsou za sebou? Měl jsem právě za to, že když vše poskládám plynule za sebe, použiju minimum proměnných a je to pro hospodárnost s pamětí lepší..
Mám tedy udělat vstupní proměnnou, funkci, výstupní proměnnou. A tu výstupní pak zase použít jako vstupní pro další funkci?? Je toto myšleno tou hloubkou vnočení? Nevadí tedy když tam budu mít 50 proměnných, ale jen jedno úrovňové funkce?
Milan Bydžovský:
Citace: Jan Novotný2 21.01.2020, 12:20
Zaujala mě věta "Druhou možností je omezení hloubky vnoření volání".
Mám totiž také problém s pamětí R registrů.
...
Výše zmíněný problém se netýká registrů R, ale dočasných proměnných VAR_TEMP, které se vytvářejí při volání bloku (blokem je myšlena programová organizační jednotka, tedy funkce nebo funkční blok) a ruší se když se blok ukončí. VAR_TEMP proměnné nečerpají R registry.
Pokud se vrátím k hloubce vnoření, ta se zvyšuje pouze pokud volaná funkce (nebo funkční blok) volá ve svém těle jinou funkci (nebo funkční blok). Vizuálně je hloubka vnoření vidět při ladění ve stromu v okně 'Kontext ladění' (záložka se zeleným broukem).
Pokud máte vysokou spotřebu registrů R, je nutné zkontrolovat zda programy a funkční bloky neobsahují zbytečné proměnné (nepoužité proměnné jsou hlášeny při překladu), zda není možné některé proměnné použít vícekrát nebo přesunou z VAR do VAR_TEMP (v případě dočasných proměnných) a zda se nepoužívají zbytečně dlouhé proměnné STRING (u proměnné typu STRING je možné nastavit délku, pokud není uvedena použije se 80 znaků).
Jan Novotný2:
Výýýborně, (poklona) za radu, STRING byl ten problém, ty jsem opravdu měl bez vymezení velikost.
Moc díky!
Navigace
[0] Index zpráv
[#] Další strana