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
