[Beremiz-devel] REAL as DWORD representation.

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

[Beremiz-devel] REAL as DWORD representation.

Beremiz-Devel mailing list
Hello.

I'm testing the Beremiz for a while by transferring real projects from Isagrapf, Danfos etc...

Now I've faced problem. I have some parameter, which type is REAL and I want to share it through Modbus-server. And yes, I use Beremiz-friendly extention by Mario de Sousa. Ok, i can share parameters of types: BOOL, WORD. But, how I can convert REAL (...and what precision is it?  what lenght in bytes? four?) to couple of words?

First of all, I tryed to use Type-converion blocks (or functions on ST) like REAL_TO_DWORD... And I wonder, there only integer part on result! Is it really need to somebody, to make TRUNC while just convertion to <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field operation like shift-left or right, get HI or LOW byte...

Now I really need function REAL_AS_DWORD. Or, maybe get pointer from my real value and copy it by offset. But, is it possible on Beremiz and MatIEC?


-- And
Best regards,
Denis Kholodkov.

------------------------------------------------------------------------------
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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] REAL as DWORD representation.

Beremiz-Devel mailing list
Hi Denis,

On 17-07-27 17:23, beremiz-devel--- via Beremiz-devel wrote:

> Hello.
>
> I'm testing the Beremiz for a while by transferring real projects from
> Isagrapf, Danfos etc...
>
> Now I've faced problem. I have some parameter, which type is REAL and I
> want to share it through Modbus-server. And yes, I use Beremiz-friendly
> extention by Mario de Sousa. Ok, i can share parameters of types: BOOL,
> WORD. But, how I can convert REAL (...and what precision is it?  what
> lenght in bytes? four?) to couple of words?
REAL uses 4 bytes according to the IEC 61131 standard. See section
2.3.1. LREAL is for double precision.

> First of all, I tryed to use Type-converion blocks (or functions on ST)
> like REAL_TO_DWORD... And I wonder, there only integer part on result!
> Is it really need to somebody, to make TRUNC while just convertion to
> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
> operation like shift-left or right, get HI or LOW byte...
These functions are defined by the standard. ;-)

> Now I really need function REAL_AS_DWORD. Or, maybe get pointer from my
> real value and copy it by offset. But, is it possible on Beremiz and
> MatIEC?

Vasilij came with the same questions some time ago.
Look at beremiz-devel archive. I think the code is posted there.
In general the idea is to write own function with C prama
and use C to convert data between REAL and DWORD.

I've written these functions for own use, but I don't have access to
the code right now. Probably I'll add this code to some Beremiz library soon.

--
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] REAL as DWORD representation.

Beremiz-Devel mailing list
On Thursday 27 July 2017 18:55:47 [hidden email] wrote:
> Hi Denis,
>
> > First of all, I tryed to use Type-converion blocks (or functions on ST)
> > like REAL_TO_DWORD... And I wonder, there only integer part on result!

 What else did you expect? How do you want to store a decimal part in an
integer type variable?


> > Is it really need to somebody, to make TRUNC while just convertion to
> > <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
> > operation like shift-left or right, get HI or LOW byte...

 Can you explain more clearly what it is you want?
 I did not understand... Sorry!
 


> > Now I really need function REAL_AS_DWORD. Or, maybe get pointer from my
> > real value and copy it by offset. But, is it possible on Beremiz and
> > MatIEC?
>
> Vasilij came with the same questions some time ago.
> Look at beremiz-devel archive. I think the code is posted there.
> In general the idea is to write own function with C prama
> and use C to convert data between REAL and DWORD.
>
> I've written these functions for own use, but I don't have access to
> the code right now. Probably I'll add this code to some Beremiz library
> soon.

 I wrote an extension to matiec that allows matiec to support pointers. I
think it also supports pointers to void (or equivalent). It may be possible to
do what you want using pointers, but if you want to do it very often I would
go with what Andrey suggested, i.e. simply create your own function.



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

Re: [Beremiz-devel] REAL as DWORD representation.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
Hi Denis,
Hello, Mario!
First of all, I tryed to use Type-converion blocks (or functions on ST)
like REAL_TO_DWORD... And I wonder, there only integer part on result!
 What else did you expect? How do you want to store a decimal part in an 
integer type variable?
Of Course, not :)
Is it really need to somebody, to make TRUNC while just convertion to
<ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
operation like shift-left or right, get HI or LOW byte...
 Can you explain more clearly what it is you want?
 I did not understand... Sorry!
I must apologize, my English is terrible...
Now I really need function REAL_AS_DWORD. Or, maybe get pointer from my
real value and copy it by offset. But, is it possible on Beremiz and
MatIEC?
Vasilij came with the same questions some time ago.
Look at beremiz-devel archive. I think the code is posted there.
In general the idea is to write own function with C prama
and use C to convert data between REAL and DWORD.

I've written these functions for own use, but I don't have access to
the code right now. Probably I'll add this code to some Beremiz library
soon.
 I wrote an extension to matiec that allows matiec to support pointers. I 
think it also supports pointers to void (or equivalent). It may be possible to 
do what you want using pointers, but if you want to do it very often I would 
go with what Andrey suggested, i.e. simply create your own function.
Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a number yet, just two bytes and in another words 65536 conditions of whatever i want, it's it? That's why I can't agree with you. If we convert REAL (4 bytes) to, for example DWORD, we just get REAL as bit-field and set it accordingly to DWORD. IMHO, something other is senselessly, because if we want to get integer part of real - we have TRUNC function and should get something from <ANY_NUM> to assign a result. I think such behavior get us mach more capabilities.

What about pointers and C-injections... Ok, that's working solution, but... Isn't whole 61131-3 about languages that's main purpose is support engineers, who perfectly knows tech-flow, but not programming? We must bring them tools which are absolutely abstract from internal machine processes. I think that pointers and alien injections kills good ideas of 61131.
-- 
Best regards,
Denis Kholodkov.

------------------------------------------------------------------------------
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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Beremiz-devel] REAL as DWORD representation.

Beremiz-Devel mailing list
On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:

> > Hi Denis,
> Hello, Mario!
> >> First of all, I tryed to use Type-converion blocks (or functions on ST)
> >> like REAL_TO_DWORD... And I wonder, there only integer part on result!
> >  What else did you expect? How do you want to store a decimal part in an
> > integer type variable?
> Of Course, not :)
> >>> Is it really need to somebody, to make TRUNC while just convertion to
> >>> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
> >>> operation like shift-left or right, get HI or LOW byte...
> >  Can you explain more clearly what it is you want?
> >  I did not understand... Sorry!
> I must apologize, my English is terrible...
> >>> Now I really need function REAL_AS_DWORD. Or, maybe get pointer from my
> >>> real value and copy it by offset. But, is it possible on Beremiz and
> >>> MatIEC?
> >> Vasilij came with the same questions some time ago.
> >> Look at beremiz-devel archive. I think the code is posted there.
> >> In general the idea is to write own function with C prama
> >> and use C to convert data between REAL and DWORD.
> >>
> >> I've written these functions for own use, but I don't have access to
> >> the code right now. Probably I'll add this code to some Beremiz library
> >> soon.
> >  I wrote an extension to matiec that allows matiec to support pointers. I
> > think it also supports pointers to void (or equivalent). It may be possible to
> > do what you want using pointers, but if you want to do it very often I would
> > go with what Andrey suggested, i.e. simply create your own function.
> Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
> number yet, just two bytes and in another words 65536 conditions of
> whatever i want, it's it? That's why I can't agree with you. If we
> convert REAL (4 bytes) to, for example DWORD, we just get REAL as
> bit-field and set it accordingly to DWORD. IMHO, something other is
> senselessly, because if we want to get integer part of real - we have
> TRUNC function and should get something from <ANY_NUM> to assign a
> result. I think such behavior get us mach more capabilities.
By the way, REAL_TO_INT works slightly different than TRUNC (see IEC-61131-3 section 2.5.1.5.1 Type conversion functions).

Standard doesn't explicitly says how [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
information about that in the second edition of the standard. I don't
have access to the third edition.

But probably we are not going to change behavior of these functions anyway.
First, it'll break existing Beremiz programs. Second, IMHO current
implementation is logical. *_TO_*  functions are just simple type
casting function. In CODESYS these functions have the same behavior.

I know DWORD_TO_REAL works differently in Step7.
And I agree with you that this function is very useful. But
unfortunately it's not defined in the standard. I'll add it to
additional function blocks Beremiz library.
Any suggestion for the name of function are welcome? :-)

Mario, have you read the third edition of the standard?
Does it have any clarification for [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD? Has it description of any special function
for this kind of conversions?

> What about pointers and C-injections... Ok, that's working solution,
> but... Isn't whole 61131-3 about languages that's main purpose is
> support engineers, who perfectly knows tech-flow, but not programming?
> We must bring them tools which are absolutely abstract from internal
> machine processes. I think that pointers and alien injections kills good
> ideas of 61131.
Denis, I agree with you, but pointers and a lot of other stuff are now
officially part of IEC-61131-3 standard (see changes in the third edition).


--
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] REAL as DWORD representation.

Beremiz-Devel mailing list


  Hi Andrey & Denis

On 31.07.2017 16:52, [hidden email] wrote:
> On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:
>> > Hi Denis,
>> Hello, Mario!
>> >> First of all, I tryed to use Type-converion blocks (or functions on ST)
>> >> like REAL_TO_DWORD... And I wonder, there only integer part on result!
>> >  What else did you expect? How do you want to store a decimal part in an
>> > integer type variable?
>> Of Course, not :)

  OK. I read your explanation further on and I now understand your logic.
I actually agree with you!

>> >>> Is it really need to somebody, to make TRUNC while just convertion to
>> >>> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
>> >>> operation like shift-left or right, get HI or LOW byte...
>> >  Can you explain more clearly what it is you want?
>> >  I did not understand... Sorry!
>> I must apologize, my English is terrible...

  Nope, not really. I understood your second explanation perfectly!
  Your first explanation includes a non explicit assumption that I was
unable to figure out (yes, sometimes I am slow in understanding because
I take things a little too literally- my wife hates this about me).

>> >  I wrote an extension to matiec that allows matiec to support pointers. I
>> > think it also supports pointers to void (or equivalent). It may be possible to
>> > do what you want using pointers, but if you want to do it very often I would
>> > go with what Andrey suggested, i.e. simply create your own function.
>> Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
>> number yet, just two bytes and in another words 65536 conditions of
>> whatever i want, it's it? That's why I can't agree with you. If we
>> convert REAL (4 bytes) to, for example DWORD, we just get REAL as
>> bit-field and set it accordingly to DWORD. IMHO, something other is
>> senselessly, because if we want to get integer part of real - we have
>> TRUNC function and should get something from <ANY_NUM> to assign a
>> result. I think such behavior get us mach more capabilities.
> By the way, REAL_TO_INT works slightly different than TRUNC (see
> IEC-61131-3 section 2.5.1.5.1 Type conversion functions).
>
> Standard doesn't explicitly says how [DL]WORD_TO_REAL and
> REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
> information about that in the second edition of the standard. I don't
> have access to the third edition.


  Yep, this is what I remember from the standard too.

  I just browsed through the standard (v2) to be absolutely sure, and can
confirm. It merely defines how to round when converting REAL/LREAL to
INT/LINT/UINT... However, even then it does not define what happens in
underflow and overflow situations.

  V3 is actually a little more explicit. It defines the conversions
between ANY_BIT to ANY_INT (and vice versa) as binary transfer (of right
most bytes, either throwing away or setting to zero left most bits when
sizes do not match).

  However, even v3 is silent in relation to conversions between ANY_REAL
and ANY_BIT. My opinion is that we should follow the spirit of the other
functions and do binary transfer as well.



> But probably we are not going to change behavior of these functions
> anyway.
> First, it'll break existing Beremiz programs. Second, IMHO current
> implementation is logical. *_TO_*  functions are just simple type
> casting function. In CODESYS these functions have the same behavior.

  Actually, I kind of disagree with the last poster (Andrey?).

  I agree with Denis that the binary transfer method makes more sense
than handling the ANY_BIT data types as ANY_INT when doing the
conversion. It seems that v3 also seems to agree.

  I vote for changing the behaviour of the matiec standard functions.

  However, I think we need to come up with a versioning method/rules for
matiec that makes it obvious that it may break backward compatibility
(instead of fixing obvious bugs). I have never bothered with versioning
of matiec (although the code is there already, always set to version
0.1). I guess it is time to start treating this correctly? Up to now I
have simply been using the mercurial repository's version which is also
automatically output/printed when you run 'iec2c -v'.


> I know DWORD_TO_REAL works differently in Step7.
> And I agree with you that this function is very useful. But
> unfortunately it's not defined in the standard. I'll add it to
> additional function blocks Beremiz library.
> Any suggestion for the name of function are welcome? :-)

  I vote to change the way the standard functions work.
  I would like to hear what you all think.
  Andrey, have you by any chance changed your opinion?

>
> Mario, have you read the third edition of the standard?
> Does it have any clarification for [DL]WORD_TO_REAL and
> REAL_TO_[DL]WORD? Has it description of any special function
> for this kind of conversions?
>

  Answered above...
  It does not specify REAL_TO_WORD, but it does specify INT_TO_WORD et
al. I think we should follow the same spirit when implementing
REAL_TO_WORD.

>> What about pointers and C-injections... Ok, that's working solution,
>> but... Isn't whole 61131-3 about languages that's main purpose is
>> support engineers, who perfectly knows tech-flow, but not programming?
>> We must bring them tools which are absolutely abstract from internal
>> machine processes. I think that pointers and alien injections kills
>> good
>> ideas of 61131.
> Denis, I agree with you, but pointers and a lot of other stuff are now
> officially part of IEC-61131-3 standard (see changes in the third
> edition).
>

  Yep. I implemented pointers using the syntax defined in v3. You can say
the matiec implements a very limited part of v3. However, and I am not
absolutely sure at the moment, but I think the void pointer equivalent
is a matiec extension (not in v3).



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

Re: [Beremiz-devel] REAL as DWORD representation.

Beremiz-Devel mailing list
Hi Mario,

On 17-08-01 07:32, [hidden email] wrote:

>
>
>  Hi Andrey & Denis
>
> On 31.07.2017 16:52, [hidden email] wrote:
> > On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:
> > > > Hi Denis,
> > > Hello, Mario!
> > > >> First of all, I tryed to use Type-converion blocks (or functions on ST)
> > > >> like REAL_TO_DWORD... And I wonder, there only integer part on result!
> > > >  What else did you expect? How do you want to store a decimal part in an
> > > > integer type variable?
> > > Of Course, not :)
>
>  OK. I read your explanation further on and I now understand your logic. I
> actually agree with you!
>
> > > >>> Is it really need to somebody, to make TRUNC while just convertion to
> > > >>> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
> > > >>> operation like shift-left or right, get HI or LOW byte...
> > > >  Can you explain more clearly what it is you want?
> > > >  I did not understand... Sorry!
> > > I must apologize, my English is terrible...
>
>  Nope, not really. I understood your second explanation perfectly!
>  Your first explanation includes a non explicit assumption that I was unable
> to figure out (yes, sometimes I am slow in understanding because I take
> things a little too literally- my wife hates this about me).
>
> > > >  I wrote an extension to matiec that allows matiec to support pointers. I
> > > > think it also supports pointers to void (or equivalent). It may be possible to
> > > > do what you want using pointers, but if you want to do it very often I would
> > > > go with what Andrey suggested, i.e. simply create your own function.
> > > Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
> > > number yet, just two bytes and in another words 65536 conditions of
> > > whatever i want, it's it? That's why I can't agree with you. If we
> > > convert REAL (4 bytes) to, for example DWORD, we just get REAL as
> > > bit-field and set it accordingly to DWORD. IMHO, something other is
> > > senselessly, because if we want to get integer part of real - we have
> > > TRUNC function and should get something from <ANY_NUM> to assign a
> > > result. I think such behavior get us mach more capabilities.
> > By the way, REAL_TO_INT works slightly different than TRUNC (see
> > IEC-61131-3 section 2.5.1.5.1 Type conversion functions).
> >
> > Standard doesn't explicitly says how [DL]WORD_TO_REAL and
> > REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
> > information about that in the second edition of the standard. I don't
> > have access to the third edition.
>
>
>  Yep, this is what I remember from the standard too.
>
>  I just browsed through the standard (v2) to be absolutely sure, and can
> confirm. It merely defines how to round when converting REAL/LREAL to
> INT/LINT/UINT... However, even then it does not define what happens in
> underflow and overflow situations.
>
>  V3 is actually a little more explicit. It defines the conversions between
> ANY_BIT to ANY_INT (and vice versa) as binary transfer (of right most bytes,
> either throwing away or setting to zero left most bits when sizes do not
> match).
That's very good, that they are far more explicit now than in V2.


>  However, even v3 is silent in relation to conversions between ANY_REAL and
> ANY_BIT. My opinion is that we should follow the spirit of the other
> functions and do binary transfer as well.
It seems reasonable.

> > But probably we are not going to change behavior of these functions
> > anyway.
> > First, it'll break existing Beremiz programs. Second, IMHO current
> > implementation is logical. *_TO_*  functions are just simple type
> > casting function. In CODESYS these functions have the same behavior.
>
>  Actually, I kind of disagree with the last poster (Andrey?).
>
>  I agree with Denis that the binary transfer method makes more sense than
> handling the ANY_BIT data types as ANY_INT when doing the conversion. It
> seems that v3 also seems to agree.
>
>  I vote for changing the behaviour of the matiec standard functions.

>  However, I think we need to come up with a versioning method/rules for
> matiec that makes it obvious that it may break backward compatibility
> (instead of fixing obvious bugs). I have never bothered with versioning of
> matiec (although the code is there already, always set to version 0.1). I
> guess it is time to start treating this correctly? Up to now I have simply
> been using the mercurial repository's version which is also automatically
> output/printed when you run 'iec2c -v'.
Probably we should and maintain the list of introduced
incompatibilities as well.
Unfortunately now Beremiz doesn't store in the project any information about used matiec version.

> > I know DWORD_TO_REAL works differently in Step7.
> > And I agree with you that this function is very useful. But
> > unfortunately it's not defined in the standard. I'll add it to
> > additional function blocks Beremiz library.
> > Any suggestion for the name of function are welcome? :-)
>
>  I vote to change the way the standard functions work.
>  I would like to hear what you all think.
>  Andrey, have you by any chance changed your opinion?
I don't like changing behaviour without a reason and following
the standard seems to me reasonable enough.
But I still have very mixed feeling about introducing this kind of backward
incompatibility for ANY_BIT to ANY_REAL conversion not even described in
the standard.

I think that standard working group intentionally
haven't covered ANY_BIT to ANY_REAL case. 3S (company behind CODESYS) participated in the
standard development. Siemens probably (I'm not sure) did as well.
Because several member of the working group already have different
implementation and don't want introduce incompatibility for their
products, they just omitted this case in the standard and all parts
were happy.
Mario, do you have any contact to working group? Probably they could clarify this case.

Any other opinion?


--
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] REAL as DWORD representation.

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

 I agree with Denis that the binary transfer method makes more sense than handling the ANY_BIT data types as ANY_INT when doing the conversion. It seems that v3 also seems to agree.

I agree with Denis and Mario.

However, I think we need to come up with a versioning method/rules...
I guess it is time to start treating this correctly?
 
How about http://semver.org/ ?

BTW we still have 2038 problem ahead, so breaking changes should be made in mid term!

Best regards,
Paul Beltyukov

2017-08-01 11:32 GMT+05:00 <[hidden email]>:


 Hi Andrey & Denis

On 31.07.2017 16:52, [hidden email] wrote:
On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:
> Hi Denis,
Hello, Mario!
>> First of all, I tryed to use Type-converion blocks (or functions on ST)
>> like REAL_TO_DWORD... And I wonder, there only integer part on result!
>  What else did you expect? How do you want to store a decimal part in an
> integer type variable?
Of Course, not :)

 OK. I read your explanation further on and I now understand your logic. I actually agree with you!

>>> Is it really need to somebody, to make TRUNC while just convertion to
>>> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
>>> operation like shift-left or right, get HI or LOW byte...
>  Can you explain more clearly what it is you want?
>  I did not understand... Sorry!
I must apologize, my English is terrible...

 Nope, not really. I understood your second explanation perfectly!
 Your first explanation includes a non explicit assumption that I was unable to figure out (yes, sometimes I am slow in understanding because I take things a little too literally- my wife hates this about me).

>  I wrote an extension to matiec that allows matiec to support pointers. I
> think it also supports pointers to void (or equivalent). It may be possible to
> do what you want using pointers, but if you want to do it very often I would
> go with what Andrey suggested, i.e. simply create your own function.
Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
number yet, just two bytes and in another words 65536 conditions of
whatever i want, it's it? That's why I can't agree with you. If we
convert REAL (4 bytes) to, for example DWORD, we just get REAL as
bit-field and set it accordingly to DWORD. IMHO, something other is
senselessly, because if we want to get integer part of real - we have
TRUNC function and should get something from <ANY_NUM> to assign a
result. I think such behavior get us mach more capabilities.
By the way, REAL_TO_INT works slightly different than TRUNC (see
IEC-61131-3 section 2.5.1.5.1 Type conversion functions).

Standard doesn't explicitly says how [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
information about that in the second edition of the standard. I don't
have access to the third edition.


 Yep, this is what I remember from the standard too.

 I just browsed through the standard (v2) to be absolutely sure, and can confirm. It merely defines how to round when converting REAL/LREAL to INT/LINT/UINT... However, even then it does not define what happens in underflow and overflow situations.

 V3 is actually a little more explicit. It defines the conversions between ANY_BIT to ANY_INT (and vice versa) as binary transfer (of right most bytes, either throwing away or setting to zero left most bits when sizes do not match).

 However, even v3 is silent in relation to conversions between ANY_REAL and ANY_BIT. My opinion is that we should follow the spirit of the other functions and do binary transfer as well.



But probably we are not going to change behavior of these functions anyway.
First, it'll break existing Beremiz programs. Second, IMHO current
implementation is logical. *_TO_*  functions are just simple type
casting function. In CODESYS these functions have the same behavior.

 Actually, I kind of disagree with the last poster (Andrey?).

 I agree with Denis that the binary transfer method makes more sense than handling the ANY_BIT data types as ANY_INT when doing the conversion. It seems that v3 also seems to agree.

 I vote for changing the behaviour of the matiec standard functions.

 However, I think we need to come up with a versioning method/rules for matiec that makes it obvious that it may break backward compatibility (instead of fixing obvious bugs). I have never bothered with versioning of matiec (although the code is there already, always set to version 0.1). I guess it is time to start treating this correctly? Up to now I have simply been using the mercurial repository's version which is also automatically output/printed when you run 'iec2c -v'.


I know DWORD_TO_REAL works differently in Step7.
And I agree with you that this function is very useful. But
unfortunately it's not defined in the standard. I'll add it to
additional function blocks Beremiz library.
Any suggestion for the name of function are welcome? :-)

 I vote to change the way the standard functions work.
 I would like to hear what you all think.
 Andrey, have you by any chance changed your opinion?


Mario, have you read the third edition of the standard?
Does it have any clarification for [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD? Has it description of any special function
for this kind of conversions?


 Answered above...
 It does not specify REAL_TO_WORD, but it does specify INT_TO_WORD et al. I think we should follow the same spirit when implementing REAL_TO_WORD.

What about pointers and C-injections... Ok, that's working solution,
but... Isn't whole 61131-3 about languages that's main purpose is
support engineers, who perfectly knows tech-flow, but not programming?
We must bring them tools which are absolutely abstract from internal
machine processes. I think that pointers and alien injections kills good
ideas of 61131.
Denis, I agree with you, but pointers and a lot of other stuff are now
officially part of IEC-61131-3 standard (see changes in the third edition).


 Yep. I implemented pointers using the syntax defined in v3. You can say the matiec implements a very limited part of v3. However, and I am not absolutely sure at the moment, but I think the void pointer equivalent is a matiec extension (not in v3).



 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


------------------------------------------------------------------------------
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] REAL as DWORD representation.

Beremiz-Devel mailing list
Hi!

Sorry for my gmail web interface!

I agree with Denis that the binary transfer method makes more sense than handling the ANY_BIT data types as ANY_INT when doing the conversion. It seems that v3 also seems to agree.
 
I agree with Denis and Mario.

However, I think we need to come up with a versioning method/rules... 
I guess it is time to start treating this correctly?
 
How about http://semver.org/ ?

BTW we still have 2038 problem ahead, so breaking changes should be made in mid term!

Best regards,
Paul Beltyukov

2017-08-01 17:58 GMT+05:00 <[hidden email]>:
Hi!

 I agree with Denis that the binary transfer method makes more sense than handling the ANY_BIT data types as ANY_INT when doing the conversion. It seems that v3 also seems to agree.

I agree with Denis and Mario.

However, I think we need to come up with a versioning method/rules...
I guess it is time to start treating this correctly?
 
How about http://semver.org/ ?

BTW we still have 2038 problem ahead, so breaking changes should be made in mid term!

Best regards,
Paul Beltyukov

2017-08-01 11:32 GMT+05:00 <[hidden email]>:


 Hi Andrey & Denis

On 31.07.2017 16:52, [hidden email] wrote:
On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:
> Hi Denis,
Hello, Mario!
>> First of all, I tryed to use Type-converion blocks (or functions on ST)
>> like REAL_TO_DWORD... And I wonder, there only integer part on result!
>  What else did you expect? How do you want to store a decimal part in an
> integer type variable?
Of Course, not :)

 OK. I read your explanation further on and I now understand your logic. I actually agree with you!

>>> Is it really need to somebody, to make TRUNC while just convertion to
>>> <ANY_BIT>? I thought, that <ANY_BIT> type is just for bit-field
>>> operation like shift-left or right, get HI or LOW byte...
>  Can you explain more clearly what it is you want?
>  I did not understand... Sorry!
I must apologize, my English is terrible...

 Nope, not really. I understood your second explanation perfectly!
 Your first explanation includes a non explicit assumption that I was unable to figure out (yes, sometimes I am slow in understanding because I take things a little too literally- my wife hates this about me).

>  I wrote an extension to matiec that allows matiec to support pointers. I
> think it also supports pointers to void (or equivalent). It may be possible to
> do what you want using pointers, but if you want to do it very often I would
> go with what Andrey suggested, i.e. simply create your own function.
Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
number yet, just two bytes and in another words 65536 conditions of
whatever i want, it's it? That's why I can't agree with you. If we
convert REAL (4 bytes) to, for example DWORD, we just get REAL as
bit-field and set it accordingly to DWORD. IMHO, something other is
senselessly, because if we want to get integer part of real - we have
TRUNC function and should get something from <ANY_NUM> to assign a
result. I think such behavior get us mach more capabilities.
By the way, REAL_TO_INT works slightly different than TRUNC (see
IEC-61131-3 section 2.5.1.5.1 Type conversion functions).

Standard doesn't explicitly says how [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
information about that in the second edition of the standard. I don't
have access to the third edition.


 Yep, this is what I remember from the standard too.

 I just browsed through the standard (v2) to be absolutely sure, and can confirm. It merely defines how to round when converting REAL/LREAL to INT/LINT/UINT... However, even then it does not define what happens in underflow and overflow situations.

 V3 is actually a little more explicit. It defines the conversions between ANY_BIT to ANY_INT (and vice versa) as binary transfer (of right most bytes, either throwing away or setting to zero left most bits when sizes do not match).

 However, even v3 is silent in relation to conversions between ANY_REAL and ANY_BIT. My opinion is that we should follow the spirit of the other functions and do binary transfer as well.



But probably we are not going to change behavior of these functions anyway.
First, it'll break existing Beremiz programs. Second, IMHO current
implementation is logical. *_TO_*  functions are just simple type
casting function. In CODESYS these functions have the same behavior.

 Actually, I kind of disagree with the last poster (Andrey?).

 I agree with Denis that the binary transfer method makes more sense than handling the ANY_BIT data types as ANY_INT when doing the conversion. It seems that v3 also seems to agree.

 I vote for changing the behaviour of the matiec standard functions.

 However, I think we need to come up with a versioning method/rules for matiec that makes it obvious that it may break backward compatibility (instead of fixing obvious bugs). I have never bothered with versioning of matiec (although the code is there already, always set to version 0.1). I guess it is time to start treating this correctly? Up to now I have simply been using the mercurial repository's version which is also automatically output/printed when you run 'iec2c -v'.


I know DWORD_TO_REAL works differently in Step7.
And I agree with you that this function is very useful. But
unfortunately it's not defined in the standard. I'll add it to
additional function blocks Beremiz library.
Any suggestion for the name of function are welcome? :-)

 I vote to change the way the standard functions work.
 I would like to hear what you all think.
 Andrey, have you by any chance changed your opinion?


Mario, have you read the third edition of the standard?
Does it have any clarification for [DL]WORD_TO_REAL and
REAL_TO_[DL]WORD? Has it description of any special function
for this kind of conversions?


 Answered above...
 It does not specify REAL_TO_WORD, but it does specify INT_TO_WORD et al. I think we should follow the same spirit when implementing REAL_TO_WORD.

What about pointers and C-injections... Ok, that's working solution,
but... Isn't whole 61131-3 about languages that's main purpose is
support engineers, who perfectly knows tech-flow, but not programming?
We must bring them tools which are absolutely abstract from internal
machine processes. I think that pointers and alien injections kills good
ideas of 61131.
Denis, I agree with you, but pointers and a lot of other stuff are now
officially part of IEC-61131-3 standard (see changes in the third edition).


 Yep. I implemented pointers using the syntax defined in v3. You can say the matiec implements a very limited part of v3. However, and I am not absolutely sure at the moment, but I think the void pointer equivalent is a matiec extension (not in v3).



 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


------------------------------------------------------------------------------
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] REAL as DWORD representation.

Beremiz-Devel mailing list
In reply to this post by Beremiz-Devel mailing list
On 17-08-01 11:15, [hidden email] wrote:

> Hi Mario,
>
> On 17-08-01 07:32, [hidden email] wrote:
> >
> >
> >  Hi Andrey & Denis
> >
> > On 31.07.2017 16:52, [hidden email] wrote:
> > > On 17-07-31 16:09, beremiz-devel--- via Beremiz-devel wrote:
> > > > > Hi Denis,
> > > > Hello, Mario!
> > > > >> First of all, I tryed to use Type-converion blocks (or functions on ST)
> > > > >> like REAL_TO_DWORD... And I wonder, there only integer part on result!
> > > > >  What else did you expect? How do you want to store a decimal part in an
> > > > > integer type variable?
> > > > Of Course, not :)
> >
> >  OK. I read your explanation further on and I now understand your logic. I
> > actually agree with you!
> >
...

> > > > >  I wrote an extension to matiec that allows matiec to support pointers. I
> > > > > think it also supports pointers to void (or equivalent). It may be possible to
> > > > > do what you want using pointers, but if you want to do it very often I would
> > > > > go with what Andrey suggested, i.e. simply create your own function.
> > > > Ok... From beginning... WORD type is <ANY_BIT> in general, it is not a
> > > > number yet, just two bytes and in another words 65536 conditions of
> > > > whatever i want, it's it? That's why I can't agree with you. If we
> > > > convert REAL (4 bytes) to, for example DWORD, we just get REAL as
> > > > bit-field and set it accordingly to DWORD. IMHO, something other is
> > > > senselessly, because if we want to get integer part of real - we have
> > > > TRUNC function and should get something from <ANY_NUM> to assign a
> > > > result. I think such behavior get us mach more capabilities.
> > > By the way, REAL_TO_INT works slightly different than TRUNC (see
> > > IEC-61131-3 section 2.5.1.5.1 Type conversion functions).
> > >
> > > Standard doesn't explicitly says how [DL]WORD_TO_REAL and
> > > REAL_TO_[DL]WORD should work (unfortunately). At least I couldn't find
> > > information about that in the second edition of the standard. I don't
> > > have access to the third edition.
> >
> >
> >  Yep, this is what I remember from the standard too.
> >
> >  I just browsed through the standard (v2) to be absolutely sure, and can
> > confirm. It merely defines how to round when converting REAL/LREAL to
> > INT/LINT/UINT... However, even then it does not define what happens in
> > underflow and overflow situations.
> >
> >  V3 is actually a little more explicit. It defines the conversions between
> > ANY_BIT to ANY_INT (and vice versa) as binary transfer (of right most bytes,
> > either throwing away or setting to zero left most bits when sizes do not
> > match).
> That's very good, that they are far more explicit now than in V2.
>
...

> > > I know DWORD_TO_REAL works differently in Step7.
> > > And I agree with you that this function is very useful. But
> > > unfortunately it's not defined in the standard. I'll add it to
> > > additional function blocks Beremiz library.
> > > Any suggestion for the name of function are welcome? :-)
> >
> >  I vote to change the way the standard functions work.
> >  I would like to hear what you all think.
> >  Andrey, have you by any chance changed your opinion?
> I don't like changing behaviour without a reason and following
> the standard seems to me reasonable enough.
> But I still have very mixed feeling about introducing this kind of backward
> incompatibility for ANY_BIT to ANY_REAL conversion not even described in
> the standard.
>
> I think that standard working group intentionally
> haven't covered ANY_BIT to ANY_REAL case. 3S (company behind CODESYS) participated in the
> standard development. Siemens probably (I'm not sure) did as well.
> Because several member of the working group already have different
> implementation and don't want introduce incompatibility for their
> products, they just omitted this case in the standard and all parts
> were happy.
> Mario, do you have any contact to working group? Probably they could clarify this case.

I think it's better to leave ANY_BIT to ANY_REAL conversion like it's now for
practical reasons.

1. This conversion functions are not defined in the standard (and probably never
will, because of the reason described above). So there is actually not much
reason to change current behavior, except nice new logic, that we *all* like.

2. Major players already have different implementation of these
function. Most likely they'll not change it in the near future either.
Beremiz/matiec users from one or another camp will certainly
complain, that ANY_BIT to ANY_REAL doesn't work as they expect,
regardless of our choice.

3. If we change implementation, we don't gain anything. Do we? Just break
existing programs of our current users.

4. Current implementation work as in CODESYS.
CODESYS supports import/export of plcopen xml. Currently Beremiz couldn't open exported
from CODESYS file, because some required by Beremiz tags are missing.
But I'd like to fix this in the future.

Does STEP 7 supports export to plcopen xml? I searched a bit on the
Internet and it seems to me that it's *not*.
Allen Bradley has *no* plcopen xml support either.
If I wrong about plcopen xml support, please correct me.

If we leave our implementation as is and improve plcopen import from
CODESYS (or they fix their export :-) ), then it'd be easier to move
POUs from *any* CODESYS-based PLC to Beremiz.



Is DWORD bit-stream to REAL conversion useful? Yes!
Are we needed it? Yes!
Are we going to add it to Beremiz? Yes!

My suggestion is:
- leave current implementation as is;
- add new conversion function;
- make iec2c generate warning for DWORD_TO_REAL/REAL_TO_WORD function like this
  "This is non-standard conversion. It's not portable and isn't recommended for use.
  Different PLC vendors may have different implementation of it.".


--
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] REAL as DWORD representation.

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

On 17-08-01 17:58, [hidden email] wrote:
>
> However, I think we need to come up with a versioning method/rules...
>> I guess it is time to start treating this correctly?
>
> How about http://semver.org/ ?
This is what I'd recommend as well.
And IMHO on every compatibility change (major release) should be made
a new branch. So people could easily find commits introduced
incompatibility and backport to this branch some fixes from
development branch.

>
> BTW we still have 2038 problem ahead, so breaking changes should be made in
> mid term!

This is a different story. It doesn't break user programs actually, so
no compatibility problems here.
This problem is more for PLC vendors. And because PLC vendors supply
their (hopefully tested version) of Beremiz/matiec, then it's hidden
from users. Question with 2038 problem is more how we get attention of
PLC vendors to the problem and our fix and how to guide them
to apply the fix for 2038y problem in their future products.

...

> >  However, I think we need to come up with a versioning method/rules for
> > matiec that makes it obvious that it may break backward compatibility
> > (instead of fixing obvious bugs). I have never bothered with versioning of
> > matiec (although the code is there already, always set to version 0.1). I
> > guess it is time to start treating this correctly? Up to now I have simply
> > been using the mercurial repository's version which is also automatically
> > output/printed when you run 'iec2c -v'.
> >

...

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