Hi Chris, then i will tackle that.
Matthias Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: matthias.strl...@isw.uni-stuttgart.de Web: http://www.isw.uni-stuttgart.de -----Ursprüngliche Nachricht----- Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Tuesday, January 14, 2020 11:23 AM An: dev@plc4x.apache.org Betreff: AW: Just added new branch "next-gen-core-2" ... Hi all, Well the up-side is that we will never need to implement the full attack, just parts of it. Perhaps porting the opc-ua driver to the updated structure could help for now. Chris ________________________________ Von: Strljic, Matthias Milan <matthias.strl...@isw.uni-stuttgart.de> Gesendet: Dienstag, 14. Januar 2020 10:32:41 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: AW: Just added new branch "next-gen-core-2" ... Hi Chris, Yeah, the OPC UA stack will be pretty heavy. Maybe not the raw package logic, but the complete feature set will be a bigger piece. So I assume it will take a while until OPC UA is mapped into a generated driver. So I have a question how we will handle this in the larger version 0.6.0 we are aiming for? Matthias Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: matthias.strl...@isw.uni-stuttgart.de Web: http://www.isw.uni-stuttgart.de -----Ursprüngliche Nachricht----- Von: Christofer Dutz <christofer.d...@c-ware.de> Gesendet: Monday, January 13, 2020 1:04 PM An: dev@plc4x.apache.org Betreff: Re: Just added new branch "next-gen-core-2" ... Hi Alvaro, well mixing old and new versions of Drivers and Runtime might be an issue. Julian would probably simply say: "Use our OSGI versions", but then I would respond with: "But we only have valid OSGi bundles for S7". I have to admit that I haven't had a look at any OPC-UA packets yet so I can't judge how long it would take to implement the port of OPC-UA with mspec. I would assume the protocol being very heavy so I would expect it to take a while. Modbus is probably the simplest of all, so I would assume this goes quickly. Chris Am 13.01.20, 11:56 schrieb "Álvaro Del Castillo" <adelcasti...@thingso2.com>: Hi Chris, On Mon, 2020-01-13 at 08:57 +0000, Christofer Dutz wrote: > Hi Alvaro, > > unfortunately the next-gen-core-2 doesn't have any Modbus, OPC-UA, or > EtherNet/IP as these protocols haven't been ported to mspec yet. > As soon as the refactoring is finished at least Modbus and > EtherNet/IP are the next on my list. Ok, once you start the porting to mspec for modbus, I could help in the testing of the results, and in general, reviewing the code. The protocols like OPC-UA which does not have a clear date for the porting, will continue working with the actual version, right? Thank you guys for the great effort in this refactoring!! -- Alvaro > > Chris > > Am 13.01.20, 07:49 schrieb "Álvaro Del Castillo" < > adelcasti...@thingso2.com>: > > Dear all, > > On Sun, 2020-01-12 at 12:30 +0000, Christofer Dutz wrote: > > Hi all, > > > > so as I mentioned in the last email about the scraper, I have > > invested about 7 full days in cleaning up the SPI module after > the > > refactoring session. > > Now hopefully I have untangled some of the code that made it > > extremely hard to understand for me (And probably others). > > I cleaned up in the packages quite a lot as Sebastian told me > that > > the current structure was a result of “just merging multiple > old > > module”. > > I hope it’s a big step forward regarding maintainability of the > SPI. > > > > Also did I remove all deprecated stuff in the SPI. I think if > we’re > > currently going to release all drivers in new versions anyways, > there > > is no need in porting the old ones and then deleting them. > > The changes that we would have needed would have been > significant. So > > now only the next-gen drivers are enabled and all the old ones > are > > commented out of the build (not deleted yet) > > > > I also introduced the concepts of “transports” even if this > concept > > was previously sort of there already, but it wasn’t exposed > very > > well. Now every driver can define a default transport. > > Here for example S7 would define “tcp”, BACnet/IP would define > “udp”, > > AB-ETH would define “serial” … and a connection string like: > > s7://1.2.3.4 would directly use TCP with a default port of 102. > > But we can now override the transport: s7:raw://if4 would use > the > > same S7 driver but use a raw-socket using the network device > “if4” > > for capturing. Interesting for testing will be the “pcap” > transport. > > Here you provide a path to a pcap file in the url and it will > replay > > that as if it were a real “raw” transport. > > > > Every transport defines a Config interface which can provide > > additional information such as the default-port for tcp, the > replay- > > speed for pcap etc. > > The driver configurations can implement these interfaces (but > don’t > > have to). > > A configuration can implement the transport config interfaces > of > > multiple transports. > > > > As the changes were so significant (I think about 250 changed > files) > > … I decided to create a new branch so you can compare the > branches. > > > > Please review them and especially test your drivers … I don’t > think > > that my port of all of them was 100% successful, but sometimes > I > > didn’t have the hardware. > > Is it useful in its current state to test modbus or opc-ua > drivers? > > Cheers! > > > -- Alvaro > > > > > > Chris > > > > >
