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
