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
