Re: [PROPOSAL] Implement a Java GUI application for browsing PLCs with PLC4X

[Stephen Snow]

Yeah I can see that WRT examples. 

On Mon, 2022-07-11 at 09:55 -0700, Otto Fowler wrote:
> Sorry, I don’t mean to confuse.
> Since we don’t have examples or documentation, and trying to pick
> between a bunch of people’s personal favorite GUI framework /
> programming language on a list is tiresome, I’m just recommending
> doing the doc, examples in each language, and letting people write a
> GUI in whatever they fancy ( outside the project ). Then a person may
> look at:
> * dependencies
> * what it takes to build
> * code maintainability
> * style and actually GUI
> for each IRL.
> 
> 
> 
> From: Stephen Snow 
> Reply: dev@plc4x.apache.org 
> Date: July 11, 2022 at 08:18:22
> To: dev@plc4x.apache.org 
> Subject:  Re: [PROPOSAL] Implement a Java GUI application for
> browsing PLCs with PLC4X 
> 
> 
> > So I took this to be a discussion about making a graphical browser
> > of
> > connected PLC's that PLC4X api was being used to develop some app
> > with
> > by the dev. In this case using PLC4X's discovery api as part of
> > this
> > tool. Am I missing something here? Otto seems to be referring to
> > implementation examples (which I think is a must for the doc's in
> > any
> > case).
> > 
> > In the spirit of using the Netbeans IDE (which I do) I have a
> > module
> > created which I am ready to add PLC4X functionality to, actually
> > the
> > maven bits are done, I just need to implement. Is there any doc for
> > the
> > discovery lib? Or could someone familiar with it suggest a starting
> > point for me?
> > 
> > Regards,
> > Stephen
> > 
> > On Fri, 2022-07-08 at 10:40 -0700, Otto Fowler wrote:
> > >  you say that like it is a bad thing?
> > > 
> > > From: Christofer Dutz 
> > > 
> > > Reply: dev@plc4x.apache.org 
> > > 
> > > Date: July 7, 2022 at 18:46:01
> > > To: dev@plc4x.apache.org 
> > > 
> > > Subject:  Re: [PROPOSAL] Implement a Java GUI application for
> > > browsing PLCs
> > > with PLC4X
> > > 
> > > So a hello-plc4x-discovery-and-browse using the default api?...
> > That
> > > should
> > > be a matter of minutes to Implement.
> > > 
> > > Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
> > > 
> > > From: Otto Fowler 
> > > Sent: Thursday, July 7, 2022 6:17:49 PM
> > > To: dev@plc4x.apache.org 
> > > Subject: RE: [PROPOSAL] Implement a Java GUI application for
> > browsing
> > > PLCs
> > > with PLC4X
> > > 
> > > I would make the simplest possible example application, in each
> > > language
> > > plc4x supports, just to discover and show the browse ‘tree’ or
> > > whatever.
> > > Maybe console.
> > > 
> > > Then with these examples of API usage, people can have at it and
> > > there can
> > > be a bake off.
> > > 
> > > It will be easier to agree on what a ‘sample.go’, sample.rust,
> > > sample.python etc would look like, and a minimal set of
> > functionality
> > > than
> > > to pick a language and environment etc.
> > > 
> > > the samples have to build everywhere plc4x builds and for
> > everyone,
> > > the
> > > contrib/ui things can be optional so that we don’t have to setup
> > > anything
> > > exotic unless we want to.
> > > 
> > > 
> > > 
> > > 
> > > From: Christofer Dutz 
> > > 
> > > Reply: dev@plc4x.apache.org 
> > > 
> > > Date: June 26, 2022 at 07:11:52
> > > To: dev@plc4x.apache.org 
> > > 
> > > Subject: RE: [PROPOSAL] Implement a Java GUI application for
> > browsing
> > > PLCs
> > > with PLC4X
> > > 
> > > Hi Niclas,
> > > 
> > > yeah ... I agree ... if the core of such a tool is created the
> > right
> > > way,
> > > adding integration-wrappers into other tools should be easy. I
> > guess
> > > sticking to an "as standard as possible ui technology" would help
> > > with
> > > this. So, I could imagine that it's easier to integrate a JavaFX
> > ui
> > > into
> > > Netbeans, Eclips and IntelliJ than any client-server based web-ui
> > > tech.
> > > br/> <
> > > Also, could we consider having one logic core and multiple ui
> > > implementations.
> > > 
> > > Chris
&

Re: [PROPOSAL] Implement a Java GUI application for browsing PLCs with PLC4X

[Stephen Snow]

So I took this to be a discussion about making a graphical browser of
connected PLC's that PLC4X api was being used to develop some app with
by the dev. In this case using PLC4X's discovery api as part of this
tool. Am I missing something here? Otto seems to be referring to
implementation examples (which I think is a must for the doc's in any
case).

In the spirit of using the Netbeans IDE (which I do) I have a module
created which I am ready to add PLC4X functionality to, actually the
maven bits are done, I just need to implement. Is there any doc for the
discovery lib? Or could someone familiar with it suggest a starting
point for me?

Regards,
Stephen

On Fri, 2022-07-08 at 10:40 -0700, Otto Fowler wrote:
>  you say that like it is a bad thing?
> 
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org 
> 
> Date: July 7, 2022 at 18:46:01
> To: dev@plc4x.apache.org 
> 
> Subject:  Re: [PROPOSAL] Implement a Java GUI application for
> browsing PLCs
> with PLC4X
> 
> So a hello-plc4x-discovery-and-browse using the default api?... That
> should
> be a matter of minutes to Implement.
> 
> Holen Sie sich Outlook für Android
> 
> From: Otto Fowler 
> Sent: Thursday, July 7, 2022 6:17:49 PM
> To: dev@plc4x.apache.org 
> Subject: RE: [PROPOSAL] Implement a Java GUI application for browsing
> PLCs
> with PLC4X
> 
> I would make the simplest possible example application, in each
> language
> plc4x supports, just to discover and show the browse ‘tree’ or
> whatever.
> Maybe console.
> 
> Then with these examples of API usage, people can have at it and
> there can
> be a bake off.
> 
> It will be easier to agree on what a ‘sample.go’, sample.rust,
> sample.python etc would look like, and a minimal set of functionality
> than
> to pick a language and environment etc.
> 
> the samples have to build everywhere plc4x builds and for everyone,
> the
> contrib/ui things can be optional so that we don’t have to setup
> anything
> exotic unless we want to.
> 
> 
> 
> 
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org 
> 
> Date: June 26, 2022 at 07:11:52
> To: dev@plc4x.apache.org 
> 
> Subject: RE: [PROPOSAL] Implement a Java GUI application for browsing
> PLCs
> with PLC4X
> 
> Hi Niclas,
> 
> yeah ... I agree ... if the core of such a tool is created the right
> way,
> adding integration-wrappers into other tools should be easy. I guess
> sticking to an "as standard as possible ui technology" would help
> with
> this. So, I could imagine that it's easier to integrate a JavaFX ui
> into
> Netbeans, Eclips and IntelliJ than any client-server based web-ui
> tech.
> br/> <
> Also, could we consider having one logic core and multiple ui
> implementations.
> 
> Chris
> 
> 
> -Original Message-
> From: Niclas Hedhman  br/>Sent:: Samstag, 25.
> Juni 2022
> 07:59
> To: dev@plc4x.apache.org
> Subject: Re: [PROPOSAL] Implement a Java GUI application for browsing
> PLCs
> with PLC4X
> 
> On 2022-06-23 14:36, Christofer Dutz wrote:
> > I agree that if we use NetBeans it’s definitiely “eating our own
> > (Apache) dogfood” … and yes it’s quite well established.
> > Probably you can create Standalone Applications with Netbeans
> > similar
> br/>> to how you can do that with Eclipse. <
> > However, do I imagine, that this would probably be a bit of
> > overkill
> br/>> for this usecase. <
> 
> There is a case to be made for having these kinds of tools being part
> of an
> IDE, i.e. a plugin rather than an "App on NB".
> So, by being a little clever, the clickable-jar could also be
> Netbeans
> plugin compatible, IF that is wanted by people. It is mostly a matter
> of
> having hooks for user input that can be hooked into NB's system
> rather than
> handled directly. Minor thing if one take care of it up front.
> And if it is then a plugin, then it is up to someone else to package
> that
> as a dedicated NB app, if such desires exist.
> 
> 
> Cheers
> Niclas

Re: [PROPOSAL] Implement a Java GUI application for browsing PLCs with PLC4X

[Stephen Snow]

Truly,
To scaffold an application that can be rapidly utilized in Java/Kotlin
I would strongly recommend Quarkus from https://quarkus.io/. It likes
to use the GraalVM and readily can build out to native or native in
container. It can be deployed ootb in development mode with ci
happening as you develop in netbeans say.

Just my 2c worth.

Regards,
Stephen
On Thu, 2022-06-23 at 14:59 +0200, Łukasz Dywicki wrote:
> I been wrapping head around this as I had a necessity to watch
> CANopen 
> traffic decoded by plc4x. I ended up building fairly basic web page 
> which displayed most recent frames (so I could stay with local
> socketcan 
> transport), yet it was far from useful or portable. Recently I also
> did 
> struggle a lot with bloody modbus. My usecases are often focused on 
> making the commissioning to generate further software configuration.
> 
> My little research in topic of desktop applications ended up at
> javafx 
> which allows to make it small and compile to native binary thanks to 
> graal. My experiences with RCP platforms are rather bad (I did some 
> small Eclipse RCP projects), even if I have no issues with OSGi.
> Problem 
> I see in RCP platforms is sparse development documentation, I also 
> perceive both Eclipse RCP and Netbeans as focused mainly on
> organizing 
> navigation while strongly depending on UI frameworks (jface/swt or 
> swing/awt). Effectively you still need to build tables and so on, but
> with much more overhead.
> Please do not take above too seriously in context of Netbeans, I
> don't 
> know much about it and its flexibility. I don't know how to build it 
> with Maven, hence it feels strange.
> For the Kotlin stuff and frameworks there - I can say that any UI 
> project which Google is pushing is a red flag to me. Looking at GWT, 
> Angular 1.x (I used both) I simply fear that they can step back from 
> "experiment" after a year or two leaving everything to the community.
> I 
> looked at kootlin and javafx a while ago and there is not much
> happening 
> there. I don't know if is because of maturity, javafx issues or shift
> to 
> other UI approaches.
> 
> As I had no time to work on it I just postponed that to a future.
> Yet, I 
> still dream from time to time about proper "fieldbus.app". ;-)
> 
> Cheers,
> Łukasz
> 
> On 23.06.2022 14:46, Michal Harakal wrote:
> > Hi,
> > 
> > I would be also interested in, having a strong opinion on
> > technology stack, but fully open to design and function.
> > 
> > My suggestion is writing a Desktop App with Kotlin Jetpack Compose
> > for Desktop:
> > 
> > Props:
> > * modern, state of the art, way to write reactive UI (natural way
> > to implement unidirectional data flows architectures)
> > * JVM target
> > * open source, backed by Google And Jetbrains (they use it in their
> > critical products)
> > * Kotlin provides 1A class interoperability support with Java and
> > JVM
> > * since Jetpack Compose is originally created and used by Android,
> > you can have an Android App out of the box, with little effort
> > * integration with Jetbrains Intellij
> > * even if you don't know Jetpack Compose Framewrok, you can
> > contribute too with your Java/Kotlin skills imedialtely on
> > domain/bussines etc. parts of code ..
> > * easy to learn
> > * with multiplatform support are native apps with their native UI
> > frameworks (e.g. iOS)
> > 
> > Cons:
> > * Still in Alpha
> > * backed by Google and Jetbrains
> > * Kotlin is probably not the number one programming language here
> > 
> > 
> > Best regards,
> > Michal
> > > Christofer Dutz  hat am 23.06.2022
> > > 10:55 geschrieben:
> > > 
> > > 
> > > Hi all,
> > > 
> > > Again, I was in need of a simple application to simply monitor
> > > the values on a Modbus device (I’m currently configuring my Wago
> > > PFC200 Modbus Slave interface).
> > > I could use stuff like the “Modbus Poll” GUI tool, but my trial
> > > expired and I’m not willing to pay 130€ for this limited
> > > functionality.
> > > 
> > > So, I thought, it would be an awesome addition to PLC4X if we had
> > > some sort of GUI application, that uses the Discover
> > > functionality to find possible PLCs and list them in a tree view.
> > > If the use double clicks on one of these connections, it connects
> > > and possibly executes the Browse functionality and lists up what
> > > it finds.
> > > 
> > > I know that I could simply start working on something like that,
> > > but I thought this would also be a great thing for someone else
> > > to implement as it doesn’t require too deep knowledge of PLC4X
> > > internals.
> > > 
> > > And I suck at building beautiful UIs :-)
> > > 
> > > Anyone interested?
> > > 
> > > Chris

Re: [jira] [Commented] (PLC4X-339) modbus connection causes memory leak

[Stephen Snow]

On Wed, 2022-04-27 at 07:30 +, Christofer Dutz (Jira) wrote:
> 
>     [
> https://issues.apache.org/jira/browse/PLC4X-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528601#comment-17528601
>  ]
> 
> Christofer Dutz commented on PLC4X-339:
> ---
> 
> I guess in the end er really should get rid of Netty ... it just adds
> loads of complexity and problems like this ... plc4go and plc4c also
> work fine without any Netty.
> 
Go and C don't use Java libraries for networking protocols like TCP or
UDP I guess, but isn't Netty sort of integral to the communication
stack right now? Just asking is all. I mean it is pretty powerful for
setting up TCP and UDP connections, and serial AFAICT.
> > modbus connection causes memory leak
> > 
> > 
> >     Key: PLC4X-339
> >     URL:
> > https://issues.apache.org/jira/browse/PLC4X-339
> >     Project: Apache PLC4X
> >  Issue Type: Bug
> >  Components: Driver-Modbus
> >    Affects Versions: 0.9.0
> >     Environment: Windows 10; jdk1.8 32bit
> >    Reporter: liangjian
> >    Priority: Major
> > 
> > Note: The version is 0.9.1.
> > 1. The document
> > (here)[https://plc4x.apache.org/users/protocols/modbus.html] seems
> > wrong. It tells me the connection string format is: "modbus-
> > tcp:tcp://127.0.0.1:502", but my test code throws exception saying
> > no driver until I change it to "modbus://127.0.0.1".
> > 2. My test code writes (or reads) some value via modbus tcp every 1
> > second, using short tcp connection (open and close every time).
>From the Netty documentation

"Please note that, close() also might not close the connection
immediately, and it returns a ChannelFuture."

How is the future being handled? Close doesn't always close immediately
according to what it says in the netty documentation at
https://netty.io/wiki/user-guide-for-5.x.html


> >  The memory increases every second until out-of-memory. In process
> > monitor I find the thread count  increases 1 every time the
> > connection opens, but never releases, althought I consider the
> > `try-block` shall closes it automatically. In fact, I see it calls
> > `connection.close` after the `try-block`.
Does connection.close return success? Or anything? Possibly it needs to
reflect that the close operation sometimes doesn't happen immediately
upon request. Again, just asking here since this is an asynchronous
operation, and the thread would stay open until the future completed I
would think.
> > Test code:
> > ```java
> >         while (true) {
> >             String connectionString = "modbus://127.0.0.1";
> >             try (PlcConnection plcConnection = new
> > PlcDriverManager().getConnection(connectionString)) {
> >                 PlcWriteRequest.Builder builder =
> > plcConnection.writeRequestBuilder();
> >                 builder.addItem("value-1", "holding-
> > register:1:DINT", 3);
> >                 builder.addItem("value-2", "holding-
> > register:3:REAL", 3.14);
> >                 PlcWriteRequest writeRequest = builder.build();
> >                 PlcWriteResponse response =
> > writeRequest.execute().get();
> >                 
> >                 for (String fieldName : response.getFieldNames()) {
> >                     if(response.getResponseCode(fieldName) ==
> > PlcResponseCode.OK) {
> >                         System.out.println("Value[" + fieldName +
> > "]: updated");
> >                     }
> >                     // Something went wrong, to output an error
> > message instead.
> >                     else {
> >                         System.out.println("Error[" + fieldName +
> > "]: " + response.getResponseCode(fieldName).name());
> >                     }
> >                 }
> >                 System.out.println("done");
> >             }
> >             Thread.sleep(1000);
> >         }
> > ```
> > It shows the connection is not cleaned properly. 
> > I see it's more efficient to do this using long tcp connection
> > (reuse 1 connection or use a pool). But short tcp connection should
> > also work.
Possibly the "long tcp connection" (is this in time/duration?) success
is an indicator that the future promise has completed?
> >  

> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.20.7#820007)

Regards,
Stephen

Re: [DISCUSS] how to read bool and bool-arrays?

[Stephen Snow]

Hi Chris and Myhongk, et al

Depending on the processor (this would include embedded IIOT devices)
they could be big or little endian, which may complicate matters for
the modbus driver. Being able to set this as a parameter when using the
driver in an app being built which may talk to many modbus devices of
either endian arrangement would likely be beneficial. Byte swapping in
PLC land is common in communication between PLC's/PC's and periphery
devices or other control elements. 

I don't know if that is what you're referring to, but it sure sounds
like endian issues I have encountered in the past (and still today).

Be well,

Stephen
On Fri, 2022-04-22 at 10:26 +, Christofer Dutz wrote:
> Hi all,
> 
> Myhongk just brought up an issue in the Modbus driver, which I think
> could probably also come up in other protocols.
> 
> When reading a BOOL or BOOL[] the driver generally reads chunks of 16
> bits (words). Now we need to define how we count the bits.
> 
> Currently when reading a simple BOOL we do this (0 = skipped, 1 =
> read):
> 
>  0001
> 
> So, the least significant bit is the value and the ones before are
> skipped.
> 
> When reading an array, we currently start at the end. So reading
> BOOL[6] would be this:
> 
> 1100 
> 
> In this case we start at the most significant bits.
> 
> Both variants have its logic and it's downsides.
> 
> Downside by starting at the least significant bits is as soon as we
> read more than 16 bits.
> So, if we read BOOL[19] we'd probably have this
> 
>    0XXX
> 
> Where the indexes in the array would probably be:
> 
> 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0   X X X X X X X X    X X X
> X X 18 17 16
> 
> Or would it be different?
> 
> Another option would be to start at the end of the last word read and
> to count "from right to left"
> 
> 
> If we start at the most significant bits, it would make things easier
> for multiple elements, as we'd have this for BOOL[19]:
> 
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 X X X X X
> X X X X X X X X
> 
> But we would have only read the register value: 32768 or 0x8000 as
> "True".
> 
> 
> Would be cool to know what's the default industry way to do thins
> (I'm sort of expecting an "it depends").
> Possibly we could make it configurable (Which would complicate things
> a bit).
> 
> Another thing is ... in S7 we can address parts of a byte as BOOL by
> using a Bit address ... would it be cool to extend the Modbus to
> allow this too?
> 
> So something like this would work:
> 
> 51.4:BOOL[3]
> 
> Which would return (assuming we start counting at the most
> significant bit):
> 
> X X X X X 1 2 3    X X X X X X X X
> 
> 
> Feedback highly appreciated :-)
> 
> Chris

Re: PLC4Py - Change of Build System - Poetry is for the time beeing not suitable anymore

[Stephen Snow]

On Tue, 2022-04-19 at 21:52 +0200, Lukas Ott wrote:
> Hello PLC4X Developers,
> 
> As shown here: https://github.com/apache/plc4x/pull/348
> 
> We started the discussion to change our build system.
> 
> Poetry has at the moment an increasing amount of issues:
> https://github.com/python-poetry/poetry/issues
> 
> Which are not fixed soon. Even that Poetry is a good solution and was
> the
> right decision to begin with. We need a solution that works for our
> purposes.
> 
> Therefore here are some links comparing different possibilities:
> https://remastr.com/blog/pip-pipenv-poetry-comparison
> 
> https://www.reddit.com/r/Python/comments/limd9t/poetry_vs_pipenv_vs_piptools_what_do_you_use/
> 
> My suggestion would be to go with
> https://pypi.org/project/pip-tools/ It is
> more low-level but also more stable / reliable.
> 
> What are your thoughts?
> 
With python I've only ever used npm since I run Fedora Linux. I find it
very useful, but I am not a daily user of it.

Stephen

> Thank you Ben! It is really fun to read / see your work in the Pull
> request
> :-)
> 
> Cheers,
> Lukas

Re: [DISCUSS] Add a generic "Obejct getDataType()" to the PlcValue?

[Stephen Snow]

Hello Chris,

On Tue, 2022-02-15 at 12:20 +, Christofer Dutz wrote:
> Hi all,
> 
> I'm currently working on Plc4C. Here I need to save the datatype
> along with the plcvalue as there is no such thing as a "instanceof"
> in C.
> While initially this was fixed to a pre-defined list of built-in
> types, I'm currently making this more dynamic.
> 
> This got me thinking: Wouldn't this generally make sense in other
> languages too?
> 
> For example, in KNX there are multiple datatypes which result in the
> same type of PLCValue. However, one is a Power-Consumption in Watt,
> another is a Temperature in °C.
> When parsing this generally isn't an issue, however when serializing
> the representation might vary (One might be that crazy KNX 16-bit
> float, another might be a real IEC Float).
> So we need to keep the datatype in parallel with the PLcValue.
> 
Single precision floating point is one thing this could help with I
guess, but it would really be beneficial when you are thinking about
the complex data-types most of the large-ish PLC's & PAC's have, like
the axis data-type for instance. This makes working with things like
Rockwells Logix family of processors easier I would think. And also
very likely Siemens family of Sinumerik S7 PLC/PAC.

> I think having it IN the plcvalue would be better.
> 
> What do you think?
> 
> 
If it makes sense then yes. Are there caveats to this?
> Chris

Stephen

Re: Thomas ... you still around?

[Stephen Snow]

On Sun, 2022-02-13 at 13:20 +0100, Niclas Hedhman wrote:
> ...snip
> 
> Sorry to intervene... I work a lot with LoraWAN and somehow this
> sounds 
> like "All I have is a hammer so all problems look like a nail." kind
> of 
> thinking.
> 
...snip
> I would be happy to guide you or answer any questions, because I
> think
> the request/reply "mentality" from PLC world doesn't really belong in
> the LoraWAN world.
Yes, largely this is to be blamed on determinism with device level
control. PLC's are built to be deterministic, even over networked
connections. Determinism is next to impossible to maintain without
considerable control overhead, in an asynchronous application. But in
this case, to know the device is reporting not in real time, is not of
importance since the role is data logging, and non mission critical.

Sorry to butt in, just my 2c worth.

Good Luck!
Stephen

Re: [DISCUSS] What should the "Connection Pool" be named?

[Stephen Snow]

Hello,

On Fri, 2022-01-21 at 11:35 +, Christofer Dutz wrote:
> Hi all,
> 
> in the past we had a "ConnectionPool" ... but in reality, we don't
> have a pool of multiple connection to one target, like in databases,
> but usually we have only one connection to each source in the "pool".
> But we can have multiple connections to multiple targets.
> 
> I guess that's why Julian named the new version of the Pool
> "Connection Cache". This sort of comes closer to what it technically
> is.
> 
I don't mind use of either name, personally, but if you have a good
reason for naming it a cache, that should be documented and explained
why (we) feel it is more suitable. This should cover some
implementation details too I would think.
> So now the question is: How should we generally name this thing?
> 
> I would opt to stick with ConnectionPool despite it being more a
> ConnectionCache. The reason for this is that people looking for
> something with the functionality, will probably start looking for a
> ConnectionPool and not a ConnetionCache. I think the inside nature of
> the component is more a context-detail and we should rather provide
> people with what they intuitively would look for.
> 
> But I would like to hear your thoughts on this.
> 
> Chris
To put another wrinkle in this conversation. PLC's and HMI products
that hang on Industrial networks such as all of these wonderful ones we
are talking about, but let's take EIP. I am going to cite an example of
my work day. Customer calls, says "Hey Stephen, can you come over and
look at my FilberFlanger, it's not meshing my grapple grommets?" I say
"Sure, be right over." Pack up my PC and interface goodies to go see
what's the matter. I want to connect to the PLC and watch the process
while connected, live debugging. But the main panel housing the PLC
actually is inside of the Machine guarding and unreachable without
special safety interlock defeating. However, there is a connected HMI
on a serial network I can connect to with USB on it's programming port.
So my programming software for the PLC is now connected through a
network bridge in the device (HMI panel) from my USB eventually to the
EIP network the PLC is on. This is termed "jumping" by Rockwell, and
most PLC's and HMI products they sell will accomodate it. They
(Rockwell, and others I noticed) will usually only offer this through
the use of a more advanced driver, normally referred to as "enterprise"
or some such.
Which finally brings me to my point on drivers, there may need to be
different types considered, as in their expected capabilities. So a
direct connect driver should be the simplest IMO, usable in most IIOT
use cases where you are making a device to "hang off" a PLC EIP or
other open network, like a "smart IO sensor", etc... even for a lot of
the PC based uses. For multiple connections and larger networked
application building it would likely be more appropriate to look at a
server role for the driver. 
The Rockwell micro plc I am playing with now can handle up to 16
simultanious connections on TCP/UDP with either Modbus and EIP for
example, and it is just a small guy. But it will only allow one port
ownership (which ownership is meant for the programming role).

Regards,
Stephen
P.S. if you need some testing for pooled connections to a PLC on a
Modbus or EIP network I can help.

Testing - my hardware list, and change of topic

[Stephen Snow]

Hi Chris,
On Wed, 2022-01-19 at 12:52 +, 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  
> Sent: Mittwoch, 19. Januar 2022 13:33
> To: dev@plc4x.apache.org; Łukasz Dywicki
> 
> 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 +, Christofer Dutz wrote:
> > Well the problem with eagerly including transports is:
>

Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

[Stephen Snow]

Hello,
I would like to just add to this conversation if I may.
On Wed, 2022-01-19 at 11:00 +, 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" (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  
> 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 

Re: Modbus protocol and AB-ETH etc

[Stephen Snow]

On Thu, 2022-01-06 at 15:47 +1000, Ben Hutcheson wrote:
> Hi Stephan,
> 
> Hey that's cool, I'm assuming you're talking about the Modbus RTU
> branch?
Hi Ben, yes Modbus RTU for sure, but also the Allen-Bradley (Rockwell
Automation) protocols using EIP and AB-ETH I want to test. My "lab"
currently has the following at it's disposal as equipment ...
- Micro820 - 2080L20C-20QBB
- Omron CP1H
- Red Lion Controls G308C
- Rockwell Automation VFD 523 Series
- Raspberry Pi 2B with custom IO addon/shields
Plus various sundry in sensors and such for testing.
> 
> I haven't taken a look at any documentation for Modbus RTU, but any
> documentation would go
> into https://github.com/apache/plc4x/tree/develop/src/site/asciidoc.
> The asciidoc plugin for intellij works well to get an idea of how it
> will look.
> 
> I'd be interested in how the Ethernet/IP driver works with the
> Micro820, although I suspect there's a long way to go to get it
> working correctly esp with Rockwell history of having non
> standard CIP messages.
> 
> Some other interesting pages, in case you haven't seen them yet.
> https://plc4x.apache.org/users/getting-started/plc4j.html
> https://plc4x.apache.org/users/protocols/modbus.html
> https://plc4x.apache.org/developers/tutorials/writing-driver.html
> 
I'll have to read the writing driver doc's, read the others have them
bookmarked. 

> Keeping all communication on the mailing list opens it up for others
> to comment and provide feedback on your work. Congrats on the testing
> :)
> 
I don't mind sharing, that's why I started doing this. That's why I
edit for Fedora Magazine.
> Kind Regards
> 
> Ben
> 
So what I am going to work on is mainly trying to document how a user
would implement PLC4X to connect to various type of IIOT  use cases
around these particular PLC models. There will be a mix of networking
topologies in use and different configurations. I am currently (for
potential customer solutions) working through how I would be using
PLC4X for my customers, so some of that stuff will eventually bleed
through as this is a sample of their hardware in use today.

Regards,
Stephen

> On Thu, Jan 6, 2022 at 1:30 AM Stephen Snow  wrote:
> > Hi Ben,
> > Just to let you know I am still testing when I get the opportunity.
> > I
> > had to return the loaner Modicon PLc but got an Rockwell Automation
> > Micro820 along the way. I want to start cleaning up documentation
> > now.
> > I need to continue with testing for Modbus, which I will begin once
> > I
> > re-install my modbus network (I am adding some other devices than a
> > PLC). 
> > So what I would like is to know if there is a set of doc's now
> > somewhere, like maybe howto/FAQ that I can dig into. What I am
> > after is
> > first to elaborate a bit about how PLC4X constructs a message to
> > read/write from/to a PLC/device, ie the description of how to do
> > this
> > with  at higher level than
> > imlementation details. This is from the user implemantation POV
> > this
> > documentation that I want to help with. Also am wanting some help
> > with
> > proper message building, from the POV of what was intended. I have
> > been
> > able to connect to both a serial (via USB) cable to a modbus port
> > on a
> > Modicon M221 PLC and read a data value in Modbus mapped word
> > corresponding to addresss %MW0 in the PLC. I have also been
> > connected
> > to the Rockwell Micro820, but have yet to read any usable info from
> > it.
> > So, I am beginning to build up some information on connectivity
> > errors
> > seen with improper configuration or malformed connection string, as
> > well as during hardware issues (on Modbus teminations). This I
> > would
> > like to incorporate into doc's for help for end users, possibly a
> > generic mashing together of different PLC OEM's white
> > papers/technical
> > notes/knowledge base articles about Modbus networks.
> > So if you have any advice on these topics, please don't hesitate to
> > provide it, I'm pretty open to suggestions.
> > 
> > Regards,
> > Stephen

Re: [DISCUSS] Officially go to Java 11

[Stephen Snow]

Hi Chris,

Thank you for the reply. I understand there are Windows Me users too
who would not want to lose Java 8 capability.

Stephen

On Fri, 2021-12-17 at 15:04 +, Christofer Dutz wrote:
> Hi Stephan,
> 
> I fully agree, however we're talking about people that run Windows XP
> for "reasons" ... some embedded hardware is very behind regarding
> updates. For example I have an edge router device that only runs Java
> 8 as latest version.
> 
> So we just didn't want to exclude potential users if this doesn't
> bring a big advantage for us.
> 
> I guess that's why we sticked to Java 8. But I'm more than happy to
> drop that requirement now. If then all of a sudden industry realizes
> they need something for Java 8 they can always hire and pay someone
> to do it ;-)
> 
> Chris
> 
> 
> -Original Message-
> From: Stephen Snow  
> Sent: Freitag, 17. Dezember 2021 14:38
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] Officially go to Java 11
> 
> Isn't Java 11 pretty much default on any OS offering out there? Also
> Java 17 is now the new stable future Java and is being adopted as the
> default on leading edge OS's such as Fedora Linux for FC36 as
> example.
> I understand that in the enterprise world Java 8 will likely be in
> use for some time in various areas, but I would think Java 11 will be
> dominent there if it isn't already. 
> Just my opinion on it.
> 
> Regards,
> Stephen
> 
> On Fri, 2021-12-17 at 12:16 +, Christofer Dutz wrote:
> > Well yes, and no ...
> > 
> > Generally, we should be Java 8 buildable (just plc4j) ... however
> > some 
> > code had been added to the code generation that broke this "build
> > on 
> > 8" feature (at least I know of the "orElseThrow()" usage.
> > 
> > So we could fix this and make it buildable with Java 8 again ... or
> > for the sake of simplicity we simply give up on Java 8 and simply 
> > continue to ensure the libraries we build are runnable on 8.
> > 
> > Chris
> > 
> > 
> > 
> > -Original Message-
> > From: Otto Fowler 
> > Sent: Freitag, 17. Dezember 2021 13:06
> > To: dev@plc4x.apache.org
> > Subject: Re: [DISCUSS] Officially go to Java 11
> > 
> >  Just to clarify, we have required Java 11 to build for some time
> > now, 
> > but our documentation has still stated java 8 or even both 11 and 8
> > in 
> > different places for a while now.
> > 
> > From: Christofer Dutz  
> > 
> > Reply: dev@plc4x.apache.org  
> > 
> > Date: December 14, 2021 at 10:38:19
> > To: dev@plc4x.apache.org 
> > 
> > Subject:  [DISCUSS] Officially go to Java 11
> > 
> > Hi all,
> > 
> > Otto just bumped me about us still referencing Java 8 as minimum 
> > version.
> > 
> > I think we could be Java 8 compatible, if we only want to build the
> > java part.
> > However as soon as we also build c or go, we need 11 due to the 
> > cmake-maven-plugin.
> > Also do we need it in order to build some of the integration
> > modules.
> > 
> > So I think instead of investing time into ironing out the Java 8 
> > incompatibilities, I would like to make the minimum version 11 
> > officially.
> > 
> > I know that in the past I said, that customers might be needing
> > Java 
> > 1.8, but as officially almost nobody admits using PLC4X and we know
> > nothing about the setups people are using we'll simply do a
> > decision 
> > on the facts known to us.
> > 
> > Right now, this is:
> > 
> > * Supporting Java 8 adds more work for me and doesn't bring an 
> > advantage that I'm aware of.
> > * Sebastian would love to officially be allowed to use Java 11 
> > goodness
> > 
> > Chris
> 

Re: [DISCUSS] Officially go to Java 11

[Stephen Snow]

Isn't Java 11 pretty much default on any OS offering out there? Also
Java 17 is now the new stable future Java and is being adopted as the
default on leading edge OS's such as Fedora Linux for FC36 as example.
I understand that in the enterprise world Java 8 will likely be in use
for some time in various areas, but I would think Java 11 will be
dominent there if it isn't already. 
Just my opinion on it.

Regards,
Stephen

On Fri, 2021-12-17 at 12:16 +, Christofer Dutz wrote:
> Well yes, and no ...
> 
> Generally, we should be Java 8 buildable (just plc4j) ... however
> some code had been added to the code generation that broke this
> "build on 8" feature (at least I know of the "orElseThrow()" usage.
> 
> So we could fix this and make it buildable with Java 8 again ... or
> for the sake of simplicity we simply give up on Java 8 and simply
> continue to ensure the libraries we build are runnable on 8.
> 
> Chris
> 
> 
> 
> -Original Message-
> From: Otto Fowler  
> Sent: Freitag, 17. Dezember 2021 13:06
> To: dev@plc4x.apache.org
> Subject: Re: [DISCUSS] Officially go to Java 11
> 
>  Just to clarify, we have required Java 11 to build for some time
> now, but our documentation has still stated java 8 or even both 11
> and 8 in different places for a while now.
> 
> From: Christofer Dutz 
> 
> Reply: dev@plc4x.apache.org 
> 
> Date: December 14, 2021 at 10:38:19
> To: dev@plc4x.apache.org 
> 
> Subject:  [DISCUSS] Officially go to Java 11
> 
> Hi all,
> 
> Otto just bumped me about us still referencing Java 8 as minimum
> version.
> 
> I think we could be Java 8 compatible, if we only want to build the
> java part.
> However as soon as we also build c or go, we need 11 due to the
> cmake-maven-plugin.
> Also do we need it in order to build some of the integration modules.
> 
> So I think instead of investing time into ironing out the Java 8
> incompatibilities, I would like to make the minimum version 11
> officially.
> 
> I know that in the past I said, that customers might be needing Java
> 1.8, but as officially almost nobody admits using PLC4X and we know
> nothing about the setups people are using we'll simply do a decision
> on the facts known to us.
> 
> Right now, this is:
> 
> * Supporting Java 8 adds more work for me and doesn't bring an
> advantage that I'm aware of.
> * Sebastian would love to officially be allowed to use Java 11
> goodness
> 
> Chris

Re: [jira] [Comment Edited] (PLC4X-303) OPCUA should support username / password authentication

[Stephen Snow]

Hello Torsten,

--snip

> 1. the boolean field "ns=2;s=HelloWorld/ScalarTypes/Boolean" is
> returned as '0' (in 0.8.0 it is returned as 'false')

By definition boolean has two states, false and true. In PLC
perspective, and digital in general, false=0 and true=1.

> 2. if I provide wrong credentials in the URL, the app will hang in
> call of new PlcDriverManager().getConnection( connectionString ) and
> never come back.
>  !screenshot-1.png! 
> The console outputs: [nioEventLoopGroup-2-1] ERROR
> org.apache.plc4x.java.opcua.context.SecureChannel - Failed to connect
> to opc ua server for the following reason:- 2149580800,
> BadIdentityTokenInvalid
> I would expect some kind of exception. 
> 
You likely need to surround it with a try catch pair. I would expect to
have incorrect credentials entered randomly.

--snip

Just offering my opinion, not answering for anyone.
Regards,
Stephen

Re: AW: Modbus RTU

[Stephen Snow]

Hi Ben,
I forked the repo, actually had it forked for snapshot 0.7.0 so just
had to merge the commits from the repo.

On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote:
> Hi Stephen,
> 
> I have pushed support for RTU to the branch feature/modbusrtu, it
> seems to
> work. I've only used RTU over TCP using the connection string
> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update
> docs,
> test and refactoring.
> 
> Until it gets merged into the develop branch it won't appear in the
> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch
> using

I couldn't find that branch listed. I see 48 branches in my fork.

> maven. Once you have built it then it will get stored in your maven
> repository cache as the 0.9.0-SNAPSHOT
> 
> As you are looking at contributing you should take a look at
> https://plc4x.apache.org/developers/contributing.html
> This gives you an overview of how to fork the main repository and
> keep it
> up to date.
> 
> Once you have it forked then you should be able to update your copy
> and
> push the changes to your fork. This should then request you to create
> a PR
> (You can change it to push to the feature/modbusrtu branch on the
> main
> repository) which we can review. A simple change if you want to test
> it
> would be to add a Modbus RTU ascii doc to the folder
> src/site/asciidoc/users/protocols folder based on the existing Modbus
> TCP
> page.
> 
> There's plenty of people activate that are generally more than happy
> to
> help if you have any questions
> 
> Ben
> 
> 
Any thoughts?
Stephen

> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow 
> wrote:
> 
> > Hi Ben,
> > 
> > On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> > > Hi Stephen,
> > > 
> > > Thank you for the offer and if it's ok I'll certainly take you up
> > > on
> > > it.
> > > 
> > Sure, what snapshot should I point maven to? Currently I have 0.8.0
> > that I was playing with a bit yesterday.
> > 
> > > Next week I'll be starting a new job so I won't be contributing
> > > for a
> > > while, However I'll try and get something up and running this
> > > week.
> > > If you
> > > are able to test it and/or take over the implementation from
> > > there it
> > > would
> > > be great.
> > Should I fork the repo? Where do I look for the directions on PR's
> > etc...?
> > 
> > Stephen
> > 
> > > 
> > > Ben
> > > 
> > > On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow 
> > > wrote:
> > > 
> > > > I'd be more than willing to setup some equipment for a lab to
> > > > test
> > > > with. Readily available to me are a couple of Omron CP1-H CPU's
> > > > and
> > > > a
> > > > Red Lion G3800C (which is outdated, but communicates with
> > > > everything
> > > > ootb), plus I can easily get some Modicon stuff as well. The
> > > > Omrons
> > > > are
> > > > fitted with serial ports capable of communicating RS-485 in
> > > > modbus
> > > > RTU,
> > > > and the RLC HMI can talk Modbus TCP as well, so that is without
> > > > laying
> > > > my hands on some Modicon equipment.
> > > > 
> > > > Let me know, and I can start pretty much as soon as I clear
> > > > space
> > > > on my
> > > > lab bench for the setup.
> > > > 
> > > > Stephen
> > > > 
> > > > 
> > > > On Mon, 2021-08-16 at 11:44 +, Christofer Dutz wrote:
> > > > > Hi Stephen,
> > > > > 
> > > > > it's not that we're dropping anything ... it's just that we
> > > > > haven't
> > > > > put any work into creating such a driver. Some day, if
> > > > > someone
> > > > > stumbles over PLC4X with the need to use ASCII, we might
> > > > > implement it
> > > > > for them (Mabe as a paid-gig or not).
> > > > > 
> > > > > In the inital days of PLC4X I invested a huge amount of time
> > > > > into
> > > > > thinking what the industry could need ... I switched to the
> > > > > way
> > > > > more
> > > > > healthy mode of implementing was is actually needed and when
> > > > > it's
> > > > > needed.
> > > > > 
> > > > > But I agree ... Modbus TCP, Modbus RTU (over RS or

Re: AW: Modbus RTU

[Stephen Snow]

Thanks Ben,
I'll get set up and fork the branch you noted. 
I'm sure I'll need some hand holding, but I'll try to not be much
bother.

Regards,
Stephen

On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote:
> Hi Stephen,
> 
> I have pushed support for RTU to the branch feature/modbusrtu, it
> seems to
> work. I've only used RTU over TCP using the connection string
> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update
> docs,
> test and refactoring.
> 
> Until it gets merged into the develop branch it won't appear in the
> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch
> using
> maven. Once you have built it then it will get stored in your maven
> repository cache as the 0.9.0-SNAPSHOT
> 
> As you are looking at contributing you should take a look at
> https://plc4x.apache.org/developers/contributing.html
> This gives you an overview of how to fork the main repository and
> keep it
> up to date.
> 
> Once you have it forked then you should be able to update your copy
> and
> push the changes to your fork. This should then request you to create
> a PR
> (You can change it to push to the feature/modbusrtu branch on the
> main
> repository) which we can review. A simple change if you want to test
> it
> would be to add a Modbus RTU ascii doc to the folder
> src/site/asciidoc/users/protocols folder based on the existing Modbus
> TCP
> page.
> 
> There's plenty of people activate that are generally more than happy
> to
> help if you have any questions
> 
> Ben
> 
> 
> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow 
> wrote:
> 
> > Hi Ben,
> > 
> > On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> > > Hi Stephen,
> > > 
> > > Thank you for the offer and if it's ok I'll certainly take you up
> > > on
> > > it.
> > > 
> > Sure, what snapshot should I point maven to? Currently I have 0.8.0
> > that I was playing with a bit yesterday.
> > 
> > > Next week I'll be starting a new job so I won't be contributing
> > > for a
> > > while, However I'll try and get something up and running this
> > > week.
> > > If you
> > > are able to test it and/or take over the implementation from
> > > there it
> > > would
> > > be great.
> > Should I fork the repo? Where do I look for the directions on PR's
> > etc...?
> > 
> > Stephen
> > 
> > > 
> > > Ben
> > > 
> > > On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow 
> > > wrote:
> > > 
> > > > I'd be more than willing to setup some equipment for a lab to
> > > > test
> > > > with. Readily available to me are a couple of Omron CP1-H CPU's
> > > > and
> > > > a
> > > > Red Lion G3800C (which is outdated, but communicates with
> > > > everything
> > > > ootb), plus I can easily get some Modicon stuff as well. The
> > > > Omrons
> > > > are
> > > > fitted with serial ports capable of communicating RS-485 in
> > > > modbus
> > > > RTU,
> > > > and the RLC HMI can talk Modbus TCP as well, so that is without
> > > > laying
> > > > my hands on some Modicon equipment.
> > > > 
> > > > Let me know, and I can start pretty much as soon as I clear
> > > > space
> > > > on my
> > > > lab bench for the setup.
> > > > 
> > > > Stephen
> > > > 
> > > > 
> > > > On Mon, 2021-08-16 at 11:44 +, Christofer Dutz wrote:
> > > > > Hi Stephen,
> > > > > 
> > > > > it's not that we're dropping anything ... it's just that we
> > > > > haven't
> > > > > put any work into creating such a driver. Some day, if
> > > > > someone
> > > > > stumbles over PLC4X with the need to use ASCII, we might
> > > > > implement it
> > > > > for them (Mabe as a paid-gig or not).
> > > > > 
> > > > > In the inital days of PLC4X I invested a huge amount of time
> > > > > into
> > > > > thinking what the industry could need ... I switched to the
> > > > > way
> > > > > more
> > > > > healthy mode of implementing was is actually needed and when
> > > > > it's
> > > > > needed.
> > > > > 
> > > > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > > > definitely flavors

Re: AW: Modbus RTU

[Stephen Snow]

Hi Ben,

On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> Hi Stephen,
> 
> Thank you for the offer and if it's ok I'll certainly take you up on
> it.
> 
Sure, what snapshot should I point maven to? Currently I have 0.8.0
that I was playing with a bit yesterday.

> Next week I'll be starting a new job so I won't be contributing for a
> while, However I'll try and get something up and running this week.
> If you
> are able to test it and/or take over the implementation from there it
> would
> be great.
Should I fork the repo? Where do I look for the directions on PR's
etc...?

Stephen

> 
> Ben
> 
> On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow 
> wrote:
> 
> > I'd be more than willing to setup some equipment for a lab to test
> > with. Readily available to me are a couple of Omron CP1-H CPU's and
> > a
> > Red Lion G3800C (which is outdated, but communicates with
> > everything
> > ootb), plus I can easily get some Modicon stuff as well. The Omrons
> > are
> > fitted with serial ports capable of communicating RS-485 in modbus
> > RTU,
> > and the RLC HMI can talk Modbus TCP as well, so that is without
> > laying
> > my hands on some Modicon equipment.
> > 
> > Let me know, and I can start pretty much as soon as I clear space
> > on my
> > lab bench for the setup.
> > 
> > Stephen
> > 
> > 
> > On Mon, 2021-08-16 at 11:44 +, Christofer Dutz wrote:
> > > Hi Stephen,
> > > 
> > > it's not that we're dropping anything ... it's just that we
> > > haven't
> > > put any work into creating such a driver. Some day, if someone
> > > stumbles over PLC4X with the need to use ASCII, we might
> > > implement it
> > > for them (Mabe as a paid-gig or not).
> > > 
> > > In the inital days of PLC4X I invested a huge amount of time into
> > > thinking what the industry could need ... I switched to the way
> > > more
> > > healthy mode of implementing was is actually needed and when it's
> > > needed.
> > > 
> > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > definitely flavors we should be supporting.
> > > 
> > > Chris
> > > 
> > > 
> > > -Ursprüngliche Nachricht-
> > > Von: Stephen Snow 
> > > Gesendet: Montag, 16. August 2021 13:39
> > > An: dev@plc4x.apache.org
> > > Betreff: Re: Modbus RTU
> > > 
> > > So I use modbus in all it's flavours, including modbusRTU and
> > > Modbus
> > > TCP. And the newer flavours Modicon is using now. Modbus RTU is
> > > definitely in heavy use on industrial equipment I encounter. It
> > > is
> > > commonly a drive networking choice, and a HMI networking choice.
> > > So,
> > > depending on what is using it ASCII is likely needed too. The one
> > > thing you don't want to do is drop ASCII.
> > > 
> > > Regards,
> > > Stephen
> > > 
> > > 
> > > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > > Then each driver flavor of modbus (rtu, ascii, tcp) would
> > > > > simply
> > > > > need to wrap and unwrap structures coming from an transport.
> > > > 
> > > > seeing the ascii variant since the 1980s or early 1990s. IIUIC,
> > > > it
> > > > was
> > > > mostly used for hand terminals, and not to connect to
> > > > computers.
> > > > So I wouldn't spend time on that, unless nothing else is
> > > > around.
> > > > 
> > > > I haven't checked the mspec in details, but I suspect it is
> > > > close
> > > > to
> > > > fair amount of equipment has extensions that are not in the
> > > > specification (well, at least last time I read it about 20
> > > > years
> > > > ago),
> > > > namely floating point numbers and 32/64-bit integers. It would
> > > > be
> > > > neat
> > > > to support that...
> > > > 
> > > > Unfortunately, I don't have cycles to help out with it.
> > > > 
> > > > Cheers
> > > > Niclas
> > > 
> > > 
> > 
> > 
> > 

Re: AW: Modbus RTU

[Stephen Snow]

I'd be more than willing to setup some equipment for a lab to test
with. Readily available to me are a couple of Omron CP1-H CPU's and a
Red Lion G3800C (which is outdated, but communicates with everything
ootb), plus I can easily get some Modicon stuff as well. The Omrons are
fitted with serial ports capable of communicating RS-485 in modbus RTU,
and the RLC HMI can talk Modbus TCP as well, so that is without laying
my hands on some Modicon equipment.

Let me know, and I can start pretty much as soon as I clear space on my
lab bench for the setup.

Stephen


On Mon, 2021-08-16 at 11:44 +, Christofer Dutz wrote:
> Hi Stephen,
> 
> it's not that we're dropping anything ... it's just that we haven't
> put any work into creating such a driver. Some day, if someone
> stumbles over PLC4X with the need to use ASCII, we might implement it
> for them (Mabe as a paid-gig or not). 
> 
> In the inital days of PLC4X I invested a huge amount of time into
> thinking what the industry could need ... I switched to the way more
> healthy mode of implementing was is actually needed and when it's
> needed.
> 
> But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> definitely flavors we should be supporting.
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Stephen Snow  
> Gesendet: Montag, 16. August 2021 13:39
> An: dev@plc4x.apache.org
> Betreff: Re: Modbus RTU
> 
> So I use modbus in all it's flavours, including modbusRTU and Modbus
> TCP. And the newer flavours Modicon is using now. Modbus RTU is
> definitely in heavy use on industrial equipment I encounter. It is
> commonly a drive networking choice, and a HMI networking choice. So,
> depending on what is using it ASCII is likely needed too. The one
> thing you don't want to do is drop ASCII.
> 
> Regards,
> Stephen
> 
> 
> On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > Then each driver flavor of modbus (rtu, ascii, tcp) would simply 
> > > need to wrap and unwrap structures coming from an transport.
> > 
> > seeing the ascii variant since the 1980s or early 1990s. IIUIC, it
> > was 
> > mostly used for hand terminals, and not to connect to computers.
> > So I wouldn't spend time on that, unless nothing else is around.
> > 
> > I haven't checked the mspec in details, but I suspect it is close
> > to 
> > fair amount of equipment has extensions that are not in the 
> > specification (well, at least last time I read it about 20 years
> > ago), 
> > namely floating point numbers and 32/64-bit integers. It would be
> > neat 
> > to support that...
> > 
> > Unfortunately, I don't have cycles to help out with it.
> > 
> > Cheers
> > Niclas
> 
> 

Re: Modbus RTU

[Stephen Snow]

So I use modbus in all it's flavours, including modbusRTU and Modbus
TCP. And the newer flavours Modicon is using now. Modbus RTU is
definitely in heavy use on industrial equipment I encounter. It is
commonly a drive networking choice, and a HMI networking choice. So,
depending on what is using it ASCII is likely needed too. The one thing
you don't want to do is drop ASCII.

Regards,
Stephen


On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > Then each driver flavor of modbus (rtu, ascii, tcp) would simply
> > need 
> > to
> > wrap and unwrap structures coming from an transport.
> 
> seeing the ascii variant since the 1980s or early 1990s. IIUIC, it
> was 
> mostly used for hand terminals, and not to connect to computers.
> So I wouldn't spend time on that, unless nothing else is around.
> 
> I haven't checked the mspec in details, but I suspect it is close to 
> formal specification. But I would like to bring attention to that a
> fair 
> amount of equipment has extensions that are not in the specification 
> (well, at least last time I read it about 20 years ago), namely
> floating 
> point numbers and 32/64-bit integers. It would be neat to support 
> that...
> 
> Unfortunately, I don't have cycles to help out with it.
> 
> Cheers
> Niclas

Re: DF1 protocol ...cant find documentation

[Stephen Snow]

gt; > > > > hyper doc or
> > > > > > > > HyperTerminal to connected PLC to verify respose
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Tue, Mar 16, 2021 at 6:26 PM Christofer Dutz
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Hi Gaurav,
> > > > > > > > > 
> > > > > > > > > yes, the driver sources are there and the protocol
> > > > > > > > > sources, used
> > > > > > > > > for code generation are here:
> > > > > > > > > https://github.com/apache/plc4x/tree/develop/protocols/df1
> > > > > > > > > 
> > > > > > > > > Just ask, if you need any help.
> > > > > > > > > 
> > > > > > > > > Chris
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -Ursprüngliche Nachricht-
> > > > > > > > > Von: Gaurav P 
> > > > > > > > > Gesendet: Dienstag, 16. März 2021 12:11
> > > > > > > > > An: dev@plc4x.apache.org
> > > > > > > > > Betreff: Re: DF1 protocol ...cant find documentation
> > > > > > > > > 
> > > > > > > > > Thanks Looks I would need to modify source DF1
> > > > > > > > > driver  ... is
> > > > > > > > > the latest source is at :
> > > > > > > > > 
> > > > > https://github.com/apache/plc4x/tree/develop/sandbox/test-java-df1-d
> > > > > r
> > > > > > > > > iver
> > > > > > > > > ?
> > > > > > > > > or somewhere else
> > > > > > > > > 
> > > > > > > > > On Sun, Mar 14, 2021 at 5:09 PM Christofer Dutz
> > > > > > > > >  > > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > HI Gaurav,
> > > > > > > > > > 
> > > > > > > > > > I would probably use a byte-array field, but no
> > > > > > > > > > idea if the DF1
> > > > > > > > > > driver supports that:
> > > > > > > > > > 
> > > > > > > > > > Theoretically this would look like this:
> > > > > > > > > > 
> > > > > > > > > > PlcReadRequest request =
> > > > > > > > > > plcConnection.readRequestBuilder()
> > > > > > > > > >     .addItem("N7:1", "5:USINT[12]")
> > > > > > > > > >     .build();
> > > > > > > > > > 
> > > > > > > > > > Hope that helps.
> > > > > > > > > > 
> > > > > > > > > > Chris
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > -Ursprüngliche Nachricht-
> > > > > > > > > > Von: Gaurav P 
> > > > > > > > > > Gesendet: Sonntag, 14. März 2021 03:21
> > > > > > > > > > An: dev@plc4x.apache.org
> > > > > > > > > > Betreff: Re: DF1 protocol ...cant find
> > > > > > > > > > documentation
> > > > > > > > > > 
> > > > > > > > > > Hi Chris,
> > > > > > > > > > 
> > > > > > > > > > Currently, for testing, I am creating a web service
> > > > > > > > > > API that
> > > > > > > > > > will use PLC4X to construct a command  and expects
> > > > > > > > > > a command as
> > > > > > > > > > hex string which can be used by native client to
> > > > > > > > > > send command ?
> > > > > > > > > > Code
> > > > > > > > > > 
> > > > > > > > > > PlcReadR

Re: DF1 protocol ...cant find documentation

[Stephen Snow]

Hello Gaurav,

The Rockwell Automation DF1 protocol manual, publication # 1770-rm516_-
en-p.pdf is freely downloadable and indeed searchable via google/duck
duck go/others. Just did it myself.

Regards,
Stephen


On Tue, 2021-03-16 at 22:13 +0530, Gaurav P wrote:
> Thanks ChrisI want to generate output of command to read and
> write in
> plc 5  register in hex which I can send over serial via some tool
> like
> hyperterminal and verify in ladders
> 
> On Tue, 16 Mar 2021, 18:26 Christofer Dutz,
> 
> wrote:
> 
> > Hi Gaurav,
> > 
> > yes, the driver sources are there and the protocol sources, used
> > for code
> > generation are here:
> > https://github.com/apache/plc4x/tree/develop/protocols/df1
> > 
> > Just ask, if you need any help.
> > 
> > Chris
> > 
> > 
> > -Ursprüngliche Nachricht-
> > Von: Gaurav P 
> > Gesendet: Dienstag, 16. März 2021 12:11
> > An: dev@plc4x.apache.org
> > Betreff: Re: DF1 protocol ...cant find documentation
> > 
> > Thanks Looks I would need to modify source DF1 driver  ... is the
> > latest
> > source is at :
> > https://github.com/apache/plc4x/tree/develop/sandbox/test-java-df1-driver
> > ?
> > or somewhere else
> > 
> > On Sun, Mar 14, 2021 at 5:09 PM Christofer Dutz
> >  > > 
> > wrote:
> > 
> > > HI Gaurav,
> > > 
> > > I would probably use a byte-array field, but no idea if the DF1
> > > driver
> > > supports that:
> > > 
> > > Theoretically this would look like this:
> > > 
> > > PlcReadRequest request = plcConnection.readRequestBuilder()
> > >     .addItem("N7:1", "5:USINT[12]")
> > >     .build();
> > > 
> > > Hope that helps.
> > > 
> > > Chris
> > > 
> > > 
> > > -Ursprüngliche Nachricht-
> > > Von: Gaurav P 
> > > Gesendet: Sonntag, 14. März 2021 03:21
> > > An: dev@plc4x.apache.org
> > > Betreff: Re: DF1 protocol ...cant find documentation
> > > 
> > > Hi Chris,
> > > 
> > > Currently, for testing, I am creating a web service API that will
> > > use
> > > PLC4X to construct a command  and expects a command as hex string
> > > which can be used by native client to send command ?
> > > Code
> > > 
> > > PlcReadRequest request = plcConnection.readRequestBuilder()
> > >     .addItem("N7:1", "5:INTEGER")
> > >     .build();
> > > 
> > > 
> > > How do I get a command which is constructed and send as hex like
> > > 10 02
> > > 08
> > > 09 06 00 02 04 03 10 03 E0  from the request builder ?
> > > 
> > > Thanks and Regards ,
> > > Gaurav
> > > 
> > > 
> > > On Tue, Mar 9, 2021 at 5:57 PM Christofer Dutz
> > > 
> > > wrote:
> > > 
> > > > Hi Gaurav,
> > > > 
> > > > Generally, what you could do, it to create a custom transport
> > > > implementation.
> > > > 
> > > > You could create one using the C lib and the Java Native
> > > > Interface.
> > > > 
> > > > All drivers are intentionally built in a way that the actual
> > > > communication medium can be changed.
> > > > 
> > > > Chris
> > > > 
> > > > 
> > > > -Ursprüngliche Nachricht-
> > > > Von: Gaurav P 
> > > > Gesendet: Dienstag, 9. März 2021 11:32
> > > > An: dev@plc4x.apache.org
> > > > Betreff: Re: DF1 protocol ...cant find documentation
> > > > 
> > > > Hi All ,
> > > > 
> > > > I used python to send raw commands to plc it worked...as I have
> > > > custom
> > > > rs232 shield and manufacturer has provided libraries in c and
> > > > python
> > > > its there anyway I  can get  df1 raw packets from plc4x 
> > > > ..and
> > > > call flask API I made in python post testing will write a
> > > > jni
> > > > wrapper rs232 shield
> > > > 
> > > > On Fri, Feb 26, 2021 at 6:30 PM Stephen Snow 
> > > > wrote:
> > > > 
> > > > > Hello,
> > > > > I am sorry I haven't gotten to ask my customer for the SLC500
> > > > > hardware so I couldn't test your code. I'll be at their
> > > > > location
> > > > > Monday of 

Re: AW: Source Time of PLC Value?

[Stephen Snow]

On Thu, 2021-03-11 at 19:13 +0100, Łukasz Dywicki wrote:
> [snip] ..

> While I do appreciate work made to bring all (C/Python/C#?) languages
> under Apache PLC4X umbrella I also do see that sometimes they are
> being
> {snip]

> Isn't it a time to make sure that C/C#/Python can still compile with
> 0.8
> release?  
Is no one else supporting these beside Chris? That is seemingly unfair.
I would be willing to try some work with Python, what version is in use
in the PLC4X?


[great big snip]

I am more familiar with Java and prefer it, but since I am a Fedora guy
I use Python on occasion, currently Python 3, but 2 is still doable if
necessary. I would be willing to try to help in this area if there is
lacking support.

Regards,
Stephen

Re: [DISCUSS] Minimum sampling interval on change of state subscription

[Stephen Snow]

I  will just add some of my experience with both older and newer PLC's.
First when I am referring to 'older' it generally means PLC's made
prior to the advent of object oriented control architecture that is
being employed by such OEM's as the current Siemens, Rockwell, Modicon
controllers which can have complex data structures that combine most if
not all primitive datat structures as well as user defined ones. These
are the 'newer PLC's and they have better communication handling
capablities as they were designed for this purpose. 
Irrespective of the age though, in most cases communication is divided
into different priorities by the PLC itself, an example would be when a
programming terminal is connected to it, that terminal effectivley owns
the PLC at that time and it's communication will bump less important
comms if required to satisfy scan time limits. What this implies is
that if you are 'testing' a connection to the PLC for your data
collection purposes while having a programming terminal connected, be
aware that the results are affected by the terminal connection. Also,
commonly on the control network, there will be operator terminals
(HMI's) for the operation of the equipment locally, these gain access
to memory location in the PLC and usually are setup to only look for
change of state to make writes/reads. This ability has been present
across all OEMs and HMI OEM's for a couple of decades at least (and
longer with some). SCADA has been around for a very long time, and
again, the proprietary drivers that used to be the path to connecting
your PLC to your data aquisition system were the ones to choose,
because they worked, just not always as flexibly as you liked. Products
like WonderWare, WinCC, RSView, etc all do this without substantial
overhead increases on the network or for the PLC, although at a premium
based on tag databsae size usually. From my Rockwell Automation Systems
Special days I know that their drivers they employ sit pretty low on
the OSI layer model and they use an ABI as they term it to provide
connectivity for user applications, at least this is how it was done in
the mid 2000's. So OEM driver ---> OEM ABI(API) > User created app.
This is all harware dependant to some degree, but there are processor
status bits you can monitor to determine if there is a change of state
on IO, in some PLC's this is correlated directly to specific IO areas,
but I cannot say this for all of them since my experience only covers
Siemens, Rockwell, Omron, Reliance, Allen-Bradley, Mitsubishi, Modicon,
ABB, and some now extinct types.

So with systems I have encountered and those I was involved in the
design on, I can say that polling was used for non control critical
data manipulation, so production data, logging data, basically nothing
that actually has any direct control fucntion. Anything that needed to
be reactive or active in the control strategy needed to be update on
change of state. Again, modern PLC's have come a long way and now you
can access memory location directly, even in modbus RTU networks. The
big OEM's such as Siemens Modicon and Rockwell use this IO has changed
state capability in their processors for thid purpose. Also, my
understanding of accessing the IO memory locations directly is if you
write a one into an output for instance, the PLC program will still
overwrite the value based on the program state regardless. So to time
stamps, which have been used ad nausium since we have been connecting
to PLC's to get data from the plant floor up to the ERP. Usually, if
the data collection system is the communication master, then they
applied a time stamp to the log activity for that data point. This was
necessary since very few PLC's had an RTC at first, and those that did
were very rarely connected to an NTP server like the data collection
system was. I would suggest, without fully looking at your PLC4X code,
that you make a timestamp function/method that applies the time stamp
outside of the driver, if the PLC has a RTC like most do nowadays, try
to link it to the network NTP server if possible (usually security
implications here) but I would be reluctant to rely on ther PLC's idea
of the time, per se.

Just some thoughts your conversation is provoking in me. Good luck!

Stephen

On Mon, 2021-03-08 at 13:37 +0100, Andreas Vogler wrote:
> Hi, 
> I have not really read all details of your mails …. just my personal
> opinion: for a subscription I would expect that I get every single
> change of value (what the source is able to deliver to me) ...if this
> will potentially flood my client then I have to take care about it…
> and start to think about back pressure strategies … or set a
> subscription interval to bigger than 0 (if possible, like it is with
> OPC UA )and be aware of possible lost value changes… But it is just
> my personal opinion. I mostly work on top of SCADA & event driven…
> and sure, here we are on the edge between polling/plc and event
> driven architectures 

Re: DF1 protocol ...cant find documentation

[Stephen Snow]

gt; > > Betreff: Re: DF1 protocol ...cant find documentation
> > > > > > 
> > > > > > Thanks Chris , Steven
> > > > > > 
> > > > > > I tried the code below but I am getting following error
> > > > > > *error Unable
> > > > > > to find driver for protocol 'df1'*
> > > > > > 
> > > > > > I checked in maven DF1 is added ...what can be the issue ?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > try (PlcConnection plcConnection = new
> > > > > > PlcDriverManager().getConnection("df1:serial:///ttySC1")) {
> > > > > >     PlcReadRequest request =
> > > > > > plcConnection.readRequestBuilder()
> > > > > >     .addItem("ind4", "5:INTEGER")
> > > > > >     .build();
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >   org.apache.plc4x
> > > > > >   plc4x-protocols-df1
> > > > > >   0.8.0
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Fri, Feb 19, 2021 at 6:20 PM Christofer Dutz <
> > > > > > christofer.d...@c-ware.de>
> > > > > > wrote:
> > > > > > 
> > > > > > > Hi Gaurav,
> > > > > > > 
> > > > > > > that's generally just something used during development
> > > > > > > ... It
> > > > > > > wasn't intended to be used as a standalone application.
> > > > > > > If you want to use it to experiment, you have to replace
> > > > > > > the
> > > > > > > connection string (currently "df1:serial:///COM4" with
> > > > > > > something
> > > > > > > for your case and then add/adjust the items added to the
> > > > > > > Read
> > > > Request.
> > > > > > > 
> > > > > > > Chris
> > > > > > > 
> > > > > > > 
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von: Gaurav P 
> > > > > > > Gesendet: Freitag, 19. Februar 2021 13:16
> > > > > > > An: dev@plc4x.apache.org
> > > > > > > Betreff: Re: DF1 protocol ...cant find documentation
> > > > > > > 
> > > > > > > Hi Team /Lucas ...
> > > > > > > Thanks  for comments ...
> > > > > > > 
> > > > > > > Should I use this program to test to PLC 500
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > https://github.com/apache/plc4x/blob/develop/sandbox/test-java-df1-
> > > > > > > dri
> > > > > > > ver/src/test/java/org/apache/plc4x/protocol/df1/EndToEndT
> > > > > > > est.java
> > > > > > > 
> > > > > > > 
> > > > > > > Also how do I specify address ?
> > > > > > > 
> > > > > > >  PlcReadRequest request =
> > > > > > > plcConnection.readRequestBuilder()
> > > > > > > 
> > > > > > >     .addItem("hurz", "5:INTEGER") ->>>>*is
> > > > > > > this address
> > > > > > > of register ???*
> > > > > > > 
> > > > > > >     .build();
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, Feb 19, 2021 at 5:12 PM Gaurav P 
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > Hi Team,
> > > > > > > > 
> > > > > > > > I followed the link which was shared by Lukas and Chris
> > > > > > > > and
> > > > > > > > managed to dish out the guide with sample code , which
> > > > > > > > I would be
> > > > > > > > testing AB PLC 500
> > > > > > > > 
> > > > > > > > *
> > https://docs.google.com/document/d/1FWmwJfXVD03MLtHVsJ0UizoA6D5K
> > > > > > > > zU9
> > > > > > > > JG
> > > > > > > > 4VRD-

Re: AW: DF1 protocol ...cant find documentation

[Stephen Snow]

Hi,
I won't be seeing the customer who has the hardware till a week from
monday coming. I'll ask them to bring it when we meet at his site. He
isn't using it and won't likely ever in the future. I'll let you know
when I have it powered up and connected so we can try some things out.

Stephen

On Fri, 2021-02-19 at 15:27 +0530, Gaurav P wrote:
> yay thanks Steve i have very simple requirement to send and
> receive
> data/register  to PLC 500 over serial ...i don't  have PLC
> background...we
> are IoT startup  :-(... i went through Df1 protocol but its too
> lengthy for
> me
> 
> On Fri, Feb 19, 2021 at 3:21 PM Stephen Snow 
> wrote:
> 
> > Hello,
> > I have been lurking this list off and on for some time. I am a
> > solution
> > provider in Ontario Canada. With respect to the DF1 protocol, and
> > specifically testing it further, I would be more than willing, and
> > able
> > too, to setup a SLC500 say with a 10 slot rack and assorted IO in
> > order
> > to do some testing. I have a solid background in PLC programming,
> > actually systems integration and solution providing that spans many
> > years and industries, and I program in various computer languages
> > too,
> > Java in particular in recent years.
> > So if someone would like to get the DF1 driver tweaked and tested,
> > I
> > can help.
> > 
> > Regards,
> > Stephen
> > 
> > On Fri, 2021-02-19 at 07:36 +, Christofer Dutz wrote:
> > > Hi Gaurav,
> > > 
> > > also from my side, welcome :-)
> > > 
> > > I think the DF1 was one of the first tob e created with the new
> > > code-
> > > generation framework.
> > > However due to lack of hardware to test on, it's still located in
> > > the
> > > "Sandbox" and got a "test" prefix on it.
> > > 
> > >     
> > >     org.apache.plc4x.sandbox
> > >     test-java-df1-driver
> > >     0.9.0-SNAPSHOT
> > >     
> > > 
> > > Also I think it supports all features that were needed by the
> > > folks
> > > that implemented it, but probably not much more than that.
> > > 
> > > So please test it. If you need it to do more and you've got a
> > > device
> > > you can test it with, we'd be happy to help you with that.
> > > 
> > > Chris
> > > 
> > > 
> > > -Ursprüngliche Nachricht-
> > > Von: Lukas Ott 
> > > Gesendet: Freitag, 19. Februar 2021 07:33
> > > An: dev@plc4x.apache.org
> > > Betreff: Re: DF1 protocol ...cant find documentation
> > > 
> > > Hi Gaurav,
> > > 
> > > Welcome to the list :-),
> > > 
> > > Yes it really is supported. Here you ll find some more details:
> > > https://plc4x.apache.org/developers/code-gen/protocol/df1.html
> > > 
> > > The best way to get started you can find here:
> > > https://plc4x.apache.org/users/getting-started/plc4j.html
> > > to understand more read here:
> > > https://plc4x.apache.org/users/getting-started/general-concepts.html
> > > 
> > > For release 0.6 you ll find the java code here:
> > > 
> > https://github.com/apache/plc4x/blob/rel/0.6/protocols/df1/src/main/java/org/apache/plc4x/protocol/df1/Df1Protocol.java
> > > 
> > > 
> > > Example code you ll find here:
> > > https://github.com/apache/plc4x/tree/develop/plc4j/examples
> > > 
> > > Currently not sure if we ported DF1 to release 0.8
> > > 
> > > Cheers,
> > > otluk
> > > 
> > > Am Fr., 19. Feb. 2021 um 03:41 Uhr schrieb Gaurav P
> > > :
> > > 
> > > > Hi Team ,
> > > > I am new to PLC4x , trying to integrate with DF1 but cant find
> > > > any
> > > > documentation 
> > > > https://plc4x.apache.org/users/protocols/df1.html
> > > > 
> > > > is it really supported? if yes where can I get documentation 
> > > > and
> > > > an
> > > > example code
> > > > --
> > > > B*e * the *Ch*ange
> > > > 
> > 
> > 
> > 
> 

Re: DF1 protocol ...cant find documentation

[Stephen Snow]

I can get this tested on both serial and ethernet/ip. I also have ther
DF1 protocol manual.

Stephen
On Fri, 2021-02-19 at 15:22 +0530, Gaurav P wrote:
> Thanks Chris ... I have access to an ancient AB PLC 5/260  and will
> start
> testing and report back to you .transport link would be serial
> ...hope
> it wont be any issue
>  After I go through the docs , hope its not too complex , I maybe
> able to
> maintain and test driver
> 
> On Fri, Feb 19, 2021 at 1:07 PM Christofer Dutz
> 
> wrote:
> 
> > Hi Gaurav,
> > 
> > also from my side, welcome :-)
> > 
> > I think the DF1 was one of the first tob e created with the new
> > code-generation framework.
> > However due to lack of hardware to test on, it's still located in
> > the
> > "Sandbox" and got a "test" prefix on it.
> > 
> >     
> >     org.apache.plc4x.sandbox
> >     test-java-df1-driver
> >     0.9.0-SNAPSHOT
> >     
> > 
> > Also I think it supports all features that were needed by the folks
> > that
> > implemented it, but probably not much more than that.
> > 
> > So please test it. If you need it to do more and you've got a
> > device you
> > can test it with, we'd be happy to help you with that.
> > 
> > Chris
> > 
> > 
> > -Ursprüngliche Nachricht-
> > Von: Lukas Ott 
> > Gesendet: Freitag, 19. Februar 2021 07:33
> > An: dev@plc4x.apache.org
> > Betreff: Re: DF1 protocol ...cant find documentation
> > 
> > Hi Gaurav,
> > 
> > Welcome to the list :-),
> > 
> > Yes it really is supported. Here you ll find some more details:
> > https://plc4x.apache.org/developers/code-gen/protocol/df1.html
> > 
> > The best way to get started you can find here:
> > https://plc4x.apache.org/users/getting-started/plc4j.html
> > to understand more read here:
> > https://plc4x.apache.org/users/getting-started/general-concepts.html
> > 
> > For release 0.6 you ll find the java code here:
> > 
> > https://github.com/apache/plc4x/blob/rel/0.6/protocols/df1/src/main/java/org/apache/plc4x/protocol/df1/Df1Protocol.java
> > 
> > 
> > Example code you ll find here:
> > https://github.com/apache/plc4x/tree/develop/plc4j/examples
> > 
> > Currently not sure if we ported DF1 to release 0.8
> > 
> > Cheers,
> > otluk
> > 
> > Am Fr., 19. Feb. 2021 um 03:41 Uhr schrieb Gaurav P :
> > 
> > > Hi Team ,
> > > I am new to PLC4x , trying to integrate with DF1 but cant find
> > > any
> > > documentation 
> > > https://plc4x.apache.org/users/protocols/df1.html
> > > 
> > > is it really supported? if yes where can I get documentation  and
> > > an
> > > example code
> > > --
> > > B*e * the *Ch*ange
> > > 
> > 
> 
> 

Re: AW: DF1 protocol ...cant find documentation

[Stephen Snow]

Hello,
I have been lurking this list off and on for some time. I am a solution
provider in Ontario Canada. With respect to the DF1 protocol, and
specifically testing it further, I would be more than willing, and able
too, to setup a SLC500 say with a 10 slot rack and assorted IO in order
to do some testing. I have a solid background in PLC programming,
actually systems integration and solution providing that spans many
years and industries, and I program in various computer languages too,
Java in particular in recent years.
So if someone would like to get the DF1 driver tweaked and tested, I
can help.

Regards,
Stephen
On Fri, 2021-02-19 at 07:36 +, Christofer Dutz wrote:
> Hi Gaurav,
> 
> also from my side, welcome :-)
> 
> I think the DF1 was one of the first tob e created with the new code-
> generation framework. 
> However due to lack of hardware to test on, it's still located in the
> "Sandbox" and got a "test" prefix on it.
> 
>     
>     org.apache.plc4x.sandbox
>     test-java-df1-driver
>     0.9.0-SNAPSHOT
>     
> 
> Also I think it supports all features that were needed by the folks
> that implemented it, but probably not much more than that. 
> 
> So please test it. If you need it to do more and you've got a device
> you can test it with, we'd be happy to help you with that.
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Lukas Ott  
> Gesendet: Freitag, 19. Februar 2021 07:33
> An: dev@plc4x.apache.org
> Betreff: Re: DF1 protocol ...cant find documentation
> 
> Hi Gaurav,
> 
> Welcome to the list :-),
> 
> Yes it really is supported. Here you ll find some more details:
> https://plc4x.apache.org/developers/code-gen/protocol/df1.html
> 
> The best way to get started you can find here:
> https://plc4x.apache.org/users/getting-started/plc4j.html
> to understand more read here:
> https://plc4x.apache.org/users/getting-started/general-concepts.html
> 
> For release 0.6 you ll find the java code here:
> https://github.com/apache/plc4x/blob/rel/0.6/protocols/df1/src/main/java/org/apache/plc4x/protocol/df1/Df1Protocol.java
> 
> 
> Example code you ll find here:
> https://github.com/apache/plc4x/tree/develop/plc4j/examples
> 
> Currently not sure if we ported DF1 to release 0.8
> 
> Cheers,
> otluk
> 
> Am Fr., 19. Feb. 2021 um 03:41 Uhr schrieb Gaurav P :
> 
> > Hi Team ,
> > I am new to PLC4x , trying to integrate with DF1 but cant find any 
> > documentation 
> > https://plc4x.apache.org/users/protocols/df1.html
> > 
> > is it really supported? if yes where can I get documentation  and
> > an 
> > example code
> > --
> > B*e * the *Ch*ange
> > 

RE: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)

[Stephen Snow]

Patrick,
Since you are trying to communicate with the PLC from two different PC 
apps on the same network, you will invariably have errors such as you 
experienced. This is largely due to the deterministic requirements of 
the PLC and the limited timeframe allotted for such communication. Also 
worth noting is the precendence of which comes first, and this comes 
forward even more when you have a programming (ie PLC programming 
software) terminal connected since the proprietary PLC programming 
software often takes ownership of the connection and will bump other 
connections as it suits. It was one of the reasons most brands have 
multiple communication ports available to use.


Regards,
Stephen

On Thu, Dec 17, 2020 at 17:59, Patrick Boisclair 
 wrote:

Sorry I was actually not clear.

Im running the PLC4X program from IntelliJ .


When I upload the TwinCAT program into the beckhoff PLC and it runs 
from itself, it works.


When I have Visual Studio with the TwinCAT program running from my PC 
(Connected through TwinCAT developer mode), the PLC4X programs hangs 
(still running it from IntelliJ).



It just its cool to see the TwinCAT variables "live" fron 
VisualStudio while developping the PLC4X program that connects to it.



Does it make sense ?





Patrick Boisclair
Analyste - Programmeur senior / Senior Analyst Programmer

 


462, rue des Forges, Trois-Rivières (Québec) G9A 2H5 CANADA
noovelia.com 


*De :* Christofer Dutz 
*Envoyé :* 17 décembre 2020 12:28
*À :* dev@plc4x.apache.org
*Objet :* AW: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)

Hi Patrick,

 so was the problem actually a VisualStudio problem or something we 
can improve?


 If you say: „PLC program only in the PLC itself“ … you’re 
not running the PLC4X program on a PLC? So you mean if you run the 
program from the commandline, it works and in VS it hangs?



 Chris


 Von: Patrick Boisclair 
 Gesendet: Donnerstag, 17. Dezember 2020 17:23
 An: dev@plc4x.apache.org
 Betreff: RE: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)


 Ok I found out what the problem is.



 For a reason when the PLC program is running from Visual Studio 
(TwinCAT), for a reason with PLC4X it sometimes hangs.


 If I shut down Visual Studio and run the PLC program only in the PLC 
itself.. works fine.







 Patrick Boisclair
 Analyste - Programmeur senior / Senior Analyst Programmer

 [cid:image37a0ee.PNG@c424a83b.43945ee2]


 462, rue des Forges, Trois-Rivières (Québec) G9A 2H5 CANADA
 noovelia.com>

 [cid:image138bb4.PNG@cf1129fc.4582dcdc]
 
 De : Patrick Boisclair 
mailto:pboiscl...@noovelia.com>>

 Envoyé : 17 décembre 2020 09:59
 À : dev@plc4x.apache.org
 Objet : RE: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)


 Hi Chris,



 I'll try to see what I can find with wireshark and send the info on 
the Jira issue.





 Patrick Boisclair
 Analyste - Programmeur senior / Senior Analyst Programmer

 [cid:image4523eb.PNG@2f3aa02d.45a60828]


 462, rue des Forges, Trois-Rivières (Québec) G9A 2H5 CANADA
 noovelia.com>

 [cid:image18b9f2.PNG@d05602cd.489d2dd3]
 
 De : Christofer Dutz 
mailto:christofer.d...@c-ware.de>>

 Envoyé : 17 décembre 2020 09:45
 À : dev@plc4x.apache.org
 Objet : AW: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)

 Hi Patrick,

 welcome to our list.

 There is one big difference (if you are calling the code you posted 
in a loop):
 Internally the driver automatically does the translation from a 
symbolic address to a handle and to use that handle to read and to 
give back the handle when closing the connection.


 Perhaps if you run your loop just around this part:

 request.execute().whenComplete((response, exception) -> {

 Integer x = response.getInteger("value-1");

 System.out.println("READ DONE: " + 
x.toString());


 });


 Then it would be a similar scenario.

 If this isn’t solving the problem, could you possibly do a 
WireShark recording oft hat communication and attach that to a Jira 
issue on: https://issues.apache.org/jira/projects/PLC4X/ 

 This would be the best way to help us find and possibly resolve the 
issue.



 Hope that helps,

  Chris


 Von: Patrick Boisclair 
mailto:pboiscl...@noovelia.com>>

 Gesendet: Donnerstag, 17. Dezember 2020 15:34
 An: dev@plc4x.apache.org
 Betreff: Beckhoff with ADS protocol (0.0.8-SNAPSHOT)


 Hello everyone,



 Im' able to connect to my beckhoff PLC, read a value, but sometimes 
the read just "hang". The code below works like half the time.


 Some time, I run the program, it reads the value, sometimes it just 

Re: [DISCUSS] How about changing the way we act on "backward compatability"?

[Stephen Snow]

Hello,
My name is Stephen Snow, and I am a Solution Provider of Industrial 
Automation for some customers I have. I am curently starting a project 
that I am hoping to sell to my customers in various forms, that will 
likely use the PLC4X API. I am comfortable, FWIW, with new major rev's 
breaking something of the legacy API to progress the project in order 
to bring enhancement to the capabilities. Having said this, what about 
taking the approach that JDK did when transitioning through Ver 8 to 
13, fork the legacy source. Work on the new API with intent to 
achieving Ver 1.0.0 while only maintaining the legacy at Ver 0.8.0 and 
only minor rev's until your ready to switch. And wherever possible 
provide good directions on converting to the new and improved API? Then 
when you're confident you have the new approach hammered out 
sufficiently to support a change to it, then make the change. Goal 
oriented change management is a must I think.

Just my 2c worth.

Best regards,
Stephen


On Fri, Nov 20, 2020 at 06:32, Otto Fowler  
wrote:
 or, we can follow versioning rules and have the ‘new kafka sink’ 
trigger a

proper release that allows breaking backwards compatibility

From: Christofer Dutz <mailto:christofer.d...@c-ware.de>>

mailto:christofer.d...@c-ware.de>>
Reply: dev@plc4x.apache.org <mailto:dev@plc4x.apache.org> 
mailto:dev@plc4x.apache.org>> 
mailto:dev@plc4x.apache.org>>

Date: November 20, 2020 at 06:08:51
To: dev@plc4x.apache.org <mailto:dev@plc4x.apache.org> 
mailto:dev@plc4x.apache.org>> 
mailto:dev@plc4x.apache.org>>

Subject:  [DISCUSS] How about changing the way we act on "backward
compatability"?

Hi all,

in a discussion with Ben on the Kafka Connect adapter. He was trying 
to
stay compatible with the past in order to not break anything with 
existing
installations. As of know I don’t know of a single usage of it 
anywhere.


The thing is: we developed a lot of stuff and as of now we don’t 
really
know who is actually using what. And in the past I have seen multiple 
times
that stuff I was thought to be used, actually couldn’t have and I 
was
wasting my energy in keeping things compatible while it would have 
been

better to change them.

So how about we call out loud on all channels that we promise to pay
attention to parts we know are being used. And the only way we can 
know

about this, is if the companies actually tell us.

I’d even call it out as “We are working hard on reaching the 
version 1.0.0

and for this we might want to clean up and change a few things”.

This way we can assure we evolve the different parts as freely as 
possible.
If someone complains that we broke something they were using, we’ve 
got an
excuse and perhaps we’ll get more official statements about usage 
this way?


What do you think?

Chris