Diskuse Elektrika.cz

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í?

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.

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?

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ů).

Výýýborně, děkuji za radu, STRING byl ten problém, ty jsem opravdu měl bez vymezení velikost.
Moc díky!

Děkuji za vysvětlení pana Bydžovského. Uživatelské bloky jsou vnořeny max. do 3. úrovně (MainProgram -> fb části domu -> FB knihovních bloků) a jako TEMP proměnné používám pár BOOL proměnných a UINT pro FOR cykly. Hledat tedy musím v knihovních blocích, kde může být vnoření značné.

Opravdu pomáhá např. funkce pro synchronizaci času či načítání počasí "vysunout ven" do hlavního programu.

Problém asi vidím v tom, že např. FBiTimeProgWee k1 (dost náročný blok z iControl knihovny) volám ve vnořeném bloku, který si pak musí rezervovat všechny TEMP proměnné těchto FB najednou a tím zásobník přeteče. Myslel jsem, že místo zásobníku se rezervuje těsně před voláním FB a uvolňuje hned po ukončení volání FB. Tedy problém přetečení nestává jen když volání přerušuji jiným voláním.

Dobré také je zkontrolovat "Mapu uživatelských registru".
Tam je sloupeček "Velikost" kde je velikost, kterou daná instance FB/funkce potřebuje.

Také záleží jakým způsobem ve svých POU předáváte data v parametrech. Pokud nejsou nárocné struktury/pole předána "odkazem" pak si funkce musí vyhradit místo podle typu pro nakopírování hodnot. Pro ušetření místa je možné použít VAR_IN_OUT, pak se předává jen ukazatel na proměnnou. Tady je pak ale potřeba hlídat/vědět co daná POU dělá, aby nedošlo k nežádoucímu přepisu dat ;-)

Přesně jak píše p. Krhounek, větší data do/z POU je obecně žádoucí nepředávat pomocí VAR_INPUT ani VAR_OUTPUT, nýbrž VAR_IN_OUT !
Jen pozor, že sloupec "Velikost" v "Mapa uživatelských registrů" se týká registrů R tj. zahrnuje VAR_INPUT a VAR_OUTPUT, ale nezahrnuje VAR_TEMP.

Výsledek reálného testu

Zásobník pro VAR_TEMP se tedy, jak popsal p. Bydžovský, skutečně rezervuje jen po dobu volání odpovídající POU. Ale limit 4000+ je o dost nižší než očekávaných 6kB...