AW: AW: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Christofer Dutz]

As long as the sonar reports keep being generated …

I wouldn’t want to give up on that.
A different option would be to relax the rules in Sonar for failing the build.

If someone adds something like fatal issues, I think it’s ok to fail, but based 
on our current coverage levels I would probably relax those rules a bit.

Chris


Von: Sebastian Rühl 
Datum: Freitag, 15. März 2024 um 14:45
An: dev@plc4x.apache.org 
Betreff: Re: AW: [DISCUSS] Disable the Sonar-Check in Github Actions?
Yes, you are absolutely right. Lets just disable the Part in sonar which fails 
the build or mark it as failed and lets disable that.

On 2024/03/15 13:05:00 Christofer Dutz wrote:
> I generally fully agree.
>
> But I don’t want to cause contributors to leave in that case.
> I have seen way too many projects where good contributions don’t get merged 
> because of guards like that.
>
> So, if us doing that would cause us loosing/not attracting new people, then I 
> would be hesitant to add more rules.
>
> In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
> the only ones contributing, cause everyone else left.
>
> When contributing to other project stuff like that is sometimes the most 
> discouraging things.
> Like “Build failed cause there’s a line-break at the end of this file” 
> (Totally annoyed by that in the IoTDB project).
>
> Chris
>
> Von: Sebastian Rühl 
> Datum: Freitag, 15. März 2024 um 11:23
> An: dev@plc4x.apache.org 
> Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
> Honestly I think we should do the following:
>
> - Take sonar serious and look after that stuff Reported there
> - Disable the build breaker for some time so it doesn't flag everything as a 
> failed build
> - Think about how we can avoid ending in the same situation again
>
> If you look at other projects usually you have a build breaker/guard on a PR 
> and then it is the duty of the author to ensure that the code added doesn't 
> break the sonar rules before merging. Due to the fact that we don't follow 
> that it is easy to slip stuff into develop which leads then to a state we 
> have now. Not 100% sure what is best to do here.
>
> Sebastian
>
> On 2024/03/14 21:27:45 Christofer Dutz wrote:
> > Hi all,
> >
> > So, we have been having failing builds for … well … it feels like … ever. 
> > Because the Sonarcloud check always keeps on marking every commit as Errror.
> >
> > I think: Either we pay attention to it, or we disable it.
> >
> > So, what do you folks think? Keeping it on and paying attention to it will 
> > be a lot of work, but it would be worth it.
> >
> > Chris
> >
>

AW: S7 types supporting Subscriptions

[Christofer Dutz]

Hi all,

I wasn’t in favor of this … just added what we would need to fully address it, 
but still I would assume that even then will be some edge-cases.

Throwing an exception sounds quite excessive, but thinking more about it, we do 
return plc status codes for every field.
So, if an operation is requested, that is not supported, we could simply 
indicate that in the status codes returned for that field.
Maybe we need to add some codes we were missing, but I guess that should be a 
lot simpler.

Chris


Von: Cesar Garcia 
Datum: Freitag, 15. März 2024 um 14:15
An: dev@plc4x.apache.org 
Betreff: Re: S7 types supporting Subscriptions
Hello,

I think that makes the API more complex than necessary.

We should keep it as simple as possible.

I think that for the driver there are already some fields that are
MetaData, so we should document and not extend the API.

As you don't point out, for example the S7 has the ability to diagnose
which functions it supports, and then inform the developer. Of course it
takes time to do it.

My grain of sand

El vie, 15 mar 2024 a las 9:02, Christofer Dutz ()
escribió:

> Well in that case we‘d actually have to introduce the following:
>
>
>   *   IsCyclicSubscriptionSupportedForTag
>   *   IsChangeOnValueSubscriptionSupportedForTag
>   *   IsEventSubscriptionSupportedForTag
>
> And possibly the “TagAddress” counterparts.
>
> We’d definitely be blowing up the API that way and making it more complex
> to use.
>
> Possibly throwing an exception when buiding a request might be a better
> option.
> So you use the isXYZSupported functions for general functionality support
> and catch exceptions later.
>
> Chris
>
> Von: Łukasz Dywicki 
> Datum: Freitag, 15. März 2024 um 10:48
> An: dev@plc4x.apache.org 
> Betreff: Re: S7 types supporting Subscriptions
> Thinking of it, maybe it would be better to extend signature of
> subscription inquiry to be isSubscriptionSupported(PlcTag) ?
> My motivation for this is rather basic - the BACnet stuff which is on
> the way will have per-participant subscriptions. Profinet (I suppose) is
> same for cyclic/acyclic subscriptions and so on.
> This gives driver opportunity to make smarter decision. Obviously for
> point to point connection such S7-TCP we can rely on device type
> negotiated earlier, *but* spanning further, we could finally let S7-1200
> subscriptions only for MODE events.
>
> Cheers,
> Łukasz
>
> On 13.03.2024 21:16, Christofer Dutz wrote:
> > Changing the title ….
> >
> > So, I just updated the S7 driver to no longer simply report true on
> “isSubscriptionSupported()” and it now only reports “true”, if it’s a
> S7-300 or S7-400.
> > If there is more, that needs to be enabled in order to support
> subscriptions on such a device, it would be cool, if we could detect that
> during the connection process and report accordingly.
> >
> > Chris
> >
> >
> > Von: Cesar Garcia 
> > Datum: Mittwoch, 13. März 2024 um 21:12
> > An: dev@plc4x.apache.org 
> > Betreff: Re: Board report 
> > Hello Chris,
> >
> > The S7-300/S7-400 devices have an important group of functions for event
> > handling. In the process part (PCS7) this is handled intensively.
> >
> > At the time, all these operations are on the Tag associated with the
> > request, so any service type subscription is a subscription to events.
> >
> > In general the S7-300/S7-400 support;
> >
> > - *MODE*: Change of operating state in the controller, change from
> STOP
> > to RUN and vice versa.
> > - *SYS*: System events, associated with internal events of the
> > controller or events previously parameterized for their indication.
> > - *USR*: Events programmed by the user and that are registered in the
> > internal diagnostic buffer.
> > - *ALM*: Alarm events generated by the user program, ALARM_S,
> ALARM_8,
> > NOTIFY.
> > - And additionally "*CYC*" cyclic mode transfer.
> >
> >
> > But in general they are all seen as events, hence the inconsistency
> pointed
> > out by Bjorn.
> >
> > All these events are implemented, of course, they have many points of
> > improvement that must be addressed.
> >
> > I currently do not have a PN or CP-343-1 CPU for testing with S7-300.
> >
> > As you point out, with Zylk's contribution it can complement the CP-443-1
> > for redudance tests (thanks Zylk).
> >
> > Well, the story is long... I'm going for a good coffee.
> >
> > Kind regards,
> >
> > El mié, 13 mar 2024 a las 14:57, Christofer Dutz (<
> christofer.d...@c-ware.de>)
> > escribió:
> >
> >> Hi Björn,
> >>
> >> the problem with the subscriptions in S7 are that they do work, but only
> >> on S7 300 (I think).
> >> I mentioned before on this list, that we should probably do
> >> context-sensitive “isXYZSupported” functions.
> >> Unfortunately, I haven’t yet had the time to implement them.
> >>
> >> So, to make it short … in general the S7 protocol doesn’t support
> >> subscriptions, except for a small subset of device types.
> >> If Cesar could possibly 

Re: AW: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Sebastian Rühl]

Yes, you are absolutely right. Lets just disable the Part in sonar which fails 
the build or mark it as failed and lets disable that.

On 2024/03/15 13:05:00 Christofer Dutz wrote:
> I generally fully agree.
> 
> But I don’t want to cause contributors to leave in that case.
> I have seen way too many projects where good contributions don’t get merged 
> because of guards like that.
> 
> So, if us doing that would cause us loosing/not attracting new people, then I 
> would be hesitant to add more rules.
> 
> In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
> the only ones contributing, cause everyone else left.
> 
> When contributing to other project stuff like that is sometimes the most 
> discouraging things.
> Like “Build failed cause there’s a line-break at the end of this file” 
> (Totally annoyed by that in the IoTDB project).
> 
> Chris
> 
> Von: Sebastian Rühl 
> Datum: Freitag, 15. März 2024 um 11:23
> An: dev@plc4x.apache.org 
> Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
> Honestly I think we should do the following:
> 
> - Take sonar serious and look after that stuff Reported there
> - Disable the build breaker for some time so it doesn't flag everything as a 
> failed build
> - Think about how we can avoid ending in the same situation again
> 
> If you look at other projects usually you have a build breaker/guard on a PR 
> and then it is the duty of the author to ensure that the code added doesn't 
> break the sonar rules before merging. Due to the fact that we don't follow 
> that it is easy to slip stuff into develop which leads then to a state we 
> have now. Not 100% sure what is best to do here.
> 
> Sebastian
> 
> On 2024/03/14 21:27:45 Christofer Dutz wrote:
> > Hi all,
> >
> > So, we have been having failing builds for … well … it feels like … ever. 
> > Because the Sonarcloud check always keeps on marking every commit as Errror.
> >
> > I think: Either we pay attention to it, or we disable it.
> >
> > So, what do you folks think? Keeping it on and paying attention to it will 
> > be a lot of work, but it would be worth it.
> >
> > Chris
> >
> 

[BUILD-FAILURE]: Job 'PLC4X/PLC4X/develop [develop] [1937]'

[Apache Jenkins Server]

BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [1937]':

Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/1937/;>PLC4X/PLC4X/develop
 [develop] [1937]"

Re: S7 types supporting Subscriptions

[Cesar Garcia]

Hello,

I think that makes the API more complex than necessary.

We should keep it as simple as possible.

I think that for the driver there are already some fields that are
MetaData, so we should document and not extend the API.

As you don't point out, for example the S7 has the ability to diagnose
which functions it supports, and then inform the developer. Of course it
takes time to do it.

My grain of sand

El vie, 15 mar 2024 a las 9:02, Christofer Dutz ()
escribió:

> Well in that case we‘d actually have to introduce the following:
>
>
>   *   IsCyclicSubscriptionSupportedForTag
>   *   IsChangeOnValueSubscriptionSupportedForTag
>   *   IsEventSubscriptionSupportedForTag
>
> And possibly the “TagAddress” counterparts.
>
> We’d definitely be blowing up the API that way and making it more complex
> to use.
>
> Possibly throwing an exception when buiding a request might be a better
> option.
> So you use the isXYZSupported functions for general functionality support
> and catch exceptions later.
>
> Chris
>
> Von: Łukasz Dywicki 
> Datum: Freitag, 15. März 2024 um 10:48
> An: dev@plc4x.apache.org 
> Betreff: Re: S7 types supporting Subscriptions
> Thinking of it, maybe it would be better to extend signature of
> subscription inquiry to be isSubscriptionSupported(PlcTag) ?
> My motivation for this is rather basic - the BACnet stuff which is on
> the way will have per-participant subscriptions. Profinet (I suppose) is
> same for cyclic/acyclic subscriptions and so on.
> This gives driver opportunity to make smarter decision. Obviously for
> point to point connection such S7-TCP we can rely on device type
> negotiated earlier, *but* spanning further, we could finally let S7-1200
> subscriptions only for MODE events.
>
> Cheers,
> Łukasz
>
> On 13.03.2024 21:16, Christofer Dutz wrote:
> > Changing the title ….
> >
> > So, I just updated the S7 driver to no longer simply report true on
> “isSubscriptionSupported()” and it now only reports “true”, if it’s a
> S7-300 or S7-400.
> > If there is more, that needs to be enabled in order to support
> subscriptions on such a device, it would be cool, if we could detect that
> during the connection process and report accordingly.
> >
> > Chris
> >
> >
> > Von: Cesar Garcia 
> > Datum: Mittwoch, 13. März 2024 um 21:12
> > An: dev@plc4x.apache.org 
> > Betreff: Re: Board report 
> > Hello Chris,
> >
> > The S7-300/S7-400 devices have an important group of functions for event
> > handling. In the process part (PCS7) this is handled intensively.
> >
> > At the time, all these operations are on the Tag associated with the
> > request, so any service type subscription is a subscription to events.
> >
> > In general the S7-300/S7-400 support;
> >
> > - *MODE*: Change of operating state in the controller, change from
> STOP
> > to RUN and vice versa.
> > - *SYS*: System events, associated with internal events of the
> > controller or events previously parameterized for their indication.
> > - *USR*: Events programmed by the user and that are registered in the
> > internal diagnostic buffer.
> > - *ALM*: Alarm events generated by the user program, ALARM_S,
> ALARM_8,
> > NOTIFY.
> > - And additionally "*CYC*" cyclic mode transfer.
> >
> >
> > But in general they are all seen as events, hence the inconsistency
> pointed
> > out by Bjorn.
> >
> > All these events are implemented, of course, they have many points of
> > improvement that must be addressed.
> >
> > I currently do not have a PN or CP-343-1 CPU for testing with S7-300.
> >
> > As you point out, with Zylk's contribution it can complement the CP-443-1
> > for redudance tests (thanks Zylk).
> >
> > Well, the story is long... I'm going for a good coffee.
> >
> > Kind regards,
> >
> > El mié, 13 mar 2024 a las 14:57, Christofer Dutz (<
> christofer.d...@c-ware.de>)
> > escribió:
> >
> >> Hi Björn,
> >>
> >> the problem with the subscriptions in S7 are that they do work, but only
> >> on S7 300 (I think).
> >> I mentioned before on this list, that we should probably do
> >> context-sensitive “isXYZSupported” functions.
> >> Unfortunately, I haven’t yet had the time to implement them.
> >>
> >> So, to make it short … in general the S7 protocol doesn’t support
> >> subscriptions, except for a small subset of device types.
> >> If Cesar could possibly tell me which devices support Subscriptions, I
> >> could implement something to make this happen (Shouldn’t be too much
> work).
> >>
> >> One day we’ll probably have simulated subscriptions, but admittedly as
> >> nobody really seems to be interested in working on core-services like
> this,
> >> it’s probably gonna take a while.
> >> In the past I was able to work on PLC4X full time, but as no company
> >> (except Zylk) was really willing to pay for any form of development, I
> had
> >> to pick a job that pays the bills.
> >> I’m still on it, but doing this in my free time.
> >>
> >> Chris
> >>
> >> Von: Björn Haverland 
> >> Datum: 

Re: [PR] Fix/s7async

[via GitHub]

glcj merged PR #1451:
URL: https://github.com/apache/plc4x/pull/1451


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

AW: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Christofer Dutz]

I generally fully agree.

But I don’t want to cause contributors to leave in that case.
I have seen way too many projects where good contributions don’t get merged 
because of guards like that.

So, if us doing that would cause us loosing/not attracting new people, then I 
would be hesitant to add more rules.

In the end it doesn’t help us, if we have a happy Sonar, but we’re (or I) am 
the only ones contributing, cause everyone else left.

When contributing to other project stuff like that is sometimes the most 
discouraging things.
Like “Build failed cause there’s a line-break at the end of this file” (Totally 
annoyed by that in the IoTDB project).

Chris

Von: Sebastian Rühl 
Datum: Freitag, 15. März 2024 um 11:23
An: dev@plc4x.apache.org 
Betreff: Re: [DISCUSS] Disable the Sonar-Check in Github Actions?
Honestly I think we should do the following:

- Take sonar serious and look after that stuff Reported there
- Disable the build breaker for some time so it doesn't flag everything as a 
failed build
- Think about how we can avoid ending in the same situation again

If you look at other projects usually you have a build breaker/guard on a PR 
and then it is the duty of the author to ensure that the code added doesn't 
break the sonar rules before merging. Due to the fact that we don't follow that 
it is easy to slip stuff into develop which leads then to a state we have now. 
Not 100% sure what is best to do here.

Sebastian

On 2024/03/14 21:27:45 Christofer Dutz wrote:
> Hi all,
>
> So, we have been having failing builds for … well … it feels like … ever. 
> Because the Sonarcloud check always keeps on marking every commit as Errror.
>
> I think: Either we pay attention to it, or we disable it.
>
> So, what do you folks think? Keeping it on and paying attention to it will be 
> a lot of work, but it would be worth it.
>
> Chris
>

[PR] Fix/s7async

[via GitHub]

glcj opened a new pull request, #1451:
URL: https://github.com/apache/plc4x/pull/1451

   This initial PR includes,
   
   1. Modify the cyclic subscription so that it returns PlcValue objects 
instead of byte[].
   2. Cyclic subscriptions now support subscribing to boolean elements.
   3. Cyclic subscriptions adapt to the API. Cyclic subscriptions can be made 
through "addCyclicTagAddress".
   4. The value transferred as "pollingInterval" is tailored to the 
requirements of the S7 cyclic subscription.
   5. Experimentally, support for "addChangeOfStateTagAddress" is added.
   6. Only a subset of the types is allowed since the "getRaw" method is 
required to be implemented in the different PlcValues.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

AW: S7 types supporting Subscriptions

[Christofer Dutz]

Well in that case we‘d actually have to introduce the following:


  *   IsCyclicSubscriptionSupportedForTag
  *   IsChangeOnValueSubscriptionSupportedForTag
  *   IsEventSubscriptionSupportedForTag

And possibly the “TagAddress” counterparts.

We’d definitely be blowing up the API that way and making it more complex to 
use.

Possibly throwing an exception when buiding a request might be a better option.
So you use the isXYZSupported functions for general functionality support and 
catch exceptions later.

Chris

Von: Łukasz Dywicki 
Datum: Freitag, 15. März 2024 um 10:48
An: dev@plc4x.apache.org 
Betreff: Re: S7 types supporting Subscriptions
Thinking of it, maybe it would be better to extend signature of
subscription inquiry to be isSubscriptionSupported(PlcTag) ?
My motivation for this is rather basic - the BACnet stuff which is on
the way will have per-participant subscriptions. Profinet (I suppose) is
same for cyclic/acyclic subscriptions and so on.
This gives driver opportunity to make smarter decision. Obviously for
point to point connection such S7-TCP we can rely on device type
negotiated earlier, *but* spanning further, we could finally let S7-1200
subscriptions only for MODE events.

Cheers,
Łukasz

On 13.03.2024 21:16, Christofer Dutz wrote:
> Changing the title ….
>
> So, I just updated the S7 driver to no longer simply report true on 
> “isSubscriptionSupported()” and it now only reports “true”, if it’s a S7-300 
> or S7-400.
> If there is more, that needs to be enabled in order to support subscriptions 
> on such a device, it would be cool, if we could detect that during the 
> connection process and report accordingly.
>
> Chris
>
>
> Von: Cesar Garcia 
> Datum: Mittwoch, 13. März 2024 um 21:12
> An: dev@plc4x.apache.org 
> Betreff: Re: Board report 
> Hello Chris,
>
> The S7-300/S7-400 devices have an important group of functions for event
> handling. In the process part (PCS7) this is handled intensively.
>
> At the time, all these operations are on the Tag associated with the
> request, so any service type subscription is a subscription to events.
>
> In general the S7-300/S7-400 support;
>
> - *MODE*: Change of operating state in the controller, change from STOP
> to RUN and vice versa.
> - *SYS*: System events, associated with internal events of the
> controller or events previously parameterized for their indication.
> - *USR*: Events programmed by the user and that are registered in the
> internal diagnostic buffer.
> - *ALM*: Alarm events generated by the user program, ALARM_S, ALARM_8,
> NOTIFY.
> - And additionally "*CYC*" cyclic mode transfer.
>
>
> But in general they are all seen as events, hence the inconsistency pointed
> out by Bjorn.
>
> All these events are implemented, of course, they have many points of
> improvement that must be addressed.
>
> I currently do not have a PN or CP-343-1 CPU for testing with S7-300.
>
> As you point out, with Zylk's contribution it can complement the CP-443-1
> for redudance tests (thanks Zylk).
>
> Well, the story is long... I'm going for a good coffee.
>
> Kind regards,
>
> El mié, 13 mar 2024 a las 14:57, Christofer Dutz ()
> escribió:
>
>> Hi Björn,
>>
>> the problem with the subscriptions in S7 are that they do work, but only
>> on S7 300 (I think).
>> I mentioned before on this list, that we should probably do
>> context-sensitive “isXYZSupported” functions.
>> Unfortunately, I haven’t yet had the time to implement them.
>>
>> So, to make it short … in general the S7 protocol doesn’t support
>> subscriptions, except for a small subset of device types.
>> If Cesar could possibly tell me which devices support Subscriptions, I
>> could implement something to make this happen (Shouldn’t be too much work).
>>
>> One day we’ll probably have simulated subscriptions, but admittedly as
>> nobody really seems to be interested in working on core-services like this,
>> it’s probably gonna take a while.
>> In the past I was able to work on PLC4X full time, but as no company
>> (except Zylk) was really willing to pay for any form of development, I had
>> to pick a job that pays the bills.
>> I’m still on it, but doing this in my free time.
>>
>> Chris
>>
>> Von: Björn Haverland 
>> Datum: Mittwoch, 13. März 2024 um 18:52
>> An: dev@plc4x.apache.org 
>> Betreff: Re: Board report 
>> Hi,
>>
>> as I'm starting to get used to the project I do have some questions,
>> especially regarding the mentioned v1.0.0.
>>
>> I tried to set up a plc4j with the quickstart guide which utilizes the S7
>> protocol.
>>
>> So there are examples, in the example folder as well, which are just not
>> working. (The Subscription for instance) I do understand that the lib
>> hasn't had a Major release yet, but I think it could set people off.
>>
>> I like to suggest to change the docs on that points. I know it is hard to
>> test everything but if a feature isn't implemented a wrong documentation
>> just leads to frustration.
>> 

Re: [DISCUSS] Disable the Sonar-Check in Github Actions?

[Sebastian Rühl]

Honestly I think we should do the following:

- Take sonar serious and look after that stuff Reported there
- Disable the build breaker for some time so it doesn't flag everything as a 
failed build
- Think about how we can avoid ending in the same situation again

If you look at other projects usually you have a build breaker/guard on a PR 
and then it is the duty of the author to ensure that the code added doesn't 
break the sonar rules before merging. Due to the fact that we don't follow that 
it is easy to slip stuff into develop which leads then to a state we have now. 
Not 100% sure what is best to do here.

Sebastian

On 2024/03/14 21:27:45 Christofer Dutz wrote:
> Hi all,
> 
> So, we have been having failing builds for … well … it feels like … ever. 
> Because the Sonarcloud check always keeps on marking every commit as Errror.
> 
> I think: Either we pay attention to it, or we disable it.
> 
> So, what do you folks think? Keeping it on and paying attention to it will be 
> a lot of work, but it would be worth it.
> 
> Chris
> 

Re: S7 types supporting Subscriptions

[Łukasz Dywicki]

Thinking of it, maybe it would be better to extend signature of 
subscription inquiry to be isSubscriptionSupported(PlcTag) ?
My motivation for this is rather basic - the BACnet stuff which is on 
the way will have per-participant subscriptions. Profinet (I suppose) is 
same for cyclic/acyclic subscriptions and so on.
This gives driver opportunity to make smarter decision. Obviously for 
point to point connection such S7-TCP we can rely on device type 
negotiated earlier, *but* spanning further, we could finally let S7-1200 
subscriptions only for MODE events.


Cheers,
Łukasz

On 13.03.2024 21:16, Christofer Dutz wrote:

Changing the title ….

So, I just updated the S7 driver to no longer simply report true on 
“isSubscriptionSupported()” and it now only reports “true”, if it’s a S7-300 or 
S7-400.
If there is more, that needs to be enabled in order to support subscriptions on 
such a device, it would be cool, if we could detect that during the connection 
process and report accordingly.

Chris


Von: Cesar Garcia 
Datum: Mittwoch, 13. März 2024 um 21:12
An: dev@plc4x.apache.org 
Betreff: Re: Board report 
Hello Chris,

The S7-300/S7-400 devices have an important group of functions for event
handling. In the process part (PCS7) this is handled intensively.

At the time, all these operations are on the Tag associated with the
request, so any service type subscription is a subscription to events.

In general the S7-300/S7-400 support;

- *MODE*: Change of operating state in the controller, change from STOP
to RUN and vice versa.
- *SYS*: System events, associated with internal events of the
controller or events previously parameterized for their indication.
- *USR*: Events programmed by the user and that are registered in the
internal diagnostic buffer.
- *ALM*: Alarm events generated by the user program, ALARM_S, ALARM_8,
NOTIFY.
- And additionally "*CYC*" cyclic mode transfer.


But in general they are all seen as events, hence the inconsistency pointed
out by Bjorn.

All these events are implemented, of course, they have many points of
improvement that must be addressed.

I currently do not have a PN or CP-343-1 CPU for testing with S7-300.

As you point out, with Zylk's contribution it can complement the CP-443-1
for redudance tests (thanks Zylk).

Well, the story is long... I'm going for a good coffee.

Kind regards,

El mié, 13 mar 2024 a las 14:57, Christofer Dutz ()
escribió:


Hi Björn,

the problem with the subscriptions in S7 are that they do work, but only
on S7 300 (I think).
I mentioned before on this list, that we should probably do
context-sensitive “isXYZSupported” functions.
Unfortunately, I haven’t yet had the time to implement them.

So, to make it short … in general the S7 protocol doesn’t support
subscriptions, except for a small subset of device types.
If Cesar could possibly tell me which devices support Subscriptions, I
could implement something to make this happen (Shouldn’t be too much work).

One day we’ll probably have simulated subscriptions, but admittedly as
nobody really seems to be interested in working on core-services like this,
it’s probably gonna take a while.
In the past I was able to work on PLC4X full time, but as no company
(except Zylk) was really willing to pay for any form of development, I had
to pick a job that pays the bills.
I’m still on it, but doing this in my free time.

Chris

Von: Björn Haverland 
Datum: Mittwoch, 13. März 2024 um 18:52
An: dev@plc4x.apache.org 
Betreff: Re: Board report 
Hi,

as I'm starting to get used to the project I do have some questions,
especially regarding the mentioned v1.0.0.

I tried to set up a plc4j with the quickstart guide which utilizes the S7
protocol.

So there are examples, in the example folder as well, which are just not
working. (The Subscription for instance) I do understand that the lib
hasn't had a Major release yet, but I think it could set people off.

I like to suggest to change the docs on that points. I know it is hard to
test everything but if a feature isn't implemented a wrong documentation
just leads to frustration.
Cesar has implemented a working CyclicSubscription, and I think he is
going to merge it to the dev branch soon. But still there are other
subscription methods shown which won't work, just yet.

I'd like to hear your opinion on this.

Best regards

Bjoern



Gesendet von Outlook für Android

From: Christofer Dutz 
Sent: Wednesday, March 13, 2024 12:00:11 PM
To: dev@plc4x.apache.org 
Subject: Board report 

Hi all,

unfortunately I had almost forgotten to submit the board report after
coming back from my little snowboard vacation.
I took the liberty of posting the following report. If there are changes
you’d like to see, please tell me asap and I can edit it.



## Description:
The mission of the Apache PLC4X project is creating a set of libraries for
communicating with industrial