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" <
> [email protected]>:
> 
>     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
>     > 
>     
>     
> 

Reply via email to