Beiträge

mg, I apologise for replying in English rather than German (and a bit late as well).

As of now there is no port to 64-bit controllers for the Oscat libraries that I know of. Most of the OSCAT_BASIC library will work on both 32-bit as well as 64-bit controllers. Only the _BUFFER_CLEAR() and _BUFFER_INIT() functions are very specifically optimised for 32-bit alignment of bytes and will not work correctly on 64-bit.

You are correct in pointing out that the OSCAT_NETWORK library for CoDeSys uses SysFile23 and SysSocket23 which are both only available for 32-bit. System libraries SysFile and SysSocket indeed have similar functionality and work on both 32-bit (PFC200) as well as 64bit (PFC300) controllers. In addition they would require CmpErrors for standard enumerated error codes rather than the Oscat specific error codes of the existing network library. While there are similarities between SysFile23/SysSocket23 and SysFile/SysSocket, the differences are sufficient to require many small changes as well as some decent testing to verify correctness.

The function blocks FILE_SERVER(), IP_CONTROL() and IP_CONTROL2() need significant modifications for porting to the use of the other libraries. Other parts of the code may require additional modifications. I have found this to be the case for the D_LOG_STORE_FILE_xxxx function blocks for logging to files. Limited resources have stopped me doing further work  on this.

It has been a month since I started this thread. There have been over 300 views yet no replies. At first I thought summer holidays leads to delays in people responding to my questions in this thread. Summer holidays on the northern hemisphere are over though and still no response. And the views may have been mostly bots rather than humans.

This leads me to believe there is no interest in porting any of the Oscat codebase to 64-bit CoDeSys. I believe this can be done in a way that keeps the codebase working as before on 32-bit systems. As pointed out above, CoDeSys v3 has types like __XWORD as well as libraries SysFile and SysSocket rather than SysFile23 and SysSocket23 which would make this feasible.

For now I will keep using those portions of the libraries that port without modifications. I may adapt _BUFFER_CLEAR() and _BUFFER_INIT() from the Oscat BASIC lib for my own use. For now I have stopped using those. I have adapted a few parts of the Network library that are relevant for me so I can keep using the DLOG eco system for logging to file (csv, xml, html).

I work in a small business and have neither the time nor resources available to adapt all of the libraries in a way that meets quality standards. I am sorry to say that in the long run I may abandon most of Oscat altogether.

OSCAT_NETWORK
On CoDeSys the original implementation of network and file access depends, among other things, on two libraries SysSocket23 and SysFile23. Both of these exist only for 32-bit platforms. Their counterparts SysSocket and SysFile will work on both 32 bit and 64 bit. They have similar functionality but types used and interfaces to the relevant POUs are not identical. Substantial changes seem required for POUs IP_CONTROL(), IP_CONTROL2() and FILE_SERVER().

So far we do not make extensive use of specific networking POUs. Everything that uses IP_CONTROL() and IP_CONTROL2() is for now commented out in my copy of OSCAT_NETWORK. We do use the DLOG POUs and types. So I have adapted the FILE_SERVER() function block to use SysFile rather than SysFile23. It is no rocket science, but not trivial either. So far it works for me, but lack of time may have resulted in me missing some points and taking some shortcuts. I have made extensive use of the __XWORD type. This allows for code that will run on both 32-bit and 64-bit platforms. File handles and error handling have needed some changes. It is not ideal, it does work.

As we do most logging to the file system, I did convert the POUs for that (mostly DLOG_STORE_FILE_CSV). Parts of the DLOG ecosystem that log via a network connection of the controllers would require IP_CONTROL() and IP_CONTROL2() to be reworked. I don't have time for that. For now I have excluded those parts from build in my copy of the OSCAT_NETWORK library.

OSCAT_BASIC
Mostly works fine on either 32bit or 64bit controllers. However, the POUs _BUFFER_CLEAR() and _BUFFER_INIT() have their code very specifically optimized for 32-bit alignment. They would need to be either simplified or completely rewritten to run on 64-bit controllers. Even then, I would very much prefer to have a version that can be used without modifications on both 32-bit and 64-bit targets. I'm thinking use of some combination of pragma's, SIZEOF(), types like __XWORD and __XINT.

I currently don't have time to rewrite myself, so as a workaround I have made a copy of the BASIC library where I excluded _BUFFER_CLEAR() and _BUFFER_INIT(). I actually used these in one or two places. For now I have gone back to the use of simple FOR loops instead. It works fine, although I have lost the optimizations of the original OSCAT POUs.

I have done some work on a few things that are most urgent for me. However I lack time and resources to do everything and have it properly reviewed and tested by others. What I have found and what I have done so far can be useful additional background information.

I have been using the Oscat libraries BASIC and NETWORK for several years now and have always been happy with the added functionality. Recently, we have started looking into 64-bit controllers at work, programmed through CoDeSys 3.5 with 64-bit targets. Here is where I run into some issues. It seems more people have asked about this every once in a while. So far I find no consensus on how things with Oscat will progress in that direction.

My question is: will any work be done about supporting 64-bit targets for the OSCAT libraries? Either by the good people of the original Oscat libs here, or some small group of volunteers? If so, how are we to move forward on this?

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.

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.

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 Erweitern

#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.

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 Erweitern

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 8)

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

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.

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.

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.

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")?