[Beremiz-devel] sizeof({DT,TIME,DATE})
Locked
12
12
 
|
Hi,
I thought about Beremiz problem posted by Paul [1]. The problem is that user gets traceback in Beremiz if user tries to set IEC address to DT variable. This happens because size of DT, TIME and DATE is not defined in Beremiz. The reason for this is that IEC 61131 says that size of these types is implementation specific. So here we are. For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE variables. With matiec size is varies between archicture and operating system. [----- cut from iec_types.h -----] typedef struct { long int tv_sec; /* Seconds. */ long int tv_nsec; /* Nanoseconds. */ } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! */ typedef IEC_TIMESPEC IEC_TIME; typedef IEC_TIMESPEC IEC_DATE; typedef IEC_TIMESPEC IEC_DT; typedef IEC_TIMESPEC IEC_TOD; [--------------------------------] Windows IA32: 8 bytes Windows amd64: 8 bytes GNU/Linux IA32: 8 bytes GNU/Linux amd64: 16 byes Mac OS X IA32: 8 bytes Mac OS X amd64: 16 byes What size qualifier should Beremiz use then? 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
signature.asc (849 bytes) |
|
|
|
|
|
|
|
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 20:54, [hidden email] wrote:
> Hi, Andrey! > > I think DWORD is not enough for DT, as time related types at low level have > sec and nsec fields both of DWORD size (defined in iec_types.h as I > remember). I'm not saying that DT size should be DWORD. The size according to the standard depends on implementation. DWORD is size of DT, TOD, TIME and DATE in CODESYS v2 and v3. That was just an example of implementation with different size than matiec have. Just FYI standard doesn't require to have DT or TIME nsec precision. > > I think we should add matiec specific size definitions for at least basic > types to plcopen editor code. > > Best regards, > Paul Beltyukov. > > среда, 31 мая 2017 г. пользователь написал: > > Hi, > > > > I thought about Beremiz problem posted by Paul [1]. > > The problem is that user gets traceback in Beremiz if user tries to set > IEC > > address to DT variable. > > > > This happens because size of DT, TIME and DATE is not defined in > > Beremiz. The reason for this is that IEC 61131 says that size of these > > types is implementation specific. So here we are. > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > variables. > > With matiec size is varies between archicture and operating system. > > > > [----- cut from iec_types.h -----] > > > > typedef struct { > > long int tv_sec; /* Seconds. */ > > long int tv_nsec; /* Nanoseconds. */ > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! > */ > > > > typedef IEC_TIMESPEC IEC_TIME; > > typedef IEC_TIMESPEC IEC_DATE; > > typedef IEC_TIMESPEC IEC_DT; > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > [--------------------------------] > > > > > > Windows IA32: 8 bytes > > Windows amd64: 8 bytes > > GNU/Linux IA32: 8 bytes > > GNU/Linux amd64: 16 byes > > Mac OS X IA32: 8 bytes > > Mac OS X amd64: 16 byes > > > > > > What size qualifier should Beremiz use then? > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug > > > > -- > > Best regards, > > Andrey Skvortsov > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Beremiz-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/beremiz-devel -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 17:31, [hidden email] wrote:
> > > If I am understanding the problem correctly, it seems that Beremiz crashes > when trying to map a DT variable to a location (e.g. %I4.5.3). Is this > correct? > > In my opinion I think that beremiz should simply not allow this mapping to > occur. The user should be required to map a DWORD or other variable of known > size, and then use the convertion functions DWORD_TO_DT() or DT_TO_DWORD) > > Would this be asking too much of the user? Hi Mario, this sounds fair enough. Let's do this. Paul, as I understand you currently use locatable variables of DT type to access values in RTC. Right? > On Wednesday 31 May 2017 16:57:27 [hidden email] wrote: > > And yes, how about replacing "long int" with "int32_t" ? > > > > среда, 31 мая 2017 г. пользователь написал: > > > Hi, > > > > > > I thought about Beremiz problem posted by Paul [1]. > > > The problem is that user gets traceback in Beremiz if user tries to set > > > > IEC > > > > > address to DT variable. > > > > > > This happens because size of DT, TIME and DATE is not defined in > > > Beremiz. The reason for this is that IEC 61131 says that size of these > > > types is implementation specific. So here we are. > > > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > > > > variables. > > > > > With matiec size is varies between archicture and operating system. > > > > > > [----- cut from iec_types.h -----] > > > > > > typedef struct { > > > > > > long int tv_sec; /* Seconds. */ > > > long int tv_nsec; /* Nanoseconds. */ > > > > > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! > > > > */ > > > > > typedef IEC_TIMESPEC IEC_TIME; > > > typedef IEC_TIMESPEC IEC_DATE; > > > typedef IEC_TIMESPEC IEC_DT; > > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > > > > [--------------------------------] > > > > > > > > > Windows IA32: 8 bytes > > > Windows amd64: 8 bytes > > > GNU/Linux IA32: 8 bytes > > > GNU/Linux amd64: 16 byes > > > Mac OS X IA32: 8 bytes > > > Mac OS X amd64: 16 byes > > > > > > > > > What size qualifier should Beremiz use then? > > > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug > > > > > > -- > > > Best regards, > > > Andrey Skvortsov > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Beremiz-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/beremiz-devel Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 20:57, [hidden email] wrote:
> And yes, how about replacing "long int" with "int32_t" ? And this is another problem that I want to discuss. int32_t is a problem, not a solution! On all 32-bit platforms 'long int' is the same as int32_t (32-bit long). Number of seconds since 1.1.1970 is stored as 32-bit integer. The problem is that 'long int' is going to overflow at 03:14:08 UTC on 19 January 2038). Mario, could you replace 'long int' at least with 'unsigned long int'. So we safe at least until 2106. But in this case dates before 1.1.1970 can't be handled. What do you think about that? > среда, 31 мая 2017 г. пользователь написал: > > Hi, > > > > I thought about Beremiz problem posted by Paul [1]. > > The problem is that user gets traceback in Beremiz if user tries to set > IEC > > address to DT variable. > > > > This happens because size of DT, TIME and DATE is not defined in > > Beremiz. The reason for this is that IEC 61131 says that size of these > > types is implementation specific. So here we are. > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > variables. > > With matiec size is varies between archicture and operating system. > > > > [----- cut from iec_types.h -----] > > > > typedef struct { > > long int tv_sec; /* Seconds. */ > > long int tv_nsec; /* Nanoseconds. */ > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! > */ > > > > typedef IEC_TIMESPEC IEC_TIME; > > typedef IEC_TIMESPEC IEC_DATE; > > typedef IEC_TIMESPEC IEC_DT; > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > [--------------------------------] > > > > > > Windows IA32: 8 bytes > > Windows amd64: 8 bytes > > GNU/Linux IA32: 8 bytes > > GNU/Linux amd64: 16 byes > > Mac OS X IA32: 8 bytes > > Mac OS X amd64: 16 byes > > > > > > What size qualifier should Beremiz use then? > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug > > > > -- > > Best regards, > > Andrey Skvortsov > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Beremiz-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/beremiz-devel -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
|
|
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 23:09, [hidden email] wrote:
> Hi, Andrey! > > No we are not using locatable DT:) Good. I'll try fix this tomorrow. > I just erroniously selected location for DT var and a crash happened... > > I think crashes are not good... Certainly. -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 21:04, [hidden email] wrote: > On 17-05-31 20:57, [hidden email] wrote: > > And yes, how about replacing "long int" with "int32_t" ? > > And this is another problem that I want to discuss. > int32_t is a problem, not a solution! > On all 32-bit platforms 'long int' is the same as int32_t (32-bit > long). Number of seconds since 1.1.1970 is stored as 32-bit integer. > The problem is that 'long int' is going to overflow at 03:14:08 UTC on > 19 January 2038). > > Mario, could you replace 'long int' at least with 'unsigned long int'. > So we safe at least until 2106. But in this case dates before 1.1.1970 > can't be handled. What do you think about that? typedef int64_t IEC_TIMESPEC this will increase range dates from +/- 68 years to +/- 272 years. Because couple bits from tv_nsec are unused currently. And this solutions allows to handle dates before 1.1.1970. For information about the problem: https://en.wikipedia.org/wiki/Year_2038_problem > > среда, 31 мая 2017 г. пользователь написал: > > > Hi, > > > > > > I thought about Beremiz problem posted by Paul [1]. > > > The problem is that user gets traceback in Beremiz if user tries to set > > IEC > > > address to DT variable. > > > > > > This happens because size of DT, TIME and DATE is not defined in > > > Beremiz. The reason for this is that IEC 61131 says that size of these > > > types is implementation specific. So here we are. > > > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > > variables. > > > With matiec size is varies between archicture and operating system. > > > > > > [----- cut from iec_types.h -----] > > > > > > typedef struct { > > > long int tv_sec; /* Seconds. */ > > > long int tv_nsec; /* Nanoseconds. */ > > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! > > */ > > > > > > typedef IEC_TIMESPEC IEC_TIME; > > > typedef IEC_TIMESPEC IEC_DATE; > > > typedef IEC_TIMESPEC IEC_DT; > > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > > > > [--------------------------------] > > > > > > > > > Windows IA32: 8 bytes > > > Windows amd64: 8 bytes > > > GNU/Linux IA32: 8 bytes > > > GNU/Linux amd64: 16 byes > > > Mac OS X IA32: 8 bytes > > > Mac OS X amd64: 16 byes > > > > > > > > > What size qualifier should Beremiz use then? > > > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug > > > > > > -- > > > Best regards, > > > Andrey Skvortsov > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > Beremiz-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel > > > -- > Best regards, > Andrey Skvortsov > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Beremiz-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/beremiz-devel -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 21:51, [hidden email] wrote:
> On 17-05-31 23:09, [hidden email] wrote: > > Hi, Andrey! > > > > No we are not using locatable DT:) > Good. I'll try fix this tomorrow. > > I just erroniously selected location for DT var and a crash happened... > > > > I think crashes are not good... > I pushed patch for that. -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
On 17-05-31 23:12, [hidden email] wrote:
> I didn't know, that located DT are not in standard. I think located DT is allowed by the standard. I don't see any restriction on type for located variables. Disable located DT variable this is just our solution for the problem with size of DT. -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
In reply to this post by Beremiz-Devel mailing list
Any comments on that?
On 17-06-01 14:32, [hidden email] wrote: > > On 17-05-31 21:04, [hidden email] wrote: > > On 17-05-31 20:57, [hidden email] wrote: > > > And yes, how about replacing "long int" with "int32_t" ? > > > > And this is another problem that I want to discuss. > > int32_t is a problem, not a solution! > > On all 32-bit platforms 'long int' is the same as int32_t (32-bit > > long). Number of seconds since 1.1.1970 is stored as 32-bit integer. > > The problem is that 'long int' is going to overflow at 03:14:08 UTC on > > 19 January 2038). > > > > Mario, could you replace 'long int' at least with 'unsigned long int'. > > So we safe at least until 2106. But in this case dates before 1.1.1970 > > can't be handled. What do you think about that? > > Another way would be to use single int64_t value fro IEC_TIMESPEC, > > typedef int64_t IEC_TIMESPEC > > this will increase range dates from +/- 68 years to +/- 272 years. > Because couple bits from tv_nsec are unused currently. > And this solutions allows to handle dates before 1.1.1970. > > For information about the problem: > https://en.wikipedia.org/wiki/Year_2038_problem > > > > > > среда, 31 мая 2017 г. пользователь написал: > > > > Hi, > > > > > > > > I thought about Beremiz problem posted by Paul [1]. > > > > The problem is that user gets traceback in Beremiz if user tries to set > > > IEC > > > > address to DT variable. > > > > > > > > This happens because size of DT, TIME and DATE is not defined in > > > > Beremiz. The reason for this is that IEC 61131 says that size of these > > > > types is implementation specific. So here we are. > > > > > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > > > variables. > > > > With matiec size is varies between archicture and operating system. > > > > > > > > [----- cut from iec_types.h -----] > > > > > > > > typedef struct { > > > > long int tv_sec; /* Seconds. */ > > > > long int tv_nsec; /* Nanoseconds. */ > > > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc specific! > > > */ > > > > > > > > typedef IEC_TIMESPEC IEC_TIME; > > > > typedef IEC_TIMESPEC IEC_DATE; > > > > typedef IEC_TIMESPEC IEC_DT; > > > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > > > > > > > [--------------------------------] > > > > > > > > > > > > Windows IA32: 8 bytes > > > > Windows amd64: 8 bytes > > > > GNU/Linux IA32: 8 bytes > > > > GNU/Linux amd64: 16 byes > > > > Mac OS X IA32: 8 bytes > > > > Mac OS X amd64: 16 byes > > > > > > > > > > > > What size qualifier should Beremiz use then? > > > > > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var-location-bug > > > > > > > > -- > > > > Best regards, > > > > Andrey Skvortsov > > > > > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > _______________________________________________ > > > Beremiz-devel mailing list > > > [hidden email] > > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel > > > > > > -- > > Best regards, > > Andrey Skvortsov > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > Beremiz-devel mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/beremiz-devel > > > -- > Best regards, > Andrey Skvortsov > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Beremiz-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/beremiz-devel -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
|
|
On 17-06-02 12:03, [hidden email] wrote:
> Hi, Andrey! > > I also think that using uint64_t for timespec is HARD decision: > - on one hand in may solve some problems in long term; > - but one the other hand it requires MUCH work on matiec and iec_std_lib, > and it also breaks backward compatibility. I know, therefore I'd like to discuss this problem. I think this is important problem, because embedded industrial devices, that are produced/developed now, will most likely run in 2038. So at least we have plan to solve this problem. Maybe we'd find appropriate solution for this. Mario, what do you think about this? > So I would not recomend to take so radical approach :) What approach do use suggest then? > Best regards, > Paul Beltyukov > > 2017-06-02 11:16 GMT+05:00 <[hidden email]>: > > > Any comments on that? > > > > On 17-06-01 14:32, [hidden email] wrote: > > > > > > On 17-05-31 21:04, [hidden email] wrote: > > > > On 17-05-31 20:57, [hidden email] wrote: > > > > > And yes, how about replacing "long int" with "int32_t" ? > > > > > > > > And this is another problem that I want to discuss. > > > > int32_t is a problem, not a solution! > > > > On all 32-bit platforms 'long int' is the same as int32_t (32-bit > > > > long). Number of seconds since 1.1.1970 is stored as 32-bit integer. > > > > The problem is that 'long int' is going to overflow at 03:14:08 UTC on > > > > 19 January 2038). > > > > > > > > Mario, could you replace 'long int' at least with 'unsigned long int'. > > > > So we safe at least until 2106. But in this case dates before 1.1.1970 > > > > can't be handled. What do you think about that? > > > > > > Another way would be to use single int64_t value fro IEC_TIMESPEC, > > > > > > typedef int64_t IEC_TIMESPEC > > > > > > this will increase range dates from +/- 68 years to +/- 272 years. > > > Because couple bits from tv_nsec are unused currently. > > > And this solutions allows to handle dates before 1.1.1970. > > > > > > For information about the problem: > > > https://en.wikipedia.org/wiki/Year_2038_problem > > > > > > > > > > > > > > среда, 31 мая 2017 г. пользователь написал: > > > > > > Hi, > > > > > > > > > > > > I thought about Beremiz problem posted by Paul [1]. > > > > > > The problem is that user gets traceback in Beremiz if user tries > > to set > > > > > IEC > > > > > > address to DT variable. > > > > > > > > > > > > This happens because size of DT, TIME and DATE is not defined in > > > > > > Beremiz. The reason for this is that IEC 61131 says that size of > > these > > > > > > types is implementation specific. So here we are. > > > > > > > > > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and DATE > > > > > variables. > > > > > > With matiec size is varies between archicture and operating system. > > > > > > > > > > > > [----- cut from iec_types.h -----] > > > > > > > > > > > > typedef struct { > > > > > > long int tv_sec; /* Seconds. */ > > > > > > long int tv_nsec; /* Nanoseconds. */ > > > > > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc > > specific! > > > > > */ > > > > > > > > > > > > typedef IEC_TIMESPEC IEC_TIME; > > > > > > typedef IEC_TIMESPEC IEC_DATE; > > > > > > typedef IEC_TIMESPEC IEC_DT; > > > > > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > > > > > > > > > > > > > [--------------------------------] > > > > > > > > > > > > > > > > > > Windows IA32: 8 bytes > > > > > > Windows amd64: 8 bytes > > > > > > GNU/Linux IA32: 8 bytes > > > > > > GNU/Linux amd64: 16 byes > > > > > > Mac OS X IA32: 8 bytes > > > > > > Mac OS X amd64: 16 byes > > > > > > > > > > > > > > > > > > What size qualifier should Beremiz use then? > > > > > > > > > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var- > > location-bug > > > > > > Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
|
|
On 17-06-02 17:18, [hidden email] wrote:
> > What approach do use suggest then? > > Well, we have at least 19 years ahead :) So it's not neccessary to replace > long int pair with single uin64_t immediatelly. > > I have doubt about > > embedded industrial devices, that are > > produced/developed now, will most likely run in 2038. > > > I think that there are few applications for son long term working devices > (e.g. Nuclear industry). > Most of industrial devices have 8-10 years life cycle. > > So IMO 2038 problem is something like y2k problem. than 10 years. Usually people don't replace the systems, if they are working good. I've seen system that is working for 30 years (not nuclear industry) and has some kind of SCADA for DOS. People are still using it. > So my aproach is: If we can *just* replace > > > typedef struct { > > long int tv_sec; /* Seconds. */ > > long int tv_nsec; /* Nanoseconds. */ > > } /* __attribute__((packed)) */ IEC_TIMESPEC; > > > with something like > > > #ifndef IEC_SEC_T > > > # define IEC_SEC_T int32_t > > > #endif systems are safe. > typedef struct { > > IEC_SEC_T tv_sec; /* Seconds. */ > > int32_t tv_nsec; /* Nanoseconds. */ > > } IEC_TIMESPEC; > > > then we should do it now, And probably it's better to leave tv_nsec as 'long' as it was before. So the structure is the same as POSIX-defined 'struct timespec'. struct timespec { time_t tv_sec; /* seconds */ long tv_nsec; /* nanoseconds */ }; > In such case we are ready to 2038 without breaking compatibility with most > convenient devices. If you are going to change size of IEC_SEC_T, you will break ABI compatibility in this case anyway. > Anyway Marios opinion is needed as he is most expertised in matiec. > > And I think business people (e.g Smarteh) should also say some words, as > their products may depend on such changes. To have opinions on that from Mario and Smarteh's guys would be really nice. This is main purpose of this discussion! > Best regards, > Paul Beltyukov > > 2017-06-02 12:43 GMT+05:00 <[hidden email]>: > > > On 17-06-02 12:03, [hidden email] wrote: > > > Hi, Andrey! > > > > > > I also think that using uint64_t for timespec is HARD decision: > > > - on one hand in may solve some problems in long term; > > > - but one the other hand it requires MUCH work on matiec and > > iec_std_lib, > > > and it also breaks backward compatibility. > > > > I know, therefore I'd like to discuss this problem. I think this is > > important problem, because embedded industrial devices, that are > > produced/developed now, will most likely run in 2038. > > So at least we have plan to solve this problem. > > > > Maybe we'd find appropriate solution for this. > > Mario, what do you think about this? > > > > > So I would not recomend to take so radical approach :) > > What approach do use suggest then? > > > > > > > Best regards, > > > Paul Beltyukov > > > > > > 2017-06-02 11:16 GMT+05:00 <[hidden email]>: > > > > > > > Any comments on that? > > > > > > > > On 17-06-01 14:32, [hidden email] wrote: > > > > > > > > > > On 17-05-31 21:04, [hidden email] wrote: > > > > > > On 17-05-31 20:57, [hidden email] wrote: > > > > > > > And yes, how about replacing "long int" with "int32_t" ? > > > > > > > > > > > > And this is another problem that I want to discuss. > > > > > > int32_t is a problem, not a solution! > > > > > > On all 32-bit platforms 'long int' is the same as int32_t (32-bit > > > > > > long). Number of seconds since 1.1.1970 is stored as 32-bit > > integer. > > > > > > The problem is that 'long int' is going to overflow at 03:14:08 > > UTC on > > > > > > 19 January 2038). > > > > > > > > > > > > Mario, could you replace 'long int' at least with 'unsigned long > > int'. > > > > > > So we safe at least until 2106. But in this case dates before > > 1.1.1970 > > > > > > can't be handled. What do you think about that? > > > > > > > > > > Another way would be to use single int64_t value fro IEC_TIMESPEC, > > > > > > > > > > typedef int64_t IEC_TIMESPEC > > > > > > > > > > this will increase range dates from +/- 68 years to +/- 272 years. > > > > > Because couple bits from tv_nsec are unused currently. > > > > > And this solutions allows to handle dates before 1.1.1970. > > > > > > > > > > For information about the problem: > > > > > https://en.wikipedia.org/wiki/Year_2038_problem > > > > > > > > > > > > > > > > > > > > > > среда, 31 мая 2017 г. пользователь написал: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I thought about Beremiz problem posted by Paul [1]. > > > > > > > > The problem is that user gets traceback in Beremiz if user > > tries > > > > to set > > > > > > > IEC > > > > > > > > address to DT variable. > > > > > > > > > > > > > > > > This happens because size of DT, TIME and DATE is not defined > > in > > > > > > > > Beremiz. The reason for this is that IEC 61131 says that size > > of > > > > these > > > > > > > > types is implementation specific. So here we are. > > > > > > > > > > > > > > > > For example, CODESYS v2 and v3 use DWORD to store DT, TIME and > > DATE > > > > > > > variables. > > > > > > > > With matiec size is varies between archicture and operating > > system. > > > > > > > > > > > > > > > > [----- cut from iec_types.h -----] > > > > > > > > > > > > > > > > typedef struct { > > > > > > > > long int tv_sec; /* Seconds. */ > > > > > > > > long int tv_nsec; /* Nanoseconds. */ > > > > > > > > } /* __attribute__((packed)) */ IEC_TIMESPEC; /* packed is gcc > > > > specific! > > > > > > > */ > > > > > > > > > > > > > > > > typedef IEC_TIMESPEC IEC_TIME; > > > > > > > > typedef IEC_TIMESPEC IEC_DATE; > > > > > > > > typedef IEC_TIMESPEC IEC_DT; > > > > > > > > typedef IEC_TIMESPEC IEC_TOD; > > > > > > > > > > > > > > > > > > > > > > > > [--------------------------------] > > > > > > > > > > > > > > > > > > > > > > > > Windows IA32: 8 bytes > > > > > > > > Windows amd64: 8 bytes > > > > > > > > GNU/Linux IA32: 8 bytes > > > > > > > > GNU/Linux amd64: 16 byes > > > > > > > > Mac OS X IA32: 8 bytes > > > > > > > > Mac OS X amd64: 16 byes > > > > > > > > > > > > > > > > > > > > > > > > What size qualifier should Beremiz use then? > > > > > > > > > > > > > > > > 1. https://bitbucket.org/skvorl/beremiz/issues/28/dt-var- > > > > location-bug > > > > > > > > -- Best regards, Andrey Skvortsov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Beremiz-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/beremiz-devel |
|
|
Loading...
| Free forum by Nabble | Edit this page |