You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2020/01/12 12:30:03 UTC
Just added new branch "next-gen-core-2" ...
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.
Chris
Re: Just added new branch "next-gen-core-2" ...
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Chris,
thank you SOO much for all the "housekeeping".
Indeed, during the refactoring we were very focused on specific things and code quality or consistency was not the major goal, so you did a lot here.
And indeed, we merged together multiple modules (and created other ones) so that the structure of the project hopefully is more easily understandable (like explicit transports).
After seeing your work now, I also agree with your approach of doing this transport thing, its cleaner that way overall.
I will have a look at the branch and probably add some comments.
Thank you soo much!
Julian
Am 12.01.20, 13:30 schrieb "Christofer Dutz" <ch...@c-ware.de>:
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.
Chris
AW: Just added new branch "next-gen-core-2" ...
Posted by "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>.
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.strljic@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <ch...@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 <ma...@isw.uni-stuttgart.de>
Gesendet: Dienstag, 14. Januar 2020 10:32:41
An: dev@plc4x.apache.org <de...@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.strljic@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <ch...@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" <ad...@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" <
> adelcastillo@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
> >
>
>
>
AW: Just added new branch "next-gen-core-2" ...
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ma...@isw.uni-stuttgart.de>
Gesendet: Dienstag, 14. Januar 2020 10:32:41
An: dev@plc4x.apache.org <de...@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.strljic@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <ch...@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" <ad...@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" <
> adelcastillo@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
> >
>
>
>
AW: Just added new branch "next-gen-core-2" ...
Posted by "Strljic, Matthias Milan" <ma...@isw.uni-stuttgart.de>.
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.strljic@isw.uni-stuttgart.de
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Christofer Dutz <ch...@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" <ad...@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" <
> adelcastillo@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
> >
>
>
>
Re: Just added new branch "next-gen-core-2" ...
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ad...@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" <
> adelcastillo@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
> >
>
>
>
Re: Just added new branch "next-gen-core-2" ...
Posted by Álvaro Del Castillo <ad...@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" <
> adelcastillo@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
> >
>
>
>
Re: Just added new branch "next-gen-core-2" ...
Posted by Christofer Dutz <ch...@c-ware.de>.
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.
Chris
Am 13.01.20, 07:49 schrieb "Álvaro Del Castillo" <ad...@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
>
Re: Just added new branch "next-gen-core-2" ...
Posted by Álvaro Del Castillo <ad...@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
>