Hi Chris,
On Wed, 2022-01-19 at 12:52 +0000, Christofer Dutz wrote:
Hi Stephen,
Thanks for your input :-)
You're welcome, it's easy to be an armchair quarterback.;)
With my statement I was referring to Modbus-TCP which will most
likely be used with TCP,
Agree.
but I agree I should have chosen a different example. (We should
investigate how Modbus-ASCII differs and mabe also directly support
that).
Sorry, my bad, it is actually just ASCII for all PLC's (that I have
used anyway), and it is based on Hayes modem protocol. It is the
traditional serial communication for remote units at places like waste
water treatment plants, etc...
I guess even Modbus is probably the version with the most variants in
transport being used. However, I would highly doubt, that for example
PROFINET will be anything else than raw ethernet frames sent on a raw
transport (with UDP for setting up the connection).
Agreed.
I didn't want to limit PLC4X to use only the "supported" ones, in
general I think if a user wants to do PROFINET via Serial, the
framework shouldn't keep him from trying, but the user shouldn't
expect it to work.
Okay, implimentation specifics can be an area of concern, so in my mind
"expect to work" has always come with caveats and in my experiences
too.
Also testing all these combinations is a bit tricky, as they require
hardware for testing, and I at least don't have that.
I have some ...
* Rockwell Automation Micro820-20QBB, 1xSerial (RS-232/RS-485,
Modbus/ASCII capable), 1xEth (Ethernet/IP, Modbus-TCP)
* Omron CP1H PLC (x2), 2xSerial RS-232 Omron protocols, 1xUSB prg port
* Red Lion Control's G308C, 1xEth, 1xRS485, 2xRS232, 1xUSB, pretty
much any protocol you can pick for all ports except USB. (HMI with a
micro PLC and mini PC more or less)
* Raspberry Pi IIb, 1xEth, 1xSerial (needs linedriver addon for that)
* Allen-Bradley PowerFlex 523 VFD, DSI I believe can run as Modbus RTU
If you need something (code) tested, I don't mind helping. I had a
Modicon PLC around but had to return it, M221.
Would you please be so kind and start a new thread about the problems
you were mentioning?
Sure, let me poke at it for a bit.
Are you planning on bringing your Modbus-RTU work back to the
project? Cause that's been something there was quite a bit of
discussion about and interest for.
Yes, I volunteered to help Ben with it, I forked the repo (Modbus-RTU)
and cloned it which I am working with now.
I think for protocols like EIP, KNX and BacNET there seems to be a
wider range of interpretations in the Specs, and we have seen a
number of "interpretation" by vendors that seem to differ from the
specs. So it might be that for the one or the other device or vendor,
we might have to come up with flavors, variants or modes in the
drivers. However again, this is a bit problematic as we don't have
the hardware.
I want to get the Rockwell Automation CIP protocol (EIP) sorted since I
will be more likely to use it around here in Allen-Bradley land. Again,
any particular needs here I don't mind helping where I can with.
Auto-discovery is also something we have started working on ... I
think the Go version is a bit more ahead regarding that, but for
example PROFINET (WIP) already allows auto-detecting devices. Do you
want to join in on working on this (Auto-discovery in general)?
Yes.
I think regarding your request to tweak the settings of the
transport: Transports do have a list of supported options and we
generally wanted to run the transports with sensible defaults
(defaults provided by the corresponding driver) and make them
overridable with options in the connection-string. So some of this
tweaking should already be possible. However especially regarding
serial transport options, I haven't got any hardware using any non-
defaults, so difficult to test.
Again, testing is something I can do for the above hardware I list.
Unfortunately, I haven't been as active with Siemens S7 products as I
would have liked since the use is low in my area. The S5 and Sinumerik
platforms were the ones I was familiar with, PLC and CNC systems. So I
am not as cozy with Siemens Canada as I was back then. Not sure any of
my old contacts would be around.
Stephen
Chris
-----Original Message-----
From: Stephen Snow <s40...@gmail.com>
Sent: Mittwoch, 19. Januar 2022 13:33
To: dev@plc4x.apache.org; Łukasz Dywicki
<lukasz.dywi...@connectorio.com>
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?
Hello,
I would like to just add to this conversation if I may.
On Wed, 2022-01-19 at 11:00 +0000, Christofer Dutz wrote:
Well the problem with eagerly including transports is:
For example, using Modbus ... most transports being used will
probably
be onls TCP.
Not entirely true, there is Modbus Ascii which is used over serial
and is not limited in scope like RTU. Sometimes referred to as
extended.
And with Modbus-RTU it should only work with Serial, but there are
people using serial-to-network converters, so you also could use
Modbus-RTU via TCP transport
Yes, been there done that.
... also, if we ever support passive-mode we would be adding raw-
passive. I think initially I made the drivers explicitly depend on
the
default transports and have people include the optional ones. I
think
for the raw transports on some systems you needed to run the
application as root or with privileged network access.
So for this project, which is an API to talk to any PLC presumably, I
think that the end use case does determine the extent to which
discovery is desirable. In my use case(s) I am trying to make a
viable product from, I am finding the driver inflexible in the
regards to messaging. As an example, I can connect both via TCP and
via Serial transport to the same PLC. After a bit of bashing, I was
able to get a response via Modbus-RTU from a lone address in the PLC.
But the physical serial connection was established and I could also
build a message manually and just use the serial transport to
send/receive it and works fine. I was getting netty.io complaints
going through the PLC4X protocol. The TCP connection is EIP protocol
and the PLC is a Rockwell Automation Micro820, so at this time I am
going to dig into the EIP protocol bit to determine why the message
is failing with it since the structure is what the PLC is expecting.
I believe that there was some discussion of Allen-Bradley CIP
protocol issues, I'm going to dig into that presently.
But admittedly this has been so many years ago .. I don't even know
if
this is a problem today.
My reasoning on using "supported" is that these are the transports
we
are aware of and explicitly support, if the user uses S7 with
Serial
for example, that's not "supported" and if he has trouble with this
... well I guess it's his problem ;-)
So, I have worked as a Systems Integrator, a Solution Provider, and a
machine builder (turn-key solutions) for a long time and have seen
almost everything that was made for purpose 'A' being made to work
for purpose 'B'. The one thing about PLC's is that they can be used
for a broad range of tasks, though they are more specialized
generally, but that is usually I/O count or motion capability. IMO,
the driver(s) should work with whatever transport is available
(within reason). I frequently am connected (out in the field) to one
device on a network, using one driver, and talking to two or more
devices on the network via pass-thru, which most OEM's like Siemens
support, does PLC4X contemplate supporting such? From the POV of the
user, I would like to connect to a e'net switch, and browse to
connect, this is my current goal, discoverable PLC with automatic
connection.
I understand my use case is likely very specific in that I am a sole
proprietor and follow my customers needs while trying to look out for
their future needs, so I am not always doing the latest and greatest,
just what they require (and are willing to pay for).
So, what would you be proposing on returning? @Łukasz Dywicki ...
instead of returning "tcp" to return "Class<TcpTransport>" (or
however
we do it)?
I would return a transport object, ie the instance that was created.
I need to be able to after connection change things like baud rate
etc., or in the case of Modbus-RTU protocol, the timing of the
communication instructions needs to be configurable and should be
easily exposed with getter/setter methods. Also, from the POV of a
serial transport, I need to be able to set the port mode in some
cases (RS-232 or RS-485 or RS-
422) for whatever purpose, like talking on an RS-232/RS-485/RS-422
network all over the serial port.
Stephen
Chris
-----Original Message-----
From: Łukasz Dywicki <l...@code-house.org>
Sent: Mittwoch, 19. Januar 2022 11:47
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?
I come over this issue yesterday, but on other end. While trying to
get
0.10 running under OSGi I found that "wiring" if fine but whole
thing
fails to work at runtime.
This boils down to several things, but Transport SPI lookup too. I
agree that listing supported transports types (tcp/udp/serial/can)
is
fine for start. On other hand it is unlikely we will ever get S7
working over serial line so we could in theory declare that it
works
only with TcpTransport. Later one is actually beneficiary, at least
for OSGi, cause it makes S7 driver classpath aware of TcpTransport
requirement.
This was issue Etiane was facing back then while working with Camel
components to wire everything in.
Anyhow, I am fine with both, with some level of preference for
listing
transports directly. If we scope dependencies properly end users
will
get drivers working out of the box with very few entries in their
build tool.
Best,
Łukasz
On 19.01.2022 10:44, Christofer Dutz wrote:
Hi Cesar,
right now, I would only like to give back a list of strings that
are
the codes of the supported transports.
Perhaps we should extend the transports to give tooling more
assistance on how a given transport is to be configured.
Chris
-----Original Message-----
From: Cesar Garcia <cesar.gar...@ceos.com.ve>
Sent: Sonntag, 9. Januar 2022 17:29
To: Apache PLC4X <dev@plc4x.apache.org>
Subject: Re: [DISCUSS] Extend PlcDriver with
"supportedTransports"?
How are they?
Not only the transport, but also the data structures of the
items.
This would allow the user to have a reference of what you can
request in the items.
Looking to the future, this would be a must for the OPC-UA
server.
Kind regards,
El dom, 9 ene 2022 a las 6:10, Christofer Dutz
(<christofer.d...@c-ware.de>)
escribió:
Hi all,
I know initially I built the Plc4X API to generally allow any
form
of driver to use any form of transport.
However, this only would have worked in theory.
I think we should probably have every driver provide a list of
supported transports.
This would also help make tool integration easier.
If we see that for example sometimes, we have ModbusRTU passed
along TCP/UDP connections via serial-to-ethernet adapters, we
can
definitely support that and if we come across a mode of
operation,
that we haven't encountered, it should be easy to extend.
But this way we could ensure that we build the drivers in a way
that they know what to expect.
What do you think?
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1,
OFICINA
2, AV. RAUL LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI*
*Ing.
César García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: support.aan.automat...@siemens.com
<support.aan.automat...@siemens.com>*
