Beiträge

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.

Going back over this I think I was wrong here. I lack time for extensive testing but I think the original code for _BUFFER_CLEAR() and _BUFFER_INIT() will work on 64-bit. It is just not as efficient as it can be. I have adapted versions using the __XWORD datatype and compiler pragma's so the same code is optimized for both 32-bit and 64-bit. No code changes required. One library can still be used on both 32b and 64b controllers. If someone wants to test these or just review what I did, I can post the code.

Not sure if we should keep discussing this here, or move to a Codesys specific place, like Codesys Forge. The latter has the advantage that we can share code there. Switching to english can be cumbersome for some. On the other hand it has a larger active user base.

Thoughts are welcome.

In the mean time I have adapted the POUs _BUFFER_CLEAR() and _BUFFER_INIT() from OSCAT BASIC to compile on both 32bit as well as 64bit while retaining the original optimizations, which are quite smart indeed. Independent review and tests would be welcome (unit testing, for instance through co♻e ?).

Thanks for getting back to me. Another forum member has contacted me through PM.
I do read German. Writing would be difficult and time consuming.

I am not asking Peewit, Hugo or other Oscat staff to do all the work for us. I would happily contribute and work together on this with other people. Like you I work in a small company and don't have time to do all the work myself either. Ideally I'd like to see a small group of people each doing some work, working together on reviewing and testing the results.

Also, last but not least, it would be invaluable to have peers to discuss options. For instance, I have done some work on the NETWORK library, more specifically the parts for logging to file as that is what I currently use a lot. The original code uses SysFile23. File open modes and error handling is done through bespoke STRING(2) and BYTE codes. As in, these codes are specific to the OSCAT libraries.

When converting to the current SysFile library rather than SysFile23, my initial approach has been to replace all bespoke OSCAT codes with types from SysFile. The file handle becomes a variable of type SysFile.RTS_IEC_HANDLE rather than a DWORD from original OSCAT code. The open_mode, originaly STRING(2), is now of type SysFile.ACCES_MODE. For error handling, the error_code was a BYTE with bespoke values typical to OSCAT. I changed that into SysFile.RTS_IEC_RESULT.

All of that works fine. However, it requires changes in the type FILE_SERVER_DATA. Which in turn requires code changes in all functions/function blocks that use FILE_SERVER_DATA. The original intention of the OSCAT programmers has been to have all the platform specific code inside FILE_SERVER so all other code can remain identical for all platforms. I now realise that my approach breaks this independency. It would make the CoDeSys branch incompatible with the other branches of the NETWORK library. It would be invaluable to have some other people think with me on issues like this.

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