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
