Wow this is great stuff!!!! Sorry for not responding yesterday. I'm currently on a big conference and yesterday they had no internet and reading large emails and responding on the phone is sort of not that ideal.
I'm so totally looking forward to being this functionality into the new s7 driver. How about we do a slack call some time next week? Chris ________________________________ Von: Cesar Garcia <cesar.gar...@ceos.com.ve> Gesendet: Mittwoch, 5. Februar 2020 05:12 An: Apache PLC4X <dev@plc4x.apache.org> Betreff: S7 Asynchronous events. Hi Alls, I take some time to inform you of the progress I am making for handling asynchronous events in the S7 Legacy driver (Netty version). Currently the modification allows to selectively receive the events associated with the PLC. 1. PLC event handling was added. To say: . MODE: Detects when the PLC changes state. . SYS: Internal PLC events. . USER: Events generated by the user within the PLC program. .ALM_S: Subscription to ALARM_S alarms and their variants. (S7300 & S7400) .ALM_8: Subscription to alarms ALARM_8 and its variants. (S7400). These events are translated into a "PlcSubscriptionEvent" type and sent to the "Consumer" defined by the final application, using the programming pattern defined in the API (or as I interpret it). I have tried as far as possible that "Events" be as close as possible to the MapMessage interface of the JMS API. This allows you to get the most out of the PLC, being able to send process states using ActiveMQ or in my case AdminEvent from OSGi. Another point of application for this feature is the term of quality associated with the values read by the driver. For example, if you use a CP343-1 / CP443-1 (Ethernet) its operation is independent of the CPU, so when the CPU goes to STOP mode for any event the quality of the read values is doubtful. 2. Subscription to cyclic values. This feature allows the subscription to fields within the PLC synchronously. The data is sent from the PLC, so the driver does not perform a PULL of data. There are many points of improvement since the implementation depends on the amount of data that the CPU can send in a request. This is the typical way of working with WinCC, but it is especially useful for embedded devices since it lightens the CPU load. I hope to test this feature on the BegleBone Black, Raspberry Pi 3, and my new toy the Siemens IOT2040. 3. SSL It is important that with this feature, the PLC can be diagnosed. The original driver design uses this feature to determine the properties of the PLC. The driver was modified so that the information arrived complete, but not processed to the client. I will be adding a utility class to interpret the byte buffer, something that is laborious since each request has a different response pattern, but for my application it is extremely useful. The code is in GitHub, it is a spaghetti and there are many things to clean, but it is a breakthrough. I hope you find the information useful, Best regards, -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: 0416-681.03.99* *Cel: 0414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com <support.aan.automat...@siemens.com>*
