You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2020/10/25 20:59:04 UTC
Doing some read-tests with S7
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
Re: Doing some read-tests with S7
Posted by Stefano Bossi <st...@gmail.com>.
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" <ch...@c-ware.de>:
>
> 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
>
>
>
Re: Doing some read-tests with S7
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hey Chris,
Sadly I do not find the time to push that forward at the moment, sorry : /
Julian
Am 26.10.20, 20:07 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi folks
Guess the "String(10)[3]" issue is going to be a tricky one :-(
Perhaps it's easier for me to also implement the automatic splitting of items that are itself too big for one packet.
I was hoping on the proposed generic optimizer, but I guess I better get working on this myself and implement some basic rules manually.
Or @Julian Feinauer ... any progress/plans for this?
Chris
Am 25.10.20, 23:42 schrieb "Christofer Dutz" <ch...@c-ware.de>:
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" <ch...@c-ware.de>:
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
Re: Doing some read-tests with S7
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi folks
Guess the "String(10)[3]" issue is going to be a tricky one :-(
Perhaps it's easier for me to also implement the automatic splitting of items that are itself too big for one packet.
I was hoping on the proposed generic optimizer, but I guess I better get working on this myself and implement some basic rules manually.
Or @Julian Feinauer ... any progress/plans for this?
Chris
Am 25.10.20, 23:42 schrieb "Christofer Dutz" <ch...@c-ware.de>:
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" <ch...@c-ware.de>:
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
Re: Doing some read-tests with S7
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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