Hi Chris, great work! This is Luis Rodriguez from the Ceos Automation team. Together with @Cesar Garcia, we'll test the changes you made to the S7 driver.
El sáb, 9 may 2026 a las 12:31, Christofer Dutz (<[email protected]>) escribió: > That would be super awesome :-) > > Chris > > Von: Sebastian Rühl <[email protected]> > Datum: Samstag, 9. Mai 2026 um 12:06 > An: [email protected] <[email protected]> > Betreff: Re: [SPI3] New S7 driver (Merged S7 and S7-light) > > Hey Chris, > > awesome work. > > Sure I can look into the plc4go part. Should I fix that on your branch? > > - Sebastian > > On 2026/05/09 08:27:52 Christofer Dutz wrote: > > Hi all, > > > > After a week of 16 hour shifts I’m happy to announce that probably the > largest beast has landed in the SPI3 branch. > > It’s generally a complete rewrite of the S7 driver. > > > > What took a bit of time with this, was that I needed to understand what > Cesar did to make the S7 driver different. > > Turns out the main points were: > > > > * > > Support for Cyclic Subscriptions on S7-300 and 400 PLCs > > * > > Support for subscribing to Alarms/Events on S7-300 and 400 PLCs > > * > > Support for S7H (Redundancy) where you establish two simultaneous > connections it transparently executes commands via the primary, if a > failure of the primary connection is detected, it switches to the backup > connection (As the old driver didn’t handle the special case of > subscriptions on these setups, I actively defined that as unsupported when > using a S7H connection. > > > > > > The interesting thing that I found out when testing: As my S7-300 had a > secondary communication board, I wanted to use that for testing, however it > turns out my communication board is a „light“ version, that doesn’t support > S7 protocol. So, I tried two S7-1500 that have the same memory layout, and > it worked flawlessly. So possibly we should advertise this feature a bit > more as you seem to be able to use I with any type of S7 PLC. > > > > As this was also the first driver that I know of, that really supports > the „Event“ type subscriptions. I realized that our browse-items only had > as „supportsSubscriptions()“. However, the one type of tag only supports > EVENT and others support only CYCLIC, so I extended the API module to add a > method where users can list the supported types of subscriptions. The > „isSubscriptionSupported()“ was changed to checking if the other is an > empty list. > > > > @Cesar Garcia<mailto:[email protected]> It would be super > awesome, if you could give my changes a test against the hardware you built > these features for. I did my best to try and test things here, but you > can’t beat the real thing. I also hope you are not too confused about a > completely new driver. The architecturally interesting major differences > are, that this driver no longer implements the TPKT and COTP layer. This is > now all handled by the new COTP Transport (I learned there’s a whole zoo of > Siemens protocols for various types of device, which use COTP. Also does it > handle the breaking point between COTP and S7 a lot nicer and should make > the overall driver a lot simpler. The S7H stuff is handled transparently by > s secondary S7HCotpConnection wich complements the default > S7CotpConnection. So all of the handling of this is incapsulated in the > S7HCotpConnection. > > > > I’ve also used some time to adjust the PLC4C, PLC4Go, PLC4Py and PLC4Net > to work with my changes in the mspec (String encodings are named „UTF8“ and > not „UTF-8“ … same applies to all the other string encoding names) … also > is the byteOrder property no longer an enum, but a string (In order to > support these super odd byte-orders in drivers like Modbus > LITTLE_ENDIAN_BYTE_SWAP etc.). In the testsuite XMLs the two properties > driverName and languageFlavor -> driver-name and language-flavor … All > other languages pass, however I could use a bit of help with PLC4GO … so > Sebastian … if you wanna earn a few beers … could you please have a look? > > > > So … that should probably be it for now …. Gee what a week … I think I > should probably crank down my shift times … 16 hours a day isn’t healthy. > > > > > > Chris > > >
