Čeština
Nejsem schopen rozchodit funkční blok fbGetJsonAndSetVar, ani když přímo použiji příklad z dokumentace.
Podezřívám nějaký nesoulad dokumentace s verzí knihovny, případně verzí knihovny mezi sebou.
Podle logu komunikace s http serverem úspěšně proběhne, ale parser se nerozeběhne a skončí to na Timeout error.
I když nezadám direktivu OPEN_UP (zkoušel jsem i PUBLIC_API), nebo špatně pojmenuji proměnou, výsledek i chování jsou stejné.
verze :
Mosaic 2023.1.3 (3)
JsonLibEx v 2.0
InternetLib v 6.3
ComLib v 3.8
dokumentace TXV 003 79.01
Ukázka zachyceného logu (zjednodušený testovací soubor stahovaný z mého webu, originální příklad z dokumentace dopadne stejně, jen je ten JSON dlouhý a složitý)
2023-10-11 09:40:32.671903 ---- UNI start ---- F2x CP2000I v2.0.039 (Nov 6 2020 10:44:01)
2023-10-11 09:40:32.672010 Param: SSL client, myIP: 0.0.0.0:0, hisIP: 0.0.0.0:443
2023-10-11 09:40:32.797557 TCP - myIP: 0.0.0.0:0, hisIP: 81.2.195.254:443
2023-10-11 09:40:32.797926 TCP socket opened
2023-10-11 09:40:32.836118 Used interface: ETH1
2023-10-11 09:40:32.836398 TCP connection established
2023-10-11 09:40:33.071372 SSL handshake successful, Version: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256
2023-10-11 09:40:33.153099 SEND 155
GET /jirka/json/ppp.json HTTP/1.0
User-Agent: Foxtrot/2.0 (Tecomat; N; en-US)
Cache-Control: max-age=0
Accept: */*
Host: vory.cz
Connection: close
2023-10-11 09:40:33.218009 RECV 245
HTTP/1.1 200 OK
Date: Wed, 11 Oct 2023 07:40:33 GMT
Server: Apache
Last-Modified: Wed, 11 Oct 2023 07:34:39 GMT
ETag: "940b56b-22-6076bdb1ab7cc"
Accept-Ranges: bytes
Content-Length: 34
Connection: close
Content-Type: application/json
2023-10-11 09:40:33.229861 RECV 34
{"User":{"id": 1, "name": "PPP"}}
2023-10-11 09:40:33.241436 Function: SSL_Client, Call: SSL_connection_closed, ERROR: 0
2023-10-11 09:40:33.256482 SSL connection closed
2023-10-11 09:40:33.256825 TCP socket closed
2023-10-11 09:41:33.274061 TCP - myIP: 0.0.0.0:0, hisIP: 81.2.195.254:443
2023-10-11 09:41:33.274468 TCP socket opened
2023-10-11 09:41:33.315694 Used interface: ETH1
2023-10-11 09:41:33.315944 TCP connection established
2023-10-11 09:41:33.423464 SSL handshake successful, Version: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256
2023-10-11 09:41:38.390478 Function: SSL_Client, Call: SSL_connection_closed, ERROR: 0
2023-10-11 09:41:38.403127 SSL connection closed
2023-10-11 09:41:38.403532 TCP socket closed
2023-10-11 09:42:32.722575 ---- UNI stop -----
"Pro jistotu" jsem zkusil finkce VarApiToJsonFile() a JsonFileToVarApi(), fungují bez problémů.
Odpovědi 6
Zkuste prosím aktualizovat firmware PLC na poslední verzi 6.1
Následující příklad funguje s poslední verzí firmware korektně:
TYPE
T_USER : STRUCT
id : UINT;
name : STRING;
END_STRUCT;
END_TYPE
VAR_GLOBAL
User {OPEN_UP} : T_USER;
END_VAR
PROGRAM prgMain
VAR
rqGet : BOOL;
GetJsonAndSetVar : fbGetJsonAndSetVar;
result : BOOL;
END_VAR
IF rqGet THEN
GetJsonAndSetVar(exec := rqGet, logSizeKB := 20, pageUrl := 'http://vory.cz/jirka/json/ppp.json', varName := '');
END_IF;
IF GetJsonAndSetVar.done OR GetJsonAndSetVar.err THEN
rqGet := 0;
result := GetJsonAndSetVar.done;
GetJsonAndSetVar(exec := 0); // priprava na dalsi volani
END_IF;
END_PROGRAM
Děkuji. Problém přetrvával i po update firmware, nicméně doufám, že ten vyřeší nějaké potíže, které jsem měl při otevírání více socketů najednou (při práci s TCP Modbus).
Řešení - nakonec mě napadlo přehodit program do task "FreeWheeling". Celou dobu jsem ho totiž měl jako "SecondOfFour". Od té chvíle funguje.
Nemyslím si, že by to byl časový problém, spíš nějaká sofistikovanější závislost na dalších stavech celého systému.
Každopádně díky za pomoc
Blok je opravdu nutné volat v každém cyklu PLC, jinak nemusí zachytit všechny události od socketu.
Taky jsem před časem řešil podobný problém se stejnou příčinou. Nešla by ta nutnost FreeWheeling zdůraznit v dokumentaci?
Pokud by se to týkalo jednoho konkrétního funkčního bloku, tak by to zřejmě v dokumentaci zmíněné bylo. Toto ale je prinicipiální záležitost. Jakákoli komunikace se nevyřeší během jednoho volání funkčního bloku, vždy je to o tom, že se odešle dotaz a pak se v každém následujícím cyklu kontroluje, zda přišla odpověď. Následně se ta odpověď zpracovává a obvykle navazují další kroky než je operace dokončena a nastaví se příznak Done. Když se funkční blok nebude volat v každém cyklu, tak o odpověď můžete přijít. Protistrana bude vysílat další data, v případě TCP protokolu může zpráva přijít na několikrát a je tedy potřeba ten přijímací buffer obsluhovat, zprávy z něj odebírat a ihned zpracovávat. Tzn. tyto funkční bloky se mohou volat podmíněně, ale podmínka musí zůstat splněná, dokud se celá operace nedokončí.
Věcně rozumím a chápu, že podrobné slovní vysvětlení nemůže být v dokumentaci u každého takového fb.
Ale nějak by to přece v dokumentaci mělo být. Např. jednou na začátku každé knihovny, které se to týká apod.
Tento dotaz je vyřešený.