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" <christofer.d...@c-ware.de>:
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" <j.feina...@pragmaticminds.de>:
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
