[Beremiz-devel] sizeof({DT,TIME,DATE})

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list


 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?

   Mario.





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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi, Mario!

I think this may be the solution too.

Best regards,
Paul Beltyukov.

среда, 31 мая 2017 г. пользователь написал:

>
>
>  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?
>
>    Mario.
>
>
>
>
>
> 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
>
------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi, Andrey!

No we are not using locatable DT:)

I just erroniously selected location for DT var and a crash happened...

I think crashes are not good...

Best regards,
Paul Beltyukov.

среда, 31 мая 2017 г. пользователь написал:

> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
I didn't know, that located DT are not in standard.

Regards,
Paul.

среда, 31 мая 2017 г. пользователь написал:

> Hi, Andrey!
>
> No we are not using locatable DT:)
>
> I just erroniously selected location for DT var and a crash happened...
>
> I think crashes are not good...
>
> Best regards,
> Paul Beltyukov.
>
> среда, 31 мая 2017 г. пользователь написал:
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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?
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
Hi, Andrey!

I think disabling locations for time related types is good temporary solution.

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.

So I would not recomend to take so radical approach :)

Best regards,
Paul Beltyukov


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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list

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.

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
typedef struct {
    IEC_SEC_T tv_sec;            /* Seconds.  */
    int32_t tv_nsec;           /* Nanoseconds.  */
} IEC_TIMESPEC;
then we should do it now,

In such case we are ready to 2038 without breaking compatibility with most convenient devices.

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.

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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
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.
I've seen a lot of industrial systems that are older
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
It's better to leave 'long' as it's now. Because with 'long' at least 64-bit
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] sizeof({DT,TIME,DATE})

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list


 Hi Paul,




On Friday 02 June 2017 08:03:53 [hidden email] wrote:
> Hi, Andrey!
>
> I think disabling locations for time related types is good temporary
> solution.
>
> I also think that using uint64_t for timespec is HARD decision:
>   - on one hand in may solve some problems in long term;

 I would be OK with this being a permanent solution.

 Since the standard:
   - does not specify a size for the DT data type
       (may be implementation specific)
   - implicitly mandates that located variables should match
       the size of the location

  then I conclude that the standard is OK with not allowing located DT
variables.



>   - but one the other hand it requires MUCH work on matiec and iec_std_lib,
>     and it also breaks backward compatibility.
>


 To be honest this is something that has been bothering me too, but since I do
not use beremiz/matiec in a professional setting, I have never bothered fixing
it.


 Yes, the iec_std_lib.h library would need to be fixed. This is kind of
obvious, but I will say it anyway: we would need to, at a minimum, change the
conversion functions, as well as the basic functions doing DT algebra
(mutiply, add, subtract, ...). We would also need to change some macros that
handle the DT constants, as well as the variable declaration itself.

 I think that matiec itself should be OK. Hmm.... Thinking a little more, it
may require some changes to matiec. More specifically, we will need to change
the way matiec initializes DT variables.




> So I would not recomend to take so radical approach :)
>


   Yes, that is why some of the matiec code is terrible. Because the people
writing it were afraid of making big changes. Sometimes radical changes are
needed, sometimes not. In this case I think if we are going to fix this, then
we should do it correctly.

  Cheers,

      Mario.

------------------------------------------------------------------------------
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
12
Loading...