I am using the network lib v1.35 with Wago Codesys v2.3.9.49 (currently the latest version supported by Wago), and oscat basic lib v333. When building, I get error messages "Cannot pass the result of a IEC-function as string parameter to a C-function". This is related to the use of function CONCAT (2nd parameter) within blocks BASE64_DECODE_STR, BASE64_ENCODE_STR, DNS_DYN, GET_WAN_IP, IP2GEO, MD5_CRAM_AUTH, SYS_LOG, WORLD_WEATHER. And to the use of function LEN (1st parameter) within TN_INPUT_MENU_POPUP.
The error message seems to me to indicate that the result of a string function is directly passed as a parameter to some other function or function block. Just assigning the value to an intermediate variable and passing that instead of a direct function result (technically a pointer to a value rather than the value itself?) might be enough, but may come at the cost of a performance penalty (always a trade off, especially when dealing with strings).
For now I can work around this by excluding most of the blocks of the network lib from build. However, this will limit my options for using more of the network lib in the future. Am I doing something wrong, is there a version incompatibility, can I work around this error by manual tweaking of code?
Edit: one additional question
One of the applications of DLOG_STORE_FILE_CSV for me is to log some error conditions. I use triggered logging for this, rather than continuous. I log at the rising and falling edge of the error condition, so I can also tell from the logs how long an error condition was up. Some kinds of errors can last a long time, logging working fine for this. Some others can last only a fraction of a second, perhaps only one or a few cycles of the PLC program. I.e. typically communication related errors. For these short duration error conditions I only catch one edge, usually the rising edge (errorcondition = true), not the falling edge. So I cannot tell how long the error actually lasted. I see from log files that time (DLOG_DT with format #N:#R:#T:#V) is always rounded to whole seconds. Miliseconds are always zero, perhaps this is related.
Is it possible to obtain higher resolutions of the time, or is a 1 second logging interval the practical limit of logging with these components?