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
> >
>
>
>
