Nachrichten

1

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 14. März 2021, 12:59:10 »

Yes I know the changes are supposed to be minimal. Still the Codesys store also makes mention of bugfixes in the 1.3.5.2 release. That is probably just the renames you mentioned. For completeness and consistency it would be nice to have everything covered. And the English manual with 1.3.5 while being very complete (which is indeed very very much appreciated, don't get me wrong!) still has several fragments in German.

2

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 13. März 2021, 12:05:20 »

There is an update of the Network library (v1.3.5.2) available for download in the Codesys store, very much appreciated. I did notice neither a revision history nor an updated version of the manual were included. Not sure if that package is submitted/maintained by the good people of Oscat over here, or rather by the folks from 3S Software. Either way, it would be appreciated if a revision history and an updated manual could be made available.

I am happy to help out on proof reading/correcting the English version if that would be of help. I read German, just not fluent enough to proof read and correct the original German version.

3

Step 7 / Re: DT_To_STRF

« am: 07. März 2018, 21:51:52 »

For example pass these values:
 - DT#2010-10-22-06:00:00  for parameter DTI
 - 0 for MS (you don't need miliseconds to display a date, month and year)
 - '#H/#D/#B' for FMT (see below for a list of available placeholders)
 - 0 for language (no textual value for days or months, so the language does not matter either)

That should give you the requested result for this DTI value:  '22/10/10'.

Below are the placeholders you can use in the FMT string.

Code: [Auswählen]

#A 4 digit year number (2008)
#B 2-digit year number, eg (08)
#C Month 1-2 digits (1,12)
#D Month 2 digits (1, 12)
#E Month 3 letters (Jan)
#F Months written out (January)
#G Day 1 or 2 digits (1, 31)
#H Day 2-digit (01, 31)
#I Week as a number (1 = Monday, 7 = Sunday)
#J Week 2 letters (Mo)
#K Week written out (Monday)
#L AM or PM in American date formats
#M Hour in 24 hour format 1-2 digits (0, 23)
#N Hour in 24 hour format 2 digits (00, 23)
#O Hours in 12 hours Format 1 - 2 digits (1, 12)
#P Hour in 12 hour format 2 digits (01, 12)
#Q Minutes 1-2 digits (0, 59)
#R Minutes 2 digits (00, 59)
#S Seconds 1-2 digits (0, 59)
#T Seconds 2 digits (00, 59)
#U Milliseconds 1-3 digits (0, 999)
#V Milliseconds 3 digits (000, 999)
#W Day 2 digits but pre-padded with blank (' a' .. '31 ')
#X Month 2 digits but pre- padded with blank (' 1' .. '12 ')
These placeholders will be replaced by the corresponding value as determined by the DTI parameter.

4

Modulentwicklung / Re: DLOG_STORE_FILE_CSV questions

« am: 21. Februar 2018, 22:11:03 »

Just a quick note to confirm that the DLOG_STORE_FILE_CSV block from the 1.3.5 beta version does work very well indeed for my needs. Thanks again peewit for your help, much appreciated.


Deviating slightly from your suggestion in this post, I have set NETWORK_BUFFER_LONG_SIZE to a value of 8191. There is probably a good reason for the original to be 4095 = (2^12)-1, so I made my version 8191 = (2^13)-1.

Code: [Auswählen]

VAR_GLOBAL CONSTANT
   NETWORK_BUFFER_LONG_SIZE : UINT := 8191;

Also, I get plenty of warnings about slightly different types between OSCAT_BASIC and OSCAT_NETWORK. Implicit type conversions and "possible change of sign". From INT to UINT, DINT to UDINT, UINT to INT, INT to UDINT, pointer to BYTE and pointer to DWORD/UDINT, etc.  One of either might need to be adapted for a better fit between the two libraries. Thinks working despite the warnings, but I'm only using a small portion of the network lib at this time.


Last but not least, the released version has documentation translated to English. So far docs for 1.3.5 are German only. That would be just about the only thing missing before release as far as I'm concerned.
Thanks again, Oscatters

5

Codesys 2 / Re: Rasberry Pi DLOG_FILE_CSV_DEMO

« am: 18. Februar 2018, 17:05:21 »

It has been a while since this was asked. For those that may run into this question as well: it worked for me with filename  '/home/pi/testlog_#A#D#H.csv' .
The #A#D#H part would produce a new CSV file every day.

I also tried without a path (so just 'testlog_#A#D#H.csv' for filename), but could not find the log file on the Raspberry filesystem. Don't know what the Raspberry runtime would use for default path. Using a full path as indicated above worked fine for me.

SysTimeRtcGet was used to obtain a date/time stamp in DWORD format. Convert to DT (as required by DLOG_FILE_STORE_CSV) with DWORD_TO_DT.

OSCAT_NETWORK version 1.3.5 (with NETWORK_BUFFER_LONG_SIZE = 8191, and references to namespace OSCAT_BASIC added as proposed by annD, thanks for that).

6

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 09. Februar 2018, 15:52:25 »

Upon opening the NETWORK 1.35 version in Codesys, I get lots of warnings about implicit type conversions and "possible change of sign". From INT to UINT, DINT to UDINT, UINT to INT, INT to UDINT, pointer to BYTE and DWORD/UDINT, etc.

Is this normal and should I ignore the warnings or am I doing something wrong here?


CoDeSys version 3.5 SP12, Oscat basic v3.3.3 installed.

7

Modulentwicklung / Re: DLOG_STORE_FILE_CSV questions

« am: 05. Februar 2018, 11:51:51 »

Thank you very much, peewit, much appreciated. I will get me the 1.35 beta version and dive into the code to see if I can make it do what I want. If it comes to something useful, I will report back with my changes.

Also once more a big thumbs up for the Oscat libraries. They serve me in two ways: as useful additional tools in my toolbox, and as a source of inspiration to make my own.

8

Modulentwicklung / DLOG_STORE_FILE_CSV questions

« am: 04. Februar 2018, 18:23:17 »

Apologies for writing in English, I'm not very fluent in German.

I find myself using the data log functionality all the time. Mostly writing to files on local flash memory, using FTP every now and then to read log files when issues have been reported. It is a very useful tool for me. There are two features that I would very much like to see added to the data logger.

First, I'd like to be able to switch logging on and off. Having it switched off most of the time, switch it on for a while if problems are mentioned, gather some data, switch it off when the issue has been resolved. I know I can enable/disable calls to the function blocks or triggers (this is actually what I currently do). But due to buffering of writes, disabling it entirely causes the last buffer to not be written until the next time the function blocks are reenabled. Or it gets lost at a power cycle. And if I only leave out the trigger, then a new empty file is written anyway when the file name changes (I mostly use daily filename change, sometimes hourly). This would lead to filling up the file system with mostly empty files. Implementing an automatic cleanup routine that deletes older files is an option, but not an elegant one IMO. And it would cause a PLC to constantly write to flash memory, not good for longevity.

Second, and somewhat related to the first, I want the ability to force a write. When I make updates to a PLC program that cause a fresh download, the currently buffered data are lost. Or I have a program that only writes data when some feature is running but since it is not running all the time, it does not always write. It can thus take a long time for the last chunk of data to actually be written to the file system. For me it would be very useful if there were a means for "overriding" the write buffer and trigger a write to the file system despite the buffer not being completely filled.

Not sure if these requests fit in with the structure of the components. If it is an easy addition then please take these requests into account.

I'm also open for hints on how to make my own modified versions if you feel these changes would overcomplicate things for most users.

9

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 26. April 2017, 15:45:14 »

Thank you peewit, I will give that a try.


Do you have suggestions for the error messages ("Cannot pass the result of a IEC-function as string parameter to a C-function")?

10

Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION

« am: 26. April 2017, 10:42:14 »

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?