Re: Dummy Driver
Hi Julian. There is a "test"-driver associated with the "test:" protocol code. The implementation is in https://github.com/apache/incubator-plc4x/tree/master/plc4j/protocols/test. I wrote the initial version to simplify testing the kafka connector, and Christofer improved the code later. The driver simulates a "dummy" device in the same client JVM process (no network connections will be created). Just use "test:something" as the connection URL. If you want to "read" a random integer, just use the query "RANDOM/foo:INTEGER" on that connection. Andrey On 10/06/2018 09:21 PM, Julian Feinauer wrote: Hey, just had another thought. I remember chris writing about a mysterious Dummy Driver (I think he said it was implemented by Andrey, but I’m not sure). Do we have some kind of documentation about it as it would really make (some testing) a lot more easy? Thanks already! Julian
Dummy Driver
Hey, just had another thought. I remember chris writing about a mysterious Dummy Driver (I think he said it was implemented by Andrey, but I’m not sure). Do we have some kind of documentation about it as it would really make (some testing) a lot more easy? Thanks already! Julian
Re: Usage of Optional for Reader / Writer
Hey Andrey, I have to admit that your naming is definetly better than mine. And I like your idea about this Metadata thing a lot. I just checked how this is named in JDBC and the respective class is https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html So I think we can provide a canRead / canWrite (canSubscribe is a bit difficult, as we already hat several discussions about if we implement that by polling by default). But I would also like the idea of having such a Metadata interface to transport further information about the PLC (like if this is native subscribing or polling and all such stuff). Best Julian Am 06.10.18, 21:08 schrieb "Andrey Skorikov" : Hello Julian, I think that a canRead()/canWrite()/canSubscribe() methods signaling whether the connection supports reading/writing/subscription is a really good solution. This would cleanly separate querying the meta-information of a connection (whether the connection provides the required capability) from actually using it, and would free the client from dealing with the Optionals all the time. There are also some alternative solutions: - Provide the meta-information in a separate data structure, returned by some operation like getCapabilites() on PlcConnection. This can be modeled in great detail or very simply (for example by returning a BitSet). The client would check whether the required operation is supported by calling operations on that object. - Provide "mix-in" interfaces, for example Readable and Writable. The client would check whether the connection supports reading by evaluating whether the connection object implements the required interface (for example: connection instanceof Readable) and casting the connection to that type. - Provide no meta-information at all and just throw an exception when a unsupported operation is invoked. Would not recommend that, but still :-) In total, I think that Julian's solution (canRead() with Exception thrown when a unsupported operation is invoked) balances the complexity and flexibility best. Andrey On 10/06/2018 08:38 PM, Julian Feinauer wrote: > Hey everybody, > > I’m currently groing through Andreys PR (https://github.com/apache/incubator-plc4x/pull/27) which introduces some very good API changes and makes the API a lot more concise. > But one thing that annoys me from the first day on plc4x is still there (and is now even more annoying as the rest is so clean). It is the boilerplate code I have write all the time when “just doing a connection to read something” due to the Optional for getting the reader (or now the ReadRequestBuilder). > For me, the getReader (or now readRequestBuilder) as Optional is like what Sebastian hates about Checked Exceptions. > I never had to deal with a Connection which did not have a Reader but I had to check the Optional… at least 50 times, perhaps even more. > > Can’t we come up with a solution for that which would make the API (from my perspective) even more clean and user friendly. > > Suggestions could be: > >1. Replace the connection directly with Reader, so no getConnection but getReader (or readRequestBuilder). And if this fails, it throws a PlcConnectionException, as usual. >2. No optional but another or canRead() method (for those who like it save) and it then throws a unchecked PlcConnectionException (or some subclass) > > What do the others think? Is this only me having the feeling that this is the same anti-pattern as with the checked exceptions? > > Julian
Re: Usage of Optional for Reader / Writer
Hello Julian, I think that a canRead()/canWrite()/canSubscribe() methods signaling whether the connection supports reading/writing/subscription is a really good solution. This would cleanly separate querying the meta-information of a connection (whether the connection provides the required capability) from actually using it, and would free the client from dealing with the Optionals all the time. There are also some alternative solutions: - Provide the meta-information in a separate data structure, returned by some operation like getCapabilites() on PlcConnection. This can be modeled in great detail or very simply (for example by returning a BitSet). The client would check whether the required operation is supported by calling operations on that object. - Provide "mix-in" interfaces, for example Readable and Writable. The client would check whether the connection supports reading by evaluating whether the connection object implements the required interface (for example: connection instanceof Readable) and casting the connection to that type. - Provide no meta-information at all and just throw an exception when a unsupported operation is invoked. Would not recommend that, but still :-) In total, I think that Julian's solution (canRead() with Exception thrown when a unsupported operation is invoked) balances the complexity and flexibility best. Andrey On 10/06/2018 08:38 PM, Julian Feinauer wrote: Hey everybody, I’m currently groing through Andreys PR (https://github.com/apache/incubator-plc4x/pull/27) which introduces some very good API changes and makes the API a lot more concise. But one thing that annoys me from the first day on plc4x is still there (and is now even more annoying as the rest is so clean). It is the boilerplate code I have write all the time when “just doing a connection to read something” due to the Optional for getting the reader (or now the ReadRequestBuilder). For me, the getReader (or now readRequestBuilder) as Optional is like what Sebastian hates about Checked Exceptions. I never had to deal with a Connection which did not have a Reader but I had to check the Optional… at least 50 times, perhaps even more. Can’t we come up with a solution for that which would make the API (from my perspective) even more clean and user friendly. Suggestions could be: 1. Replace the connection directly with Reader, so no getConnection but getReader (or readRequestBuilder). And if this fails, it throws a PlcConnectionException, as usual. 2. No optional but another or canRead() method (for those who like it save) and it then throws a unchecked PlcConnectionException (or some subclass) What do the others think? Is this only me having the feeling that this is the same anti-pattern as with the checked exceptions? Julian
Usage of Optional for Reader / Writer
Hey everybody, I’m currently groing through Andreys PR (https://github.com/apache/incubator-plc4x/pull/27) which introduces some very good API changes and makes the API a lot more concise. But one thing that annoys me from the first day on plc4x is still there (and is now even more annoying as the rest is so clean). It is the boilerplate code I have write all the time when “just doing a connection to read something” due to the Optional for getting the reader (or now the ReadRequestBuilder). For me, the getReader (or now readRequestBuilder) as Optional is like what Sebastian hates about Checked Exceptions. I never had to deal with a Connection which did not have a Reader but I had to check the Optional… at least 50 times, perhaps even more. Can’t we come up with a solution for that which would make the API (from my perspective) even more clean and user friendly. Suggestions could be: 1. Replace the connection directly with Reader, so no getConnection but getReader (or readRequestBuilder). And if this fails, it throws a PlcConnectionException, as usual. 2. No optional but another or canRead() method (for those who like it save) and it then throws a unchecked PlcConnectionException (or some subclass) What do the others think? Is this only me having the feeling that this is the same anti-pattern as with the checked exceptions? Julian
[GitHub] JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item
JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427596324 PR is closed an I opened a JIRA (https://issues.apache.org/jira/projects/PLC4X/issues/PLC4X-63?filter=allopenissues) for adding endianess to the connection string. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] JulianFeinauer closed pull request #28: Type conversions for default byte array fiel item
JulianFeinauer closed pull request #28: Type conversions for default byte array
fiel item
URL: https://github.com/apache/incubator-plc4x/pull/28
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/DefaultByteArrayFieldItem.java
b/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/DefaultByteArrayFieldItem.java
index 4663e4689..078422dd9 100644
---
a/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/DefaultByteArrayFieldItem.java
+++
b/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/DefaultByteArrayFieldItem.java
@@ -29,14 +29,20 @@ public Object getObject(int index) {
return getValue(index);
}
+@Override
public boolean isValidByteArray(int index) {
Byte[] value = getValue(index);
return value != null;
}
+@Override
public Byte[] getByteArray(int index) {
return getValue(index);
}
+//ToDo: extend conversion methods similar to @see {@link
org.apache.plc4x.java.modbus.messages.items.DefaultModbusByteArrayFieldItem}
+
+//ToDo: implement endianness for correct handling of Byte Arrays at
conversion
+
}
diff --git
a/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/FieldItem.java
b/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/FieldItem.java
index 2a4acca15..7df46a93a 100644
---
a/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/FieldItem.java
+++
b/plc4j/protocols/driver-bases/base/src/main/java/org/apache/plc4x/java/base/messages/items/FieldItem.java
@@ -185,4 +185,6 @@ public String toString() {
"values=" + Arrays.toString(values) +
'}';
}
+
+//ToDo Replace returning of null by Exceptions
}
diff --git
a/plc4j/protocols/modbus/src/main/java/org/apache/plc4x/java/modbus/messages/items/DefaultModbusByteArrayFieldItem.java
b/plc4j/protocols/modbus/src/main/java/org/apache/plc4x/java/modbus/messages/items/DefaultModbusByteArrayFieldItem.java
new file mode 100644
index 0..963a493bd
--- /dev/null
+++
b/plc4j/protocols/modbus/src/main/java/org/apache/plc4x/java/modbus/messages/items/DefaultModbusByteArrayFieldItem.java
@@ -0,0 +1,241 @@
+/*
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+*/
+package org.apache.plc4x.java.modbus.messages.items;
+
+import org.apache.commons.lang3.ArrayUtils;
+import org.apache.plc4x.java.base.messages.items.DefaultByteArrayFieldItem;
+
+import java.nio.ByteBuffer;
+import java.nio.ByteOrder;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
+
+/**
+ * default implementation for DefaultByteArrayFieldItem for Usage within
Modbus module
+ * default ByteOrder is set to BIG_ENDIAN, can be selected on regarding
get-method explicitly from user if needed
+ */
+public class DefaultModbusByteArrayFieldItem extends DefaultByteArrayFieldItem
{
+
+private static final int SHORT_BYTES = 2;
+private static final int INTEGER_BYTES = 4;
+private static final int LONG_BYTES = 8;
+private static final ByteOrder DEFAULT_ENDIANNESS = ByteOrder.BIG_ENDIAN;
+
+private ByteOrder byteOrder;
+
+private Byte[] completeByteArray;
+
+public DefaultModbusByteArrayFieldItem(Byte[]... values) {
+super(values);
+this.byteOrder = DEFAULT_ENDIANNESS;
+this.completeByteArray = getCompleteByteArray();
+}
+
+@Override
+public Object getObject(int index) {
+return getValue(index);
+}
+
+@Override
+public boolean isValidByteArray(int index) {
+Byte[] value = getValue(index);
+return value != null;
+}
+
+@Override
+public Byte[] getByteArray(int index) {
+return getValue(index);
+}
+
+@Override
+public boolean isValidShort(int index) {
+
[GitHub] chrisdutz commented on issue #28: Type conversions for default byte array fiel item
chrisdutz commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427575262 An I should have read through the entire thread here first ;-) ... So I am on the same page as Julian. We should set the endianess on a connection level. I haven't come across any PLC where the types differed. Regarding the connection string ... I would make it mandatory: modbus://10.10.40.10:234/LE or modbus://10.10.40.10:234/BE ... it is an important detail similar like "Rack" and "Slot" for S7. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] chrisdutz commented on issue #28: Type conversions for default byte array fiel item
chrisdutz commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427574960 Regarding the endianess of data ... I guess every PLC is either Little Endian or Big Endian. How about providing this detail as part of the connection string? I think the Client code shouldn't depend on the endianess of the PLC. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] timbo2k commented on issue #28: Type conversions for default byte array fiel item
timbo2k commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427574529 PR has been updated ... explicit Modbus-Implementation for ByteArrayFieldItem makes sense Code change has been successfully tested vs an industrial Modbus device This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] timbo2k commented on issue #28: Type conversions for default byte array fiel item
timbo2k commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427569262 @JulianFeinauer @sruehl that sounds like a good idea ... I didn't thought about endianess but u'r totally right. I'll change those stuff and update PR This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] sruehl commented on issue #28: Type conversions for default byte array fiel item
sruehl commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427567205 good Idea (this could extend from the DefaultByteArrayItem), and at best add a TODO and JIRA-ISSUE id to the BIG_ENDIAN call in the field item :) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item
JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427565843 So @timbo2k , @sruehl what about the suggestion: We copy the DefaultByte... (as commited by Tim) in the Modbus module and name is something like DefaultModbusItem. Parallel we do a Improvement Ticket to add a syntax somewhere to speciy Little Endianess (and Big is the default). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: Request for Registration: PLC4X goes Mallorca meetup (Nov. 2018) ...
Hi Chris, as stated, Tim and I are definitely in! Best Julian Am 04.10.18, 15:28 schrieb "Christofer Dutz" : Hi all, well as it seems we will be doing our second PLC4X Meetup at the end of November (22.11.2018 – 25.11.2018) I would need some feedback on who’s planning on coming with how many people. As mentioned before, the accommodation will be at the codecentric Finca and will be free of charge for all attendees. I will probably also hire a van or something like that to get around. Flights (definitely) and Food/Drinks (probably) will be everyone on his own. So please respond to this thread as soon as possible to allow a little planning on our side. Chris
[GitHub] sruehl commented on issue #28: Type conversions for default byte array fiel item
sruehl commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427565497 @JulianFeinauer pretty sure there are some out there Im fine with both suggestions. :) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item
JulianFeinauer commented on issue #28: Type conversions for default byte array
fiel item
URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427565323
@sruehl so in theory could someone crazy enough decide to have different
memory areas in its plc in different endianess??? Well... I'm not sure if I
want to support communication with those people :)
But back to topic, I would suggest to do it in the connection or in the
request query (similar to what we do in S7 like "/0/0:LE" and have a default
like BE then we are flexible enough.
What I want to avoid (and I'm pretty sure @chrisdutz is with me in this
regard is to have the users think about this stuff like do a
`if (x.isBE) {
return x.getLongBE()
}`
This looks horrible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item
JulianFeinauer commented on issue #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28#issuecomment-427563770 @sruehl Hey seb, you mean the Ednainess could change? Or is undefined? Then I would suggest to add a connection parameter (as discussed some times) like modbus://...?endianess=big or bigEndian=true wiht a sensible default. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] timbo2k opened a new pull request #28: Type conversions for default byte array fiel item
timbo2k opened a new pull request #28: Type conversions for default byte array fiel item URL: https://github.com/apache/incubator-plc4x/pull/28 implemented conversion methods for * getShort * getInteger * getLong as fix for PLC4X-62 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[ANNOUNCE] Apache PLC4X (incubating) 0.1.0 released
The Apache PLC4X (Incubating) team is pleased to announce the release of Apache PLC4X (incubating) 0.1.0 This is the first official release of PLC4X. PLC4X is a set of libraries for communicating with industrial programmable logic controllers (PLCs) using a variety of protocols but with a shared API. The current release contains drivers able to communicate with industrial PLCs using one of the following protocols: * Siemens S7 (0x32) * Beckhoff ADS * Modbus * EtherNet/IP Beyond that we also provide integration modules for the following Apache projects and frameworks: * Apache Edgent (Incubating) * Apache Camel * Apache Kafka (Kafka Connect) Visit the Apache PLC4X website [1] for general information or the downloads page [2] for release notes and download information. Regards, The Apache PLC4X team [1] http://plc4x.apache.org [2] http://plc4x.apache.org/users/download.html = *Disclaimer* Apache Edgent is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the name of Apache Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
