As we are proposing a breaking change, I would suggest to prepare a vote thread ... we definitely need to practice stuff like this here ;-)
I know the user-base is still quite limited (I would be more than happy to hear
it's not), so I guess we would not be making too many people mad.
Chris
Am 03.08.18, 14:47 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Hey,
indeed you are right with the redundancy but I also think that it makes
thinks simpler and more robust.
When we speak about TIA programming we usually refer to archaic programming
; )
Are there any other opinions of the community to this topic?
Otherwise I would suggest that someone prepares a demonstrator for this
feature to play around a bit (we could do that, I guess).
Julian
Am 03.08.18, 14:15 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Julian,
I just double checked and created some more variables. Seems you are
correct and the naming in the address only refers to the size of the
data-element referenced.
So both a DINT and a REAL consume 4 bytes in memory and therefore both
are called something DBW2 ... wonder where TIA gets the types, probably because
it's so "totally integrated" ;-)
Adding more information, like you suggested, does add some sort of
redundancy as REAL at the end implies the DBD prefix, but I think for the sake
of simplicity it's still good to do that.
But in that case, I would also add the BOOL to the Boolean value.
By the way ... found this:
http://www.kleissler-online.de/SPS_Downloads-Dateien/Zahlenformate%20TIA.pdf
German, but still helpful as even non-German speakers will know how to
read it.
Chris
Am 03.08.18, 13:47 schrieb "Julian Feinauer"
<j.feina...@pragmaticminds.de>:
Hey Chris,
this is an excellent idea and will make it a lot easier to
translate TIA programs to Plc4X code as it makes this really copy and paste
(and of course we know Hurz).
We also had a look into TIA and it seems that the D stands for
Double Word (i.e. 4 Bytes) and the B for single Byte.
Thus, we think that this "only" covers the complete address, i.e.,
offset + length.
So this should additionally be combined (in my opinion) with the
type information, e.g. using a string like that:
HurzBoolean (Bool): %DB3.DBX0.0
HurzInteger (Int): %DB3.DBW2:INT
HurzReal (Real) %DB3.DBD4:REAL
HurzByte (Byte) %DB3.DBB8:BYTE
Where we have a mapping table (as in my original suggestion but
only without the bit width) which indicates if it is
* integer / decimal
* signed / unsigned
* ... ?
Of course we can keep the possibility to omit the type information
and inject some sensible defaults based on the given Class<?>, basically the
same behavior as we currently have.
What do you all think of this approach?
Julian
PS.:
@chris I think you misunderstood my last mail slightly, the number
in the address string was meant to encapsulate the bit width of the datatype
not the Items size parameter. This should definitely stay where it is and stay
orthogonal to addressing.
Am 03.08.18, 11:39 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Julian,
you bring up something I was thinking about quite some time ago
but didn't address till now as it was one of the things we could "do later"(TM)
I started off writing the S7 as the first driver for PLC4X and
didn't want to use complicated syntax I could see in TIA for example. So I
decided to use this simpler "AREA/STARTING_ADDRESS[.BIT_OFFSET]" format.
Thinking of it later however made me realize that this might
not have been such a good idea.
The thing is that TIA is the only place where S7 programs are
written. So why not use exactly this format for defining the addresses?
And this format contains type information.
I created a data-block for example with different types (Ignore
the "Hurz"... it has absolutely no meaning for people that don't know that
famous sketch of Hape Kerkeling):
HurzBoolean (Bool): %DB3.DBX0.0
HurzInteger (Int): %DB3.DBW2
HurzReal (Real) %DB3.DBD4
HurzByte (Byte) %DB3.DBB8
In this case: X seems to imply Boolean, W (word) two bytes, D
implies Real (Double) and B implies Byte.
When using digital inputs (%I0.1) and outputs (%M0.3) or analog
inputs (%IW64) we would have to implement how to interpret these types (Knowing
a I without a W is a Boolean and an IW is an UInt (4 bytes)
So it seems that we could change the format to this and would
have as a bonus, that we could read the lists a electro engineer gives us.
However we would still have to extend the Address items for S7
to contain the PLC type, which I think is a cool solution.
I would leave the API unchanged. Providing the Java result-type
and the number of items. I could imagine a lot of places where the number of
items is a variable and serializing this to a string and parsing that back
again seems not that ideal. This way we could do a check to see if the
requested return type is compatible with the address type and implement the
mapping.
What do you think?
Chris
Am 02.08.18, 21:36 schrieb "Julian Feinauer"
<j.feina...@pragmaticminds.de>:
Hi Chris,
an additional flag in the items was also my first idea, but
after thinking about it a bit I dislike it.
First, because it "breaks" the encapsulation we currently
have between "Java" Information (Class<?>) and Plc Information (Address) and
second between it is not very scalable when we come up with other "traits" of
the byte representation (e.g., Endianness).
As I really like this "you only need a suitable String to
address the PLC and the Driver will work it out at runtime" approach which
really eases applications as you only need one config string from file or DB or
so this is another drawback for the "additional flag" approach.
What I would prefer currently is to encode this Information
in the Address which is already the only point which is PLC Specific.
My idea is to add an (optional) postfix to the address
which allows to pass informations about the storage representation of Data,
e.g.,
- width
- Traits like
- unsigned
- decimal
- endianness
- ...
An example would be
"FLAGS/0/0:8U"
To Address an unsigned Byte at Offset zero.
To make it even easier to users we could provide Plc
specific enums like the MemoryArea enum where "typical" types can be predefined
that are also allowed as postfix.
Then, the Adress could become
"FLAGS/0/0:USINT"
This would lead to a good level of encapsulation as I could
go to my S7 programmer and ask him to give me this string for all values I'm
interested in and its totally in his "ubiquitous language" (yay, DDD trending).
The enum would be something like this (S7 case):
public enum S7NativeRepresentations {
SINT(new
Representation(8,Collections.singletonList(Representation.Trait.SIGNED))),
USINT(new
Representation(8,Collections.singletonList(Representation.Trait.UNSIGNED))),
INT(new
Representation(16,Collections.singletonList(Representation.Trait.SIGNED))),
UINT(new
Representation(16,Collections.singletonList(Representation.Trait.UNSIGNED))),
DINT(new
Representation(32,Collections.singletonList(Representation.Trait.SIGNED))),
UDINT(new
Representation(32,Collections.singletonList(Representation.Trait.UNSIGNED))),
REAL(new Representation(32,
Collections.singletonList(Representation.Trait.DECIMAL))),
LREAL(new Representation(64,
Collections.singletonList(Representation.Trait.DECIMAL)));
private Representation representation;
S7NativeRepresentations(Representation
representation) {
this.representation = representation;
}
}
Where the Representation class and the Trait enum are
"Global" for all PLCs and are only interpreted at runtime for the casting by
each PLC.
This would allow a general handling of the "representation"
and address suffixes but with the additional flexibility of Plc type specific
"Shortcuts".
As I currently see a lot of advantages with this approach
its up to you to find the drawbacks : )
What do all of you think of this Idea?
Julian
PS.: With this information given we could give users also
the flexibility to request the Java Type they need and could take care of
widening / narrowing or conversion internally.
Am 02.08.18, 19:04 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Julian,
I do get your point and do agree that there could be
problems.
Just an idea ... How about an optional field "signed"
in the items which defaults to false?
It seems handling the signed and unsignedness of an
item simply by the type could be a bad idea, the more I think of it.
We should also clearly define and document the expected
types and their sizes and use the same for all drivers.
What do you all think about this?
Chris
Outlook for Android<https://aka.ms/ghei36> herunterladen
Von: Julian Feinauer
Gesendet: Donnerstag, 2. August, 17:14
Betreff: Re: Handling of signed / unsigned values
An: dev@plc4x.apache.org
Hi Chris, I think we have both different approaches and
views. I totally agree with you that it should be as straight forward and easy
for users of the API to use Plc4x. But, as far as my understanding goes, we are
missing some information which we need for the user. The following example is
with regard to S7. Assume we have a datablock with two values in it (and
nothing more), one int (as S7 int -> 2 bytes) and one unsigned int (again 2
bytes), i.e., ------------- | int | uint | ------------- We usually get TIA
programs and then write our java application (or configuration) to read values
from the device. So, if I am not carefully I see Int and do:
PlcReadRequest(Integer.class, ".../0") PlcReadRequest(Integer.class, ".../2")
Which would lead to one wrong result (as the Integer is casted from 4 bytes)
and one Exception (Unknown Memory, I think, as we cross the DB boundary because
we try to read 4 bytes from offset 2). Then, I see my failure and take Javas
Short: PlcReadRequest(Short.class, ".../0") PlcReadRequest(Short.class,
".../2") So no exception here. But I get one correct value (first one) and one
wrong one (the cast to short assumes a signed representation). From a java
perspective I should do PlcReadRequest(Short.class, ".../0")
PlcReadRequest(Integer.class, ".../2") Because the second unsigned int (S7
UINT) is greater than java Short, but fits perfetctly in Javas Integer. But of
couse, this would give again an exception. From my perspective, the point
missing here is some sort of Shema which helps PLC4J to know the datatype in
the PLC behind the scenes and takes care of all the narrowing or widening (or
even conversion between integer and float types) in the background for me (in
fact we could possibly return valid results for all 3 examples if the UINT is
small enough, otherwise only the second example would fail). So my question
about signed and unsigned is less about representation bot more about how we
tell the S7Protocoll how to cast the respective byte array that is returned
from the Plc. I hope this makes my question more clear. Julian Am 02.08.18,
11:33 schrieb "Christofer Dutz" : Hi Julian, regarding your question. As far as
I have encountered, PLCs mostly transfer unsigned values and Java usually uses
signed values ... this could generally cause problems. Fortunately as far as I
know the size of the Java types is usually way bigger than the one of the PLC
types. In case of the Int: The Siemens S7 Int datatypes is two bytes and the
Java Integer is a 32 bit integer, therefore we don't have to confuse our users
with any type problems. If however a PLC would use 32 bit integers we would be
having problems. In this case we would have to use the next smaller datatype
that fits our requested datatype. So in this case reading a "Java Integer"
would read a "PLC Short". I wouldn't like to have the user have to think of the
PLC datatypes when writing his code. Chris Am 02.08.18, 11:17 schrieb "Julian
Feinauer" : Hey all, again me with another question : ) I started going through
some examples on our PLC and came to a situation where we use signed and
unsigned values in the PLC. This goes kind of back to my type system question.
How could I tell the Reader to read me an Unsigned Int from a S7 (Usigned Int
refers in this case to a two byte value on the PLC but return type had to be
Int in Java). Is there some mechanism in Place to be able to do such a Thing?
Or if not, do you have any ideas already in mind how one could introduce this
(technically it's clear but how to give the information that we want our
expected int to be read and interpreted as 2 byte unsigned)? Best Julian
