Re: [RESULT] [VOTE] Rename our "master" branch to "release"

2020-07-03 Thread Christofer Dutz 
Ok,

Just got the confirmation. I have to create the new branch, have infra unlock 
the old and then I can delete it.

Chris

Von: Christofer Dutz 
Gesendet: Freitag, 3. Juli 2020 19:28
An: dev@plc4x.apache.org 
Betreff: Re: [RESULT] [VOTE] Rename our "master" branch to "release"

I'm not sure there is no tooling from infra...

Von: Julian Feinauer 
Gesendet: Freitag, 3. Juli 2020 19:25
An: dev@plc4x.apache.org 
Betreff: Re: [RESULT] [VOTE] Rename our "master" branch to "release"

Shouldn't rename or move do the trick?

J

Holen Sie sich Outlook für Android


From: Christofer Dutz 
Sent: Friday, July 3, 2020 6:19:25 PM
To: dev@plc4x.apache.org 
Subject: [RESULT] [VOTE] Rename our "master" branch to "release"

So the vote passes with

7 +1 votes (technically 5 binding and 2 non-binding)

I'll try to find out if it's just creating a new branch and deleting the old 
and then take care od actually doing it.

Chris


Am 30.06.20, 16:00 schrieb "Otto Fowler" :

 +1  because why not?

Most others are considering “main” or something, avoiding what you are (I
think) explicitly going for using release which as such meaning.

Can always change it back

On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Hi all,

we had already discussed that some days ago, but I’d like to formally have
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t
explain what they are used for. We currently develop on “develop” and
therefore I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y”
(instead of “rel/x.y”) and to tag the releases themselves with the full
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming
scheme where nobody has to ask himself, which branch is used for what.

Chris

Re: [RESULT] [VOTE] Rename our "master" branch to "release"

2020-07-03 Thread Christofer Dutz 
I'm not sure there is no tooling from infra...

Von: Julian Feinauer 
Gesendet: Freitag, 3. Juli 2020 19:25
An: dev@plc4x.apache.org 
Betreff: Re: [RESULT] [VOTE] Rename our "master" branch to "release"

Shouldn't rename or move do the trick?

J

Holen Sie sich Outlook für Android


From: Christofer Dutz 
Sent: Friday, July 3, 2020 6:19:25 PM
To: dev@plc4x.apache.org 
Subject: [RESULT] [VOTE] Rename our "master" branch to "release"

So the vote passes with

7 +1 votes (technically 5 binding and 2 non-binding)

I'll try to find out if it's just creating a new branch and deleting the old 
and then take care od actually doing it.

Chris


Am 30.06.20, 16:00 schrieb "Otto Fowler" :

 +1  because why not?

Most others are considering “main” or something, avoiding what you are (I
think) explicitly going for using release which as such meaning.

Can always change it back

On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Hi all,

we had already discussed that some days ago, but I’d like to formally have
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t
explain what they are used for. We currently develop on “develop” and
therefore I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y”
(instead of “rel/x.y”) and to tag the releases themselves with the full
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming
scheme where nobody has to ask himself, which branch is used for what.

Chris

Re: [RESULT] [VOTE] Rename our "master" branch to "release"

2020-07-03 Thread Julian Feinauer 
Shouldn't rename or move do the trick?

J

Holen Sie sich Outlook für Android


From: Christofer Dutz 
Sent: Friday, July 3, 2020 6:19:25 PM
To: dev@plc4x.apache.org 
Subject: [RESULT] [VOTE] Rename our "master" branch to "release"

So the vote passes with

7 +1 votes (technically 5 binding and 2 non-binding)

I'll try to find out if it's just creating a new branch and deleting the old 
and then take care od actually doing it.

Chris


Am 30.06.20, 16:00 schrieb "Otto Fowler" :

 +1  because why not?

Most others are considering “main” or something, avoiding what you are (I
think) explicitly going for using release which as such meaning.

Can always change it back

On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Hi all,

we had already discussed that some days ago, but I’d like to formally have
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t
explain what they are used for. We currently develop on “develop” and
therefore I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y”
(instead of “rel/x.y”) and to tag the releases themselves with the full
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming
scheme where nobody has to ask himself, which branch is used for what.

Chris

[RESULT] [VOTE] Rename our "master" branch to "release"

2020-07-03 Thread Christofer Dutz 
So the vote passes with 

7 +1 votes (technically 5 binding and 2 non-binding)

I'll try to find out if it's just creating a new branch and deleting the old 
and then take care od actually doing it.

Chris


Am 30.06.20, 16:00 schrieb "Otto Fowler" :

 +1  because why not?

Most others are considering “main” or something, avoiding what you are (I
think) explicitly going for using release which as such meaning.

Can always change it back

On June 29, 2020 at 03:09:44, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Hi all,

we had already discussed that some days ago, but I’d like to formally have
you all vote on this … just to make it official.

I always thought “master”, “trunk” etc. were sub-ideal names as they don’t
explain what they are used for. We currently develop on “develop” and
therefore I propose to change the “master” branch to “release”.

While at it I would propose to call the release branches “release/x.y”
(instead of “rel/x.y”) and to tag the releases themselves with the full
three-digit numbers “release/x.y.z”).

This way I think we would have all in a very clean and concise naming
scheme where nobody has to ask himself, which branch is used for what.

Chris

Re: More Details regarding Scraper, Lack of Documentation

2020-07-03 Thread Stefano Bossi 
Thanks for your effort.

I would be interest too in the documentation of the scraper; I will be
stay tuned too.

Regards,
Stefano Bossi


On 03/07/2020 14:34, Christofer Dutz wrote:
> Hi Wolfgang,
>
> As the exact same question has come up multiple times In the last few days, 
> I'll start writing it.
>
> I was hoping the folks who wrote it would take care of this, but I understand 
> there's a need for more documentation and we haven't been doing an extremely 
> good job with that.
>
> So please stay tuned.
>
> Chris
>
> 
> Von: Wolfgang Huse 
> Gesendet: Freitag, 3. Juli 2020 09:30
> An: dev@plc4x.apache.org 
> Betreff: More Details regarding Scraper, Lack of Documentation
>
> Hello!
> I have read a lot of Scraper-Functionality, as example in the Logstash-Plugin 
> but I don’t find any high level Documentation.
>
> How do I leverage scraper and what are the benefits compared to cyclic 
> subscription of several values ?
>
> In my use-case I need to fetch 16 Values from a S7-300 every 1second. What Is 
> the best approach to do this ?
>
> Mit freundlichen Grüßen – With kind regards
>
> Wolfgang Huse
>
>



signature.asc
Description: OpenPGP digital signature

Re: S7 write test doubt

2020-07-03 Thread Christofer Dutz 
Hi all,

but there is one really big difference between 0.6.x and 0.7.x ... in the 0.6 
drivers when writing I explicitly split up write requests that for every filed 
a single value is sent.

But yes .. it would be interesting.

But the INTERNAL_ERROR for me implies that the problem is definitely on our 
side.

Chris


Am 03.07.20, 17:32 schrieb "Cesar Garcia" :

Hi Iñigo,

If you have the opportunity to test the previous version, it is currently
under evaluation by the team (0.6.1 PR).

You can check the versión here

https://github.com/glcj/plc4x/tree/s7alarm

In addition to the examples placed in the official repository, here you
will find a number of examples with native S7 types.

https://github.com/glcj/PLC4XS7Examples

I will be attentive to any request since it is in my interest that this
version is very well debugged.

I hope it is useful for you


El vie., 3 jul. 2020 a las 3:24, Iñigo Angulo () escribió:

> Hi Chris,
>
> Yes, I was thinking about why those dataypes were returning a List, thanks
> for the explanation
>
> I tried the SINT access. For reading values works perfectly. But when
> writing, Im afraid I am getting the same INTERNAL_ERROR message as for INT
> and DINT. I will make further tests, and let you know of the progress i
> make.
>
> Thanks!
>
> Iñigo
>
> -
> Iñigo Angulo
>
> ZYLK.net :: consultoría.openSource
> Ribera de Axpe, 11
> Edificio A, modulo 201-203
> 48950 Erandio (Bizkaia)
> +34 944272119
> -
>
> - Mensaje original -
> De: "Christofer Dutz" 
> Para: "dev" 
> Enviados: Jueves, 2 de Julio 2020 16:42:16
> Asunto: Re: S7 write test doubt
>
> Hi Iñigo,
>
> happy you made quite some progress.
>
> If you were asking yourself why for BYTE, WORD and DWORD the driver is
> returning a List ... these are considered Bit-Strings. If you want to
> read/write a single byte as an integer value, please use SINT instead.
>
> So regarding one of your questions ... could you instead of doing:
> builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
> Please try:
> builderWriter.addItem("mivariable", "%DB20:DBB06:SINT", 127);
>
> And if you're getting an INTERNAL_ERROR that's probably our fault. As I
> mentioned, we haven't done too much writing as no one ever uses that ;-)
>
> Chris
>
>
>
>
> Am 02.07.20, 15:56 schrieb "Iñigo Angulo" :
>
> Hi,
>
> I have been doing further tests with the S7 driver. I would like to
> ask you some doubts, which i am not sure if relate to the PLC4X driver or
> the actual hardware (Siemens S7-300) i am using (pretty novice in PLC data
> access im afraid...)
>
>
> The "Read value" tests I have done work correctly for different
> datatypes, for example:
>
> builderReader.addItem("mivariable", "%DB20:DBX5.0:BOOL"); //Single
> boolean value
> builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns
> a PlcList (Array of 8 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBW06:WORD"); //returns
> a PlcList (Array of 16 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBD06:DWORD");
> //returns a PlcList (Array of 32 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBW06:INT"); //returns
> a PlcInteger (16 bit integer (signed))
> builderReader.addItem("mivariable", "%DB20:DBD06:DINT"); //returns
> a PlcInteger (32 bit integer (signed))
> builderReader.addItem("mivariable", "%DB20:DBD06:REAL"); //returns
> a PlcFloat (32 bit IEEE 754 full precision floating point value (signed))
>
>
> In the "Write value" tests, write request for all datatype seem to
> work fine:
>
> builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBW06:WORD", 7);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBD06:DWORD", 1);
> //write response code "OK"
>
>
> Except for the 'INT' and 'DINT' datatypes, which return an
> INTERNAL_ERROR response code
>
> builderWriter.addItem("mivariable", "%DB20:DBW06:INT", 1); //write
> response code "INTERNAL_ERROR"
> builderWriter.addItem("mivariable", "%DB20:DBD06:DINT", 1);
> //write response code "INTERNAL_ERROR"
>
>
> Is the INTERNAL_ERROR code a hardware issue? (Maybe a device
> configuration problem?)
>
>

Re: S7 write test doubt

2020-07-03 Thread Cesar Garcia 
Hi Iñigo,

If you have the opportunity to test the previous version, it is currently
under evaluation by the team (0.6.1 PR).

You can check the versión here

https://github.com/glcj/plc4x/tree/s7alarm

In addition to the examples placed in the official repository, here you
will find a number of examples with native S7 types.

https://github.com/glcj/PLC4XS7Examples

I will be attentive to any request since it is in my interest that this
version is very well debugged.

I hope it is useful for you


El vie., 3 jul. 2020 a las 3:24, Iñigo Angulo () escribió:

> Hi Chris,
>
> Yes, I was thinking about why those dataypes were returning a List, thanks
> for the explanation
>
> I tried the SINT access. For reading values works perfectly. But when
> writing, Im afraid I am getting the same INTERNAL_ERROR message as for INT
> and DINT. I will make further tests, and let you know of the progress i
> make.
>
> Thanks!
>
> Iñigo
>
> -
> Iñigo Angulo
>
> ZYLK.net :: consultoría.openSource
> Ribera de Axpe, 11
> Edificio A, modulo 201-203
> 48950 Erandio (Bizkaia)
> +34 944272119
> -
>
> - Mensaje original -
> De: "Christofer Dutz" 
> Para: "dev" 
> Enviados: Jueves, 2 de Julio 2020 16:42:16
> Asunto: Re: S7 write test doubt
>
> Hi Iñigo,
>
> happy you made quite some progress.
>
> If you were asking yourself why for BYTE, WORD and DWORD the driver is
> returning a List ... these are considered Bit-Strings. If you want to
> read/write a single byte as an integer value, please use SINT instead.
>
> So regarding one of your questions ... could you instead of doing:
> builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
> Please try:
> builderWriter.addItem("mivariable", "%DB20:DBB06:SINT", 127);
>
> And if you're getting an INTERNAL_ERROR that's probably our fault. As I
> mentioned, we haven't done too much writing as no one ever uses that ;-)
>
> Chris
>
>
>
>
> Am 02.07.20, 15:56 schrieb "Iñigo Angulo" :
>
> Hi,
>
> I have been doing further tests with the S7 driver. I would like to
> ask you some doubts, which i am not sure if relate to the PLC4X driver or
> the actual hardware (Siemens S7-300) i am using (pretty novice in PLC data
> access im afraid...)
>
>
> The "Read value" tests I have done work correctly for different
> datatypes, for example:
>
> builderReader.addItem("mivariable", "%DB20:DBX5.0:BOOL"); //Single
> boolean value
> builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns
> a PlcList (Array of 8 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBW06:WORD"); //returns
> a PlcList (Array of 16 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBD06:DWORD");
> //returns a PlcList (Array of 32 boolean values)
> builderReader.addItem("mivariable", "%DB20:DBW06:INT"); //returns
> a PlcInteger (16 bit integer (signed))
> builderReader.addItem("mivariable", "%DB20:DBD06:DINT"); //returns
> a PlcInteger (32 bit integer (signed))
> builderReader.addItem("mivariable", "%DB20:DBD06:REAL"); //returns
> a PlcFloat (32 bit IEEE 754 full precision floating point value (signed))
>
>
> In the "Write value" tests, write request for all datatype seem to
> work fine:
>
> builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBW06:WORD", 7);
> //write response code "OK"
> builderWriter.addItem("mivariable", "%DB20:DBD06:DWORD", 1);
> //write response code "OK"
>
>
> Except for the 'INT' and 'DINT' datatypes, which return an
> INTERNAL_ERROR response code
>
> builderWriter.addItem("mivariable", "%DB20:DBW06:INT", 1); //write
> response code "INTERNAL_ERROR"
> builderWriter.addItem("mivariable", "%DB20:DBD06:DINT", 1);
> //write response code "INTERNAL_ERROR"
>
>
> Is the INTERNAL_ERROR code a hardware issue? (Maybe a device
> configuration problem?)
>
> ---
>
> Also, the other thing I found in the test:
>
> When I write a value different than BOOL, and then read the same
> memory address, I dont get the actual value but a 'false' filled array. TO
> give some examples,
>
> with BOOL values:
>
> builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
> builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return
> true
>
> builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", false);
> builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return
> false
>
> The written value is "correctly updated" and read fine.
>
> with other datatypes:
>
> builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 1);
> builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns
> [false, false,

Re: More Details regarding Scraper, Lack of Documentation

2020-07-03 Thread Christofer Dutz 
Hi Wolfgang,

As the exact same question has come up multiple times In the last few days, 
I'll start writing it.

I was hoping the folks who wrote it would take care of this, but I understand 
there's a need for more documentation and we haven't been doing an extremely 
good job with that.

So please stay tuned.

Chris


Von: Wolfgang Huse 
Gesendet: Freitag, 3. Juli 2020 09:30
An: dev@plc4x.apache.org 
Betreff: More Details regarding Scraper, Lack of Documentation

Hello!
I have read a lot of Scraper-Functionality, as example in the Logstash-Plugin 
but I don’t find any high level Documentation.

How do I leverage scraper and what are the benefits compared to cyclic 
subscription of several values ?

In my use-case I need to fetch 16 Values from a S7-300 every 1second. What Is 
the best approach to do this ?

Mit freundlichen Grüßen – With kind regards

Wolfgang Huse

Re: S7 write test doubt

2020-07-03 Thread Christofer Dutz 
Ok, thanks for checking this out. I'll investigate the issue as soon as I'm 
back in my office.

Chris

Von: Iñigo Angulo 
Gesendet: Freitag, 3. Juli 2020 09:24
An: dev 
Betreff: Re: S7 write test doubt

Hi Chris,

Yes, I was thinking about why those dataypes were returning a List, thanks for 
the explanation

I tried the SINT access. For reading values works perfectly. But when writing, 
Im afraid I am getting the same INTERNAL_ERROR message as for INT and DINT. I 
will make further tests, and let you know of the progress i make.

Thanks!

Iñigo

-
Iñigo Angulo

ZYLK.net :: consultoría.openSource
Ribera de Axpe, 11
Edificio A, modulo 201-203
48950 Erandio (Bizkaia)
+34 944272119
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Jueves, 2 de Julio 2020 16:42:16
Asunto: Re: S7 write test doubt

Hi Iñigo,

happy you made quite some progress.

If you were asking yourself why for BYTE, WORD and DWORD the driver is 
returning a List ... these are considered Bit-Strings. If you want to 
read/write a single byte as an integer value, please use SINT instead.

So regarding one of your questions ... could you instead of doing:
 builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
Please try:
 builderWriter.addItem("mivariable", "%DB20:DBB06:SINT", 127);

And if you're getting an INTERNAL_ERROR that's probably our fault. As I 
mentioned, we haven't done too much writing as no one ever uses that ;-)

Chris




Am 02.07.20, 15:56 schrieb "Iñigo Angulo" :

Hi,

I have been doing further tests with the S7 driver. I would like to ask you 
some doubts, which i am not sure if relate to the PLC4X driver or the actual 
hardware (Siemens S7-300) i am using (pretty novice in PLC data access im 
afraid...)


The "Read value" tests I have done work correctly for different datatypes, 
for example:

 builderReader.addItem("mivariable", "%DB20:DBX5.0:BOOL"); //Single 
boolean value
 builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns a 
PlcList (Array of 8 boolean values)
 builderReader.addItem("mivariable", "%DB20:DBW06:WORD"); //returns a 
PlcList (Array of 16 boolean values)
 builderReader.addItem("mivariable", "%DB20:DBD06:DWORD"); //returns a 
PlcList (Array of 32 boolean values)
 builderReader.addItem("mivariable", "%DB20:DBW06:INT"); //returns a 
PlcInteger (16 bit integer (signed))
 builderReader.addItem("mivariable", "%DB20:DBD06:DINT"); //returns a 
PlcInteger (32 bit integer (signed))
 builderReader.addItem("mivariable", "%DB20:DBD06:REAL"); //returns a 
PlcFloat (32 bit IEEE 754 full precision floating point value (signed))


In the "Write value" tests, write request for all datatype seem to work 
fine:

 builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true); 
//write response code "OK"
 builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127); //write 
response code "OK"
 builderWriter.addItem("mivariable", "%DB20:DBW06:WORD", 7); //write 
response code "OK"
 builderWriter.addItem("mivariable", "%DB20:DBD06:DWORD", 1); //write 
response code "OK"


Except for the 'INT' and 'DINT' datatypes, which return an INTERNAL_ERROR 
response code

 builderWriter.addItem("mivariable", "%DB20:DBW06:INT", 1); //write 
response code "INTERNAL_ERROR"
 builderWriter.addItem("mivariable", "%DB20:DBD06:DINT", 1); //write 
response code "INTERNAL_ERROR"


Is the INTERNAL_ERROR code a hardware issue? (Maybe a device configuration 
problem?)

---

Also, the other thing I found in the test:

When I write a value different than BOOL, and then read the same memory 
address, I dont get the actual value but a 'false' filled array. TO give some 
examples,

with BOOL values:

 builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
 builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return true

 builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", false);
 builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return 
false

The written value is "correctly updated" and read fine.

with other datatypes:

 builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 1);
 builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns 
[false, false, false, false, false, false, false, false]

 builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
 builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns 
[false, false, false, false, false, false, false, false]


I have tried to combine write single bits and read other datatypes, which 
seem to work fine:

 builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
builderReader.addItem("mivariable", "%DB20:DBB06:BYTE");

More Details regarding Scraper, Lack of Documentation

2020-07-03 Thread Wolfgang Huse 
Hello!
I have read a lot of Scraper-Functionality, as example in the Logstash-Plugin 
but I don’t find any high level Documentation.

How do I leverage scraper and what are the benefits compared to cyclic 
subscription of several values ?

In my use-case I need to fetch 16 Values from a S7-300 every 1second. What Is 
the best approach to do this ?

Mit freundlichen Grüßen – With kind regards

Wolfgang Huse

Re: S7 write test doubt

2020-07-03 Thread Iñigo Angulo 
Hi Chris,

Yes, I was thinking about why those dataypes were returning a List, thanks for 
the explanation

I tried the SINT access. For reading values works perfectly. But when writing, 
Im afraid I am getting the same INTERNAL_ERROR message as for INT and DINT. I 
will make further tests, and let you know of the progress i make.

Thanks!

Iñigo

- 
Iñigo Angulo 

ZYLK.net :: consultoría.openSource 
Ribera de Axpe, 11 
Edificio A, modulo 201-203 
48950 Erandio (Bizkaia) 
+34 944272119 
-

- Mensaje original -
De: "Christofer Dutz" 
Para: "dev" 
Enviados: Jueves, 2 de Julio 2020 16:42:16
Asunto: Re: S7 write test doubt

Hi Iñigo,

happy you made quite some progress.

If you were asking yourself why for BYTE, WORD and DWORD the driver is 
returning a List ... these are considered Bit-Strings. If you want to 
read/write a single byte as an integer value, please use SINT instead.

So regarding one of your questions ... could you instead of doing: 
builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
Please try:
builderWriter.addItem("mivariable", "%DB20:DBB06:SINT", 127);

And if you're getting an INTERNAL_ERROR that's probably our fault. As I 
mentioned, we haven't done too much writing as no one ever uses that ;-)

Chris




Am 02.07.20, 15:56 schrieb "Iñigo Angulo" :

Hi,

I have been doing further tests with the S7 driver. I would like to ask you 
some doubts, which i am not sure if relate to the PLC4X driver or the actual 
hardware (Siemens S7-300) i am using (pretty novice in PLC data access im 
afraid...)


The "Read value" tests I have done work correctly for different datatypes, 
for example:

builderReader.addItem("mivariable", "%DB20:DBX5.0:BOOL"); //Single 
boolean value
builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns a 
PlcList (Array of 8 boolean values)
builderReader.addItem("mivariable", "%DB20:DBW06:WORD"); //returns a 
PlcList (Array of 16 boolean values)
builderReader.addItem("mivariable", "%DB20:DBD06:DWORD"); //returns a 
PlcList (Array of 32 boolean values)
builderReader.addItem("mivariable", "%DB20:DBW06:INT"); //returns a 
PlcInteger (16 bit integer (signed))
builderReader.addItem("mivariable", "%DB20:DBD06:DINT"); //returns a 
PlcInteger (32 bit integer (signed))
builderReader.addItem("mivariable", "%DB20:DBD06:REAL"); //returns a 
PlcFloat (32 bit IEEE 754 full precision floating point value (signed))


In the "Write value" tests, write request for all datatype seem to work 
fine:

builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true); //write 
response code "OK"
builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127); //write 
response code "OK"
builderWriter.addItem("mivariable", "%DB20:DBW06:WORD", 7); //write 
response code "OK"
builderWriter.addItem("mivariable", "%DB20:DBD06:DWORD", 1); //write 
response code "OK"


Except for the 'INT' and 'DINT' datatypes, which return an INTERNAL_ERROR 
response code

builderWriter.addItem("mivariable", "%DB20:DBW06:INT", 1); //write 
response code "INTERNAL_ERROR"
builderWriter.addItem("mivariable", "%DB20:DBD06:DINT", 1); //write 
response code "INTERNAL_ERROR"


Is the INTERNAL_ERROR code a hardware issue? (Maybe a device configuration 
problem?)

---

Also, the other thing I found in the test:

When I write a value different than BOOL, and then read the same memory 
address, I dont get the actual value but a 'false' filled array. TO give some 
examples,

with BOOL values:

builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true); 
builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return true

builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", false); 
builderReader.addItem("mivariable", "%DB20:DBX6.1:BOOL"); //return false

The written value is "correctly updated" and read fine.

with other datatypes:

builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 1);
builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns 
[false, false, false, false, false, false, false, false]

builderWriter.addItem("mivariable", "%DB20:DBB06:BYTE", 127);
builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns 
[false, false, false, false, false, false, false, false]


I have tried to combine write single bits and read other datatypes, which 
seem to work fine:

builderWriter.addItem("mivariable", "%DB20:DBX6.1:BOOL", true);
builderReader.addItem("mivariable", "%DB20:DBB06:BYTE"); //returns 
[false, false, false, false, false, false, true, false]
builderReader.addItem("mivariable", "%DB20:DBW06:INT"); //return 512

And the other way around, write a byte and read single bits

builderWriter.addItem("mivariable",