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