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
