Hi Chris, the STRING(x)[] stuff was something you implemented on the issue I have opened a month ago or more; unfortunately my first work suck all my time and I don't have any time to try to code for your library.
Yes the splitting issue is generalized for all the datatype and for reading large datablock. Sorry for that, hope to have more time in the Christmas holidays. Thanks again for your work. Ciao, S. On 25/10/2020 23:42, Christofer Dutz wrote: > Ok ... so I fixed most of the issues. > > So-far the problems I need to address are the following: > > - When using "BOOL[]" we have to read a bit-string (byte, word, dword) > instead and filter out the bits that are not asked for. > - When reading "STRING(x)[]" (limited strings), we have to split up the > request into multiple items as the typical array notation doesn't work. > - When reading bit-strings the order of the bits looks the wrong way around > - When reading bit-string arrays, I would like to concatenate the values to > one bit-string instead of returning lists of lists > > Chris > > > > > Am 25.10.20, 21:59 schrieb "Christofer Dutz" <[email protected]>: > > Hi all, > > in order to have some good tests for the S7 protocol, I defined a lot of > variables in one of the data-blocks of one of my S7 devices. > I then created a little test program that should simply use this to read > all sorts of types of elements. > With these tests I found some things: > > > * In general all Bit-String operations, when reading arrays, produce > lists of lists … I think it would be cooler if for bit-strings they would > return one large List > * STRING handling seems to be messed up again > * When reading a BOOL array, it seems the S7 only returns the first > bit (I would have expected it to send up to 8 bits in one byte and after that > to add more bytes, but it’s always just one and that always just contains the > first bit) -> We need to translate BOOL-array reads into bit-string > operations which return partial lists. > * Reading of DATE_AND_TIME arrays seems to be messed up as only the > first item is correct and the succeeding elements are always “null” > * Reading of CHAR values seems messed up > > I’ll be working on addressing this asap > > Chris > > >
signature.asc
Description: OpenPGP digital signature
