Re: [DISCUSS] Having a in-person community meetup?
Ah... if there is TAC support, I will forward this message to IoTDB community to see if there are committers want to join for the Historian development face to face. --- Xiangdong Huang School of Software, Tsinghua University Christofer Dutz 于2023年1月5日周四 18:59写道： > > Hi Jinlin, > > Would you be willing and able to attend such an event? > You would be more than welcome. > > As I’m also part of the Apache Travel Assistance committee … I’d also like to > ask any others here too: > Would you like to attend such an event, but the costs of travelling are what > you can’t afford or would have a too big impact on your budget to be willing > to come? > > Because there theoretically is the option of having Apache cover the costs > for travelling and accommodation. However, this would put quite a lot of > extra work for us for setting it up and running it. > So, if it’s only 1-2 people, this probably doesn’t make much sense, but if > there were more, it might make sense. > > And please … don’t say: “I can’t afford it and would like assistance”, if the > problem is that the fuel has become too expensive for your Ferrari or the > parking costs for your private jet are skyrocketing ;-) > > And if you don’t want to publicly answer … feel free to DM me. > > Chris > > > From: jl hong > Date: Thursday, 5. January 2023 at 02:16 > To: dev@plc4x.apache.org > Subject: Re: [DISCUSS] Having a in-person community meetup? > This sounds exciting :) > > Jinlin > > Lukas Ott 於 2023年1月5日 週四 上午12:11寫道： > > > cool :-) would be fun so that I can finally ask all my questions in person > > ;-) > > > > Am Mi., 4. Jan. 2023 um 16:37 Uhr schrieb Ben Hutcheson < > > ben.hut...@gmail.com>: > > > > > Sounds like fun. > > > > > > Ben > > > > > > On Wed, Jan 4, 2023 at 4:30 PM Christofer Dutz < > > christofer.d...@c-ware.de> > > > wrote: > > > > > > > Ok … > > > > > > > > Uwe from codecentric FFM (the new office) was delighted my me asking if > > > > codecentric would be willing to accommodate us during the hackathon. > > > > So, that would be one option … I guess Sebastian would like that option > > > ;-) > > > > > > > > Chris > > > > > > > > > > > > From: Christofer Dutz > > > > Date: Wednesday, 4. January 2023 at 16:24 > > > > To: dev@plc4x.apache.org > > > > Subject: [DISCUSS] Having a in-person community meetup? > > > > Hi all, > > > > > > > > some of you remember the times around our graduation. We had loads of > > > > in-presence meetups and that really fuled the drive in the community. > > > > Covid sort of was the opposite and it felt like we were sort of losing > > > our > > > > drive a bit. > > > > > > > > Now that Ben now also lives in Germany, I wanted to bring up this topic > > > > again. > > > > > > > > What do you folks think of a 2-3-day hackathon on PLC4X (and possibly > > the > > > > Historian)? > > > > Probably we would need to sort of do it Friday to Sunday. > > > > > > > > Also currently probing if we could not get TAC to help finance the > > > travels > > > > of everyone except me. > > > > > > > > Even if I would love a week on the Bahamas, probably something in > > Germany > > > > somewhere round Frankfurt or Stuttgart would make sense > > > > (from the perspective of people being able to come there via public > > > > transport and keeping the connection options simple and cheaper) > > > > > > > > What do you folks think. > > > > > > > > > > > > Chris > > > > > > > > >
[GitHub] [plc4x] dependabot[bot] opened a new pull request, #734: build(deps): bump gson from 2.10 to 2.10.1
dependabot[bot] opened a new pull request, #734: URL: https://github.com/apache/plc4x/pull/734 Bumps [gson](https://github.com/google/gson) from 2.10 to 2.10.1. Release notes Sourced from https://github.com/google/gson/releases";>gson's releases. Gson 2.10.1 This is technically a minor release rather than a patch release because there is one small API change: a new JsonObject.isEmpty() method. What's Changed: User-Visible Changes Added JsonObject method isEmpty() by https://github.com/dhoard";>@dhoard in https://github-redirect.dependabot.com/google/gson/pull/2233";>google/gson#2233 Fix non-threadsafe creation of adapter for type with cyclic dependency by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/1832";>google/gson#1832 Remove EOFException special casing of JsonStreamParser.next() by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2281";>google/gson#2281 Improve exception message for duplicate field names by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2251";>google/gson#2251 Fix the javadoc of JsonDeserializer.deserialize() by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/gson/pull/2243";>google/gson#2243 Bump os-maven-plugin from 1.7.0 to 1.7.1 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2235";>google/gson#2235 Bump jackson-databind from 2.13.4.2 to 2.14.0 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2234";>google/gson#2234 Bump maven-release-plugin from 3.0.0-M6 to 3.0.0-M7 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2232";>google/gson#2232 Bump japicmp-maven-plugin from 0.16.0 to 0.17.1 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2238";>google/gson#2238 Bump jackson-databind from 2.14.0 to 2.14.1 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2241";>google/gson#2241 Bump bnd-maven-plugin from 6.3.1 to 6.4.0 by https://github.com/dependabot";>@dependabot in https://github-redirect.dependabot.com/google/gson/pull/2245";>google/gson#2245 Site Documentation and Maintenance Changes (these were already visible) Add troubleshooting guide by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2285";>google/gson#2285 Replace custom user guide header anchors by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2289";>google/gson#2289 Improve variable names in user guide by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2290";>google/gson#2290 Add 2.10 changes to CHANGELOG; minor release follow-ups by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2229";>google/gson#2229 Mention in CHANGELOG that GitHub Releases are used in the future by https://github.com/Marcono1234";>@Marcono1234 in https://github-redirect.dependabot.com/google/gson/pull/2230";>google/gson#2230 GitHub Workflows security hardening by https://github.com/sashashura";>@sashashura in https://github-redirect.dependabot.com/google/gson/pull/2274";>google/gson#2274 Other Changes Making consistent prefixs in PerformanceTest by https://github.com/CirQ";>@CirQ in https://github-redirect.dependabot.com/google/gson/pull/1760";>google/gson#1760 Adjust version numbers and a test to conform to the SemVer spec. by https://github.com/eamonnmcmanus";>@eamonnmcmanus in https://github-redirect.dependabot.com/google/gson/pull/2237";>google/gson#2237 Remove covered condition in JsonNull.equals() by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/gson/pull/2271";>google/gson#2271 Remove the final keyword from private method by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/gson/pull/2276";>google/gson#2276 Code cleanup by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/gson/pull/2282";>google/gson#2282 Unnecessary unboxing at JsonPrimitive.getAsBoolean() by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/gson/pull/2277";>google/gson#2277 Rewrite the testParsingDatesFormattedWithSystemLocale(), Fix https://github-redirect.dependabot.com/google/gson/issues/2199";>#2199 by https://github.com/MaicolAntali";>@MaicolAntali in https://github-redirect.dependabot.com/google/g
[GitHub] [plc4x] dependabot[bot] opened a new pull request, #733: build(deps): bump assertj-core from 3.24.0 to 3.24.1
dependabot[bot] opened a new pull request, #733: URL: https://github.com/apache/plc4x/pull/733 Bumps assertj-core from 3.24.0 to 3.24.1. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [plc4x] hongjinlin commented on pull request #545: feat(plc4go): Implementing the correct reading of BOOL types
hongjinlin commented on PR #545: URL: https://github.com/apache/plc4x/pull/545#issuecomment-1375071236 > In general, the changes look good, however you manually seem to have edited generated code, so the changes will get lost the next time the maven build is executed. Hi Chris, Thank you very much for reviewing the code. I have a revert commit(https://github.com/apache/plc4x/commit/8a793e26d8b24060ee657d7ca9e6114d89c724a1) of this commit(https://github.com/apache/plc4x/commit/17d7f765c670f86c3fd110f010a3faafe8ee1c5a) after Ben remind me that the Golang build failed after my push, sorry for that. The reason the Golang build failed is just what you said I edited generated file directly. But don’t worry I will be familiar with the code generation and have a PR for that as soon as possible. Jinlin -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Modbus addresses offset by 1?
Hi Niels, I know there was a reason why the offset didn't get applied to the extended registers, however I can no longer find out why I thought that it shouldn't have applied. I would be in favor of adding the offset to the extended register to make them the same as the others. Ben On Sun, Jan 8, 2023 at 11:07 PM Łukasz Dywicki wrote: > Based on my own experience with modbus devices - you might also face > situation where manufacturer starts addressing with own offset by not > following official guidance. A fairly common practice I observed is use > of addresses ie. 0, 1, 4 for coil/input/holding which are > being called "entity numbers". [1] > Out of tens of modbus devices I interfaced with I had a matching > combination of manufacturer docs, library approach and actual device > addresses once or twice. Speaking here about heat pumps, inverters, > electric meters and PLCs, all are subject of same trouble. > > Maybe implementing whole driver is not needed as you can try to use > optimizer which lives between your program code and driver and can > re-arrange fields/tags before they reach device? > > Best, > Łukasz > > [1] https://en.wikipedia.org/wiki/Modbus#Entity_numbers_and_addresses > > On 8.01.2023 12:27, Niels Basjes wrote: > > Hi, > > > > Understood. Keep the offset it is. > > But why does the ModbusTagExtendedRegister not have this shift? Is that a > > bug? > > > > Also there are a few other problems I found in this area, one is that the > > getAddressString will yield a different address (which is also > unparsable). > > I'll see if I can fix those. > > > > Niels > > > > On Sat, Jan 7, 2023 at 8:35 PM Christofer Dutz < > christofer.d...@c-ware.de> > > wrote: > > > >> Hi all, > >> > >> yeah … just wanted to say … this stupid offset is by spec that way. > >> I would say, that in this case we have two different specs with a common > >> base. > >> Perhaps if we had “variants” of drivers, we could make different > >> assumptions. > >> > >> If you get a Modbus TCP connection things are the way, they currently > are. > >> If you get a Modbus TCP connection with “SunSpec” variant, then you > don’t > >> have the offsets. > >> > >> Cause … if we undid the “+1” shift, then other would start complaining > >> because their specked registers are in different locations. > >> > >> I have also heard that for EIP for full support of the PLC features, > we’ll > >> have to have Allen Bradley, Schneider Electric variants next to the > default > >> ones. > >> I was told most of the major vendors do all the complex types and > browsing > >> differently :-( > >> > >> Chris > >> > >> From: Niels Basjes > >> Date: Saturday, 7. January 2023 at 18:31 > >> To: dev@plc4x.apache.org > >> Subject: Re: Modbus addresses offset by 1? > >> Ok, the "off by one" problem is ancient. > >> Looking around the internet I read that in the past when register 123 > was > >> needed you would have to request for 122 over modbus. > >> > >> I find the transition from the logical number to the technical number a > >> responsibility of the application, not of this library. > >> Take for example the SunSpec (modbus standard for solar systems) > >> specification it states: > >> > >> *6.1.1 **Modbus Address Location* > >> *All Modbus device maps MUST be in the holding register address space.* > >> *The beginning of the device Modbus map MUST be located at one of three > >> Modbus addresses* > >> *in the Modbus holding register address space: 0, 4 (0x9C40) or > 5 > >> (0xC350). These* > >> *Modbus addresses are the full 16-bit, 0-based addresses in the Modbus > >> protocol messages.* > >> *The first two Modbus registers at the start address MUST have the > >> following well-known* > >> *constant values as a marker: 0x5375, 0x6E53 (hexadecimal values of the > >> ASCII string SunS).* > >> > >> > >> On my solar inverter if I request 2 registers at 4 I get the > mentioned > >> 0x5375, 0x6E53. > >> Yet with plc4j/modbus I must specify address 40001 because the library > >> shifts it by one. > >> It took me the better part of today to figure that one out. > >> > >> Niels > >> > >> On Sat, Jan 7, 2023 at 6:13 PM Niclas Hedhman > wrote: > >> > >>> > >>> I am not sure what you are asking; But Modbus documentation addresses > >>> are (in my experience) always offset by 1, which I think goes back to > >>> the 1970s when we weren't yet sure whether numbers started at 0 or at > 1, > >>> and number ranges were a scarce resource so we wouldn't sacrifice one > >>> for consistency... Those were the days. > >>> > >>> Niclas > >>> > >>> On 2023-01-07 17:27, Niels Basjes wrote: > Hi, > > I ran into the effect that all modbus addresses I specify are shifted > down > by 1. > This turns out to be code in most of the ModbusTag implementations > (not > all) which have a PROTOCOL_ADDRESS_OFFSET to shift it by. > > Why was this done? > If I'm writing software to read modbus addresses and I follow t
Re: Extending Configuration to include Connection String
Hi, Thanks Chris, yeah that's what I ended up doing, thanks. Ben On Sat, Jan 7, 2023 at 8:46 PM Christofer Dutz wrote: > Hi all and sorry for being late to the party .. > > I do think we had some reasoning behind not having this information in the > Configuration. But it should also be possible to access the information in > the driver. > For example, in the ADS driver in the code for setting up the AMS routes I > use this code to access the properties: > > > SocketAddress localSocketAddress = context.getChannel().localAddress(); > InetAddress localAddress = ((InetSocketAddress) > localSocketAddress).getAddress(); > > Perhaps that helps? > > Chris > > > > From: jl hong > Date: Saturday, 7. January 2023 at 10:46 > To: dev@plc4x.apache.org > Subject: Re: Extending Configuration to include Connection String > Hi Ben, > > In your case, it seems like a good idea to keep them in the > Configuration.😎 > > Jinlin > > Ben Hutcheson 於 2023年1月7日 週六 下午5:37寫道： > > > Hi Jinlin, > > > > Yeah we do parse the string and get those values, however currently we > > don't save them in the configuration for later use. > > > > Although I have been playing around this morning with getting the values > > from the netty channel that is created. I might just use this instead. > > > > thanks > > > > Ben > > > > On Sat, Jan 7, 2023 at 10:28 AM jl hong wrote: > > > > > Hi Ben, > > > > > > I see we parse the connection string as a URL, and it contains IP, > port, > > > and protocol. Did you mean we needn’t parse it again? > > > > > > Jinlin > > > > > > Ben Hutcheson 於 2023年1月7日 週六 下午3:05寫道： > > > > > > > Hi, > > > > > > > > There's been a few times where I have had to pass the connection > string > > > > information through to the driver logic to be used in the connection > > > phase. > > > > For OPC-UA it's passed as a string through to the OPCUA device to > help > > > > select the correct endpoint. As well as now in the Profinet driver as > > we > > > > need to create multiple sockets and use multiple protocols to create > > the > > > > connection, some of which we need to know what interface we would > like > > to > > > > listen on. > > > > > > > > I propose to extend the Configuration interface to include the > > connection > > > > string information such as the ip address, port and transport. This > way > > > I'm > > > > not recreating the getConnection logic for each driver. > > > > > > > > What are peoples thoughts? > > > > > > > > Ben > > > > > > > > > >
Re: [DISCUSS] Refactor the PlcDriverManager in Java?
Hey Chris, I second approach with interfaces as it clearly cuts implementation and declaration of operations. It could also help people who use OSGi because making a PlcDriverManager valid osgi service will be easier (lighter) with interface. It boils down to runtime where proxy for interface type is built in JVM while proxy for class involves cglib/asm etc. Best, Łukasz On 8.01.2023 15:35, Christofer Dutz wrote: Hi all, I’m currently working on a new Connection Cache for Java and have stumbled over two things: The one is the fact, that the PlcDriverManager is a class and not an interface. This makes it problematic for me to have the PlcDriverManager implement the same interface. I could probably override every method, so this is not a big problem. However, having a PlcDriverManager interface would be the cleaner solution. This would require us to change the name of the current PlcDriverManager class to something like DefaultPlcDriverManager… this would be a breaking change. Another is that the getConnection doesn’t return a Future … the main reason for this was the try-with-resources pattern, that automatically closes the PlcConnection returned from getConnection. However, returning a future might be the better option and it would be more like in the other languages. Especially when we’re working with cached connections. Here a client might be waiting a while till it gets a connection handle. This also would be a breaking change. What do you folks think? Chris
Re: Modbus addresses offset by 1?
Based on my own experience with modbus devices - you might also face situation where manufacturer starts addressing with own offset by not following official guidance. A fairly common practice I observed is use of addresses ie. 0, 1, 4 for coil/input/holding which are being called "entity numbers". [1] Out of tens of modbus devices I interfaced with I had a matching combination of manufacturer docs, library approach and actual device addresses once or twice. Speaking here about heat pumps, inverters, electric meters and PLCs, all are subject of same trouble. Maybe implementing whole driver is not needed as you can try to use optimizer which lives between your program code and driver and can re-arrange fields/tags before they reach device? Best, Łukasz [1] https://en.wikipedia.org/wiki/Modbus#Entity_numbers_and_addresses On 8.01.2023 12:27, Niels Basjes wrote: Hi, Understood. Keep the offset it is. But why does the ModbusTagExtendedRegister not have this shift? Is that a bug? Also there are a few other problems I found in this area, one is that the getAddressString will yield a different address (which is also unparsable). I'll see if I can fix those. Niels On Sat, Jan 7, 2023 at 8:35 PM Christofer Dutz wrote: Hi all, yeah … just wanted to say … this stupid offset is by spec that way. I would say, that in this case we have two different specs with a common base. Perhaps if we had “variants” of drivers, we could make different assumptions. If you get a Modbus TCP connection things are the way, they currently are. If you get a Modbus TCP connection with “SunSpec” variant, then you don’t have the offsets. Cause … if we undid the “+1” shift, then other would start complaining because their specked registers are in different locations. I have also heard that for EIP for full support of the PLC features, we’ll have to have Allen Bradley, Schneider Electric variants next to the default ones. I was told most of the major vendors do all the complex types and browsing differently :-( Chris From: Niels Basjes Date: Saturday, 7. January 2023 at 18:31 To: dev@plc4x.apache.org Subject: Re: Modbus addresses offset by 1? Ok, the "off by one" problem is ancient. Looking around the internet I read that in the past when register 123 was needed you would have to request for 122 over modbus. I find the transition from the logical number to the technical number a responsibility of the application, not of this library. Take for example the SunSpec (modbus standard for solar systems) specification it states: *6.1.1 **Modbus Address Location* *All Modbus device maps MUST be in the holding register address space.* *The beginning of the device Modbus map MUST be located at one of three Modbus addresses* *in the Modbus holding register address space: 0, 4 (0x9C40) or 5 (0xC350). These* *Modbus addresses are the full 16-bit, 0-based addresses in the Modbus protocol messages.* *The first two Modbus registers at the start address MUST have the following well-known* *constant values as a marker: 0x5375, 0x6E53 (hexadecimal values of the ASCII string SunS).* On my solar inverter if I request 2 registers at 4 I get the mentioned 0x5375, 0x6E53. Yet with plc4j/modbus I must specify address 40001 because the library shifts it by one. It took me the better part of today to figure that one out. Niels On Sat, Jan 7, 2023 at 6:13 PM Niclas Hedhman wrote: I am not sure what you are asking; But Modbus documentation addresses are (in my experience) always offset by 1, which I think goes back to the 1970s when we weren't yet sure whether numbers started at 0 or at 1, and number ranges were a scarce resource so we wouldn't sacrifice one for consistency... Those were the days. Niclas On 2023-01-07 17:27, Niels Basjes wrote: Hi, I ran into the effect that all modbus addresses I specify are shifted down by 1. This turns out to be code in most of the ModbusTag implementations (not all) which have a PROTOCOL_ADDRESS_OFFSET to shift it by. Why was this done? If I'm writing software to read modbus addresses and I follow the manufacturer specified information it will run into unexpected effects (like I have today). Also: Now getAddressString() yields something different then what I used to build the tag with. -- Best regards / Met vriendelijke groeten, Niels Basjes
[GitHub] [plc4x] chrisdutz merged pull request #732: fix(plc4j/modbus): Cleanup of ModbusTag
chrisdutz merged PR #732: URL: https://github.com/apache/plc4x/pull/732 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [DISCUSS] Refactor the PlcDriverManager in Java?
I just noticed, that the PlcDriverManager currently does more stuff than we need for the caches. So, I simply created a PlcConnectionManager interface with the two getConnection methods. This way we don’t even have to refactor anything, and problem number 1 is solved. From: Christofer Dutz Date: Sunday, 8. January 2023 at 15:36 To: dev@plc4x.apache.org Subject: [DISCUSS] Refactor the PlcDriverManager in Java? Hi all, I’m currently working on a new Connection Cache for Java and have stumbled over two things: The one is the fact, that the PlcDriverManager is a class and not an interface. This makes it problematic for me to have the PlcDriverManager implement the same interface. I could probably override every method, so this is not a big problem. However, having a PlcDriverManager interface would be the cleaner solution. This would require us to change the name of the current PlcDriverManager class to something like DefaultPlcDriverManager… this would be a breaking change. Another is that the getConnection doesn’t return a Future … the main reason for this was the try-with-resources pattern, that automatically closes the PlcConnection returned from getConnection. However, returning a future might be the better option and it would be more like in the other languages. Especially when we’re working with cached connections. Here a client might be waiting a while till it gets a connection handle. This also would be a breaking change. What do you folks think? Chris
[GitHub] [plc4x] nielsbasjes commented on pull request #732: fix(plc4j/modbus): Cleanup of ModbusTag
nielsbasjes commented on PR #732: URL: https://github.com/apache/plc4x/pull/732#issuecomment-1374852494 Usually I'm happy to contribute. Right now I would like to focus on the actual application code I'm building (in Java). So currently I won't be digging in to the Go/C/Rust code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [plc4x] chrisdutz commented on pull request #732: fix(plc4j/modbus): Cleanup of ModbusTag
chrisdutz commented on PR #732: URL: https://github.com/apache/plc4x/pull/732#issuecomment-1374851509 Thank you for those changes :-) And I guess ... if you would like to get started in Plc4go, I would be happy to assist you ... PLC4C right now is probably not really worth the effort. It's a pretty "experimental" thing which might even be replaced by PLC4Rust once that's done. If you're not interested, no worries :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[DISCUSS] Refactor the PlcDriverManager in Java?
Hi all, I’m currently working on a new Connection Cache for Java and have stumbled over two things: The one is the fact, that the PlcDriverManager is a class and not an interface. This makes it problematic for me to have the PlcDriverManager implement the same interface. I could probably override every method, so this is not a big problem. However, having a PlcDriverManager interface would be the cleaner solution. This would require us to change the name of the current PlcDriverManager class to something like DefaultPlcDriverManager… this would be a breaking change. Another is that the getConnection doesn’t return a Future … the main reason for this was the try-with-resources pattern, that automatically closes the PlcConnection returned from getConnection. However, returning a future might be the better option and it would be more like in the other languages. Especially when we’re working with cached connections. Here a client might be waiting a while till it gets a connection handle. This also would be a breaking change. What do you folks think? Chris
[GitHub] [plc4x] nielsbasjes commented on pull request #732: fix(plc4j/modbus): Cleanup of ModbusTag
nielsbasjes commented on PR #732: URL: https://github.com/apache/plc4x/pull/732#issuecomment-1374851037 I have put up some additional changes with a getAddressStringPrefix() method. About the C and Go code ... I have never written any Go code yet and the last time I touched C/C++ was > 20 years ago. At this point I don't even know the basics of the build systems that are used (I assume things have changed since 2003). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [plc4x] chrisdutz commented on pull request #732: fix(plc4j/modbus): Cleanup of ModbusTag
chrisdutz commented on PR #732: URL: https://github.com/apache/plc4x/pull/732#issuecomment-1374845489 And just asking ... would you feel able to do the same for the PLC4Go and/or PLC4C implementation? We're trying to keep them as in-sync as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [plc4x] nielsbasjes opened a new pull request, #732: fix(plc4j/modbus): Cleanup of ModbusTag
nielsbasjes opened a new pull request, #732: URL: https://github.com/apache/plc4x/pull/732 This is my proposed set of (what I think are) improvements for the ModbusTag code. Summary: - The equals and hashcode were incorrect because the name of the actual class also matters. - My take on reducing the confusion around the -1 offset and the code complexity around all of this: - Simplified the code for readability - There is now a getLogicalAddress which returns the address the user configured. - The getAddressString returns a string that parses (which was not the case) AND yields an identical new tag when parsed (which was not the case: was shifted by 1 most of the time). - A more extensive set of tests that verifies all of this and ensures all supported formats for all tags yield the correct tag that is identical regardless of the used format. Looking forward to your feedback. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Working on a new Scraper and Connection Cache
Maybe some more explanation on what I see problematic with the current connection cache. >From the documentation on a first glance, it looks as if it works this way: https://plc4x.apache.org/users/tools/connection-cache.html However, when using it you need to create a dedicated CachedDriverManager for every connection string. Which you then again ask for “getConnection” and pass in the same connection string. I think the cache should simply decorate a normal connection manager and handle any connection url. Chris From: Christofer Dutz Date: Sunday, 8. January 2023 at 12:46 To: dev@plc4x.apache.org Subject: Working on a new Scraper and Connection Cache Hi all, we currently support two variants of the Pool/Cache I guess our users are a bit unsure about how to use them and which to use. I recently implemented a connection-cache for PLC4Go and having just used the Java version of the cache, I admittedly am not very happy with the API. It was pretty confusing to say the least. So, I am thinking of implementing a cache with a similar API as the PLC4Go version. Here you create it sort of as a decorator for the DriverManager … you simply ask this for “getConnection” and you get one back, just the same way you would with the driver-manager. Also, I would finally like to start working on a new Scraper. The old one I was hoping for someone to step up and help improve it, but I’m sort of giving up on that idea. Unfortunately, the cache and the scraper are sort of the core for all integration modules that we have and it will be even more important for my work on the Apache Historian. So, my plans are to build something where you can provide sets of resources to read and the triggers that cause the set of resources to be read. This trigger can be polling an address, subscribing to an address or a timer-based thing. Just to give you folks a heads-up on this. The final goal of this is to replace the old scraper and remove the connection pool and the connection cache. So I’ll be working on a branch till I’m finished. Chris
Working on a new Scraper and Connection Cache
Hi all, we currently support two variants of the Pool/Cache I guess our users are a bit unsure about how to use them and which to use. I recently implemented a connection-cache for PLC4Go and having just used the Java version of the cache, I admittedly am not very happy with the API. It was pretty confusing to say the least. So, I am thinking of implementing a cache with a similar API as the PLC4Go version. Here you create it sort of as a decorator for the DriverManager … you simply ask this for “getConnection” and you get one back, just the same way you would with the driver-manager. Also, I would finally like to start working on a new Scraper. The old one I was hoping for someone to step up and help improve it, but I’m sort of giving up on that idea. Unfortunately, the cache and the scraper are sort of the core for all integration modules that we have and it will be even more important for my work on the Apache Historian. So, my plans are to build something where you can provide sets of resources to read and the triggers that cause the set of resources to be read. This trigger can be polling an address, subscribing to an address or a timer-based thing. Just to give you folks a heads-up on this. The final goal of this is to replace the old scraper and remove the connection pool and the connection cache. So I’ll be working on a branch till I’m finished. Chris
Re: Modbus addresses offset by 1?
Hi, Understood. Keep the offset it is. But why does the ModbusTagExtendedRegister not have this shift? Is that a bug? Also there are a few other problems I found in this area, one is that the getAddressString will yield a different address (which is also unparsable). I'll see if I can fix those. Niels On Sat, Jan 7, 2023 at 8:35 PM Christofer Dutz wrote: > Hi all, > > yeah … just wanted to say … this stupid offset is by spec that way. > I would say, that in this case we have two different specs with a common > base. > Perhaps if we had “variants” of drivers, we could make different > assumptions. > > If you get a Modbus TCP connection things are the way, they currently are. > If you get a Modbus TCP connection with “SunSpec” variant, then you don’t > have the offsets. > > Cause … if we undid the “+1” shift, then other would start complaining > because their specked registers are in different locations. > > I have also heard that for EIP for full support of the PLC features, we’ll > have to have Allen Bradley, Schneider Electric variants next to the default > ones. > I was told most of the major vendors do all the complex types and browsing > differently :-( > > Chris > > From: Niels Basjes > Date: Saturday, 7. January 2023 at 18:31 > To: dev@plc4x.apache.org > Subject: Re: Modbus addresses offset by 1? > Ok, the "off by one" problem is ancient. > Looking around the internet I read that in the past when register 123 was > needed you would have to request for 122 over modbus. > > I find the transition from the logical number to the technical number a > responsibility of the application, not of this library. > Take for example the SunSpec (modbus standard for solar systems) > specification it states: > > *6.1.1 **Modbus Address Location* > *All Modbus device maps MUST be in the holding register address space.* > *The beginning of the device Modbus map MUST be located at one of three > Modbus addresses* > *in the Modbus holding register address space: 0, 4 (0x9C40) or 5 > (0xC350). These* > *Modbus addresses are the full 16-bit, 0-based addresses in the Modbus > protocol messages.* > *The first two Modbus registers at the start address MUST have the > following well-known* > *constant values as a marker: 0x5375, 0x6E53 (hexadecimal values of the > ASCII string SunS).* > > > On my solar inverter if I request 2 registers at 4 I get the mentioned > 0x5375, 0x6E53. > Yet with plc4j/modbus I must specify address 40001 because the library > shifts it by one. > It took me the better part of today to figure that one out. > > Niels > > On Sat, Jan 7, 2023 at 6:13 PM Niclas Hedhman wrote: > > > > > I am not sure what you are asking; But Modbus documentation addresses > > are (in my experience) always offset by 1, which I think goes back to > > the 1970s when we weren't yet sure whether numbers started at 0 or at 1, > > and number ranges were a scarce resource so we wouldn't sacrifice one > > for consistency... Those were the days. > > > > Niclas > > > > On 2023-01-07 17:27, Niels Basjes wrote: > > > Hi, > > > > > > I ran into the effect that all modbus addresses I specify are shifted > > > down > > > by 1. > > > This turns out to be code in most of the ModbusTag implementations (not > > > all) which have a PROTOCOL_ADDRESS_OFFSET to shift it by. > > > > > > Why was this done? > > > If I'm writing software to read modbus addresses and I follow the > > > manufacturer specified information it will run into unexpected effects > > > (like I have today). > > > > > > Also: Now getAddressString() yields something different then what I > > > used > > > to build the tag with. > > > > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes > -- Best regards / Met vriendelijke groeten, Niels Basjes
