[GitHub] [plc4x] dependabot[bot] opened a new pull request, #725: build(deps): bump error_prone_annotations from 2.16 to 2.17.0
dependabot[bot] opened a new pull request, #725: URL: https://github.com/apache/plc4x/pull/725 Bumps [error_prone_annotations](https://github.com/google/error-prone) from 2.16 to 2.17.0. Release notes Sourced from https://github.com/google/error-prone/releases;>error_prone_annotations's releases. Error Prone 2.17.0 New Checkers: https://errorprone.info/bugpattern/AvoidObjectArrays;>AvoidObjectArrays https://errorprone.info/bugpattern/Finalize;>Finalize https://errorprone.info/bugpattern/IgnoredPureGetter;>IgnoredPureGetter https://errorprone.info/bugpattern/ProtoFieldNullComparison;>ImpossibleNullComparison https://errorprone.info/bugpattern/MathAbsoluteNegative;>MathAbsoluteNegative https://errorprone.info/bugpattern/NewFileSystem;>NewFileSystem https://errorprone.info/bugpattern/StatementSwitchToExpressionSwitch;>StatementSwitchToExpressionSwitch https://errorprone.info/bugpattern/UnqualifiedYield;>UnqualifiedYield Fixed issues: https://github-redirect.dependabot.com/google/error-prone/issues/2321;>#2321, https://github-redirect.dependabot.com/google/error-prone/issues/3144;>#3144, https://github-redirect.dependabot.com/google/error-prone/issues/3297;>#3297, https://github-redirect.dependabot.com/google/error-prone/issues/3428;>#3428, https://github-redirect.dependabot.com/google/error-prone/issues/3437;>#3437, https://github-redirect.dependabot.com/google/error-prone/issues/3462;>#3462, https://github-redirect.dependabot.com/google/error-prone/issues/3482;>#3482, https://github-redirect.dependabot.com/google/error-prone/issues/3494;>#3494 Full Changelog: https://github.com/google/error-prone/compare/v2.16...v2.17.0;>https://github.com/google/error-prone/compare/v2.16...v2.17.0 Commits https://github.com/google/error-prone/commit/27de40ba6008f967c01a55ec83c9127419bfe433;>27de40b Release Error Prone 2.17.0 https://github.com/google/error-prone/commit/bcf4dcf764082def27ad14b47128fae52fe6fe46;>bcf4dcf Optimize checks that report exactly the same fix in multiple diagnostics, lik... https://github.com/google/error-prone/commit/8ddb7cbb05dc4b278836fd5019751c4e225323d9;>8ddb7cb Record Error Prone initialization time https://github.com/google/error-prone/commit/1d23141bd74663ad12e20534d062bef223df6efa;>1d23141 Do the expensive bit last in UnusedMethod. https://github.com/google/error-prone/commit/e3602572b020ae24c617b02676caa1993fba753a;>e360257 Fix yet another NonCanonicalType crash https://github.com/google/error-prone/commit/5768290a151ac8e76ed5a2593239fef2cfcadb44;>5768290 Make UnusedMethod recognize com.google.acai annotations, com.google.caliper.B... https://github.com/google/error-prone/commit/7340bdf01ddbc43dd8aaaf8eb97d28cd3f18;>7340bdf Audit EP checks for argumentless mock(). https://github.com/google/error-prone/commit/b92c9b1b55502de311d0d379b1dc2d0b2293f96b;>b92c9b1 Rip out GuardedBy:CheckMemberReferences. https://github.com/google/error-prone/commit/63fb30be3fb8dcda83ec339d769ddb9649ac3e6b;>63fb30b Have InvalidLink provide a hint about erasure if it sees in an invalid meth... https://github.com/google/error-prone/commit/4a5fd7bd5a1fc9d1eadcb9e0b963a06d35a3f01b;>4a5fd7b Suppress FieldCanBeLocal based on unused prefices. Additional commits viewable in https://github.com/google/error-prone/compare/v2.16...v2.17.0;>compare view [](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
Re: Interpreting the modbus registers.
Thanks On Mon, Jan 2, 2023 at 2:35 PM Christofer Dutz wrote: > That went off too soon … > > https://en.wikipedia.org/wiki/IEC_61131-3 > > Even if we initially had different type names for each driver, we sort of > consolidated on using the IEC defaults. > However, this doesn’t mean that we can only use these. It should be > possible to support additional type names. > > From what I read from the spec you referenced, it shouldn’t be too > difficult: > > Int16=INT > Uint16=UINT > BitField16=WORD > Int32=DINT > Uint32=UDINT > BitField32=DWORD > … > Float32=REAL > > Just the Arc and the Enum types I don’t quite know what they are and the > scale-factors I haven’t seen before. > > I would assume a simple translation from the SunSpec names to > IEC/PLC4X-Names should get most of the job done. > I haven’t tested reading strings however. > > But in general, I would say: If there’s a need to do so, PLC4X would 100% > be extendible to support different types of encoding schemes. > Even if it meant having multiple DataIo implementations. > > https://github.com/apache/plc4x/blob/develop/protocols/modbus/src/main/resources/protocols/modbus/modbus.mspec#L311 > > > Chris > > > > > > > > From: Christofer Dutz > Date: Monday, 2. January 2023 at 14:28 > To: dev@plc4x.apache.org > Subject: Re: Interpreting the modbus registers. > Hi Nils, > > As it’s the goal of PLC4X to have a shared API over many protocols. We > sort of settled on using this as a reference for the supported types: > > From: Niels Basjes > Date: Monday, 2. January 2023 at 13:33 > To: dev@plc4x.apache.org > Subject: Re: Interpreting the modbus registers. > Hi, > > Just as background info: > The Sunspec modbus spec is a standardized way of doing modbus for energy > equipment across many vendors with lots of different features. It also has > types like a `string` which is a sequence of modbus registers which are > then interpreted as ASCII (used for serial numbers, brand names) and a type > for an IPv6 address (and many others). > > https://sunspec.org/ > > https://sunspec.org/wp-content/uploads/2015/06/SunSpec-Information-Models-12041.pdf > https://github.com/sunspec/models > > Long ago I wrote some code to handle modbus for Sunspec (for my Solar > panels at home) and my SDM630 (which measures the power usage of my > Geothermal Heatpump at home) > See: https://github.com/nielsbasjes/energy > > I recently got a new Heatpump which supports modbus itself and decided to > write some code for that thing too and cleanup/refactor/reconsider the code > I wrote a few years ago. > As part of this reconsidering I'm having a close look at this project. > > How does the plc4x project look at having these kinds of very specific > decoders as part of this project ? > Or do you prefer to have them outside this project ? > > Niels > > On Mon, Jan 2, 2023 at 1:00 PM Christofer Dutz > wrote: > > > Hi Niels, > > > > and welcome to the plc4x community :-) > > > > In general, we already have a general-purpose mapping layer. However, > it’s > > not as universal as you would need for that given use-case. > > So, if for example you read a register as type “REAL” it will > > automatically fetch two registers and interpret the two as 32bit floating > > point number. > > > > However, in your case you currently would need to manually do the > > conversion. Unfortunately, I don’t know the “sunspec”, so not 100% sure > how > > this is encoded. > > > > Does that help? > > > > Chris > > > > > > > > From: Niels Basjes > > Date: Monday, 2. January 2023 at 12:48 > > To: dev@plc4x.apache.org > > Subject: Interpreting the modbus registers. > > Hi, > > > > The modbus protocol simply talks about 1 bit coils and 16 bit registers > and > > are retrieved and written back. > > Modbus does not assign any meaning to these bits so real applications > need > > a translation from these register bits to usable values. > > In some cases the meaning of the bits even varies with the content of > other > > registers; For example the sunspec has a "scaling factor" which indicates > > how much 10^X a field must be multiplied to get the real value. > > > > Is there a generic example on how to implement such a mapping layer > cleanly > > with plc4j? > > > > I did have a look at the OPM feature but that retrieves all values one by > > one; I want all measurements retrieved at the 'exact' same instant. > > > > -- > > Best regards / Met vriendelijke groeten, > > > > Niels Basjes > > > > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes > -- Best regards / Met vriendelijke groeten, Niels Basjes
[GitHub] [plc4x] chrisdutz commented on pull request #724: fix: Improve java example
chrisdutz commented on PR #724: URL: https://github.com/apache/plc4x/pull/724#issuecomment-1368977436 And expanding all of the code ... yes ... your soltion is nicer ... just noticed it was a new future you were getting ;-) So yes ... I think that option is nicer. -- 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 #724: fix: Improve java example
chrisdutz commented on PR #724: URL: https://github.com/apache/plc4x/pull/724#issuecomment-1368975821 Well admittedly the sleep doesn't make any sense with the async stuff commented out. Not quite sure why it's commented out at all. If we call "get" then the whole point of doing it asynchronously is lost. But I think it makes sense to add a second example demonstrating the async behaviour. Perhaps with a hook that waits on a signal (strg+c) to shut down. -- 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: Simple modbus application does not terminate
+1 -> thank you Niels :-)
Am Mo., 2. Jan. 2023 um 15:02 Uhr schrieb Niels Basjes :
> Thanks for clarifying.
> I've added this to the example (+ cleanups):
> https://github.com/apache/plc4x/pull/724
>
> On Mon, Jan 2, 2023 at 2:43 PM Christofer Dutz
> wrote:
>
> > Hi Niels,
> >
> > If you find the time to have a little bit deeper look and find a solution
> > … we’re super happy about PRs ;-)
> > This behavior is sort of know behavior and we never really got to
> > addressing it. I would assume it’s generally because of some Netty-Crap
> … I
> > would so love to get rid of Netty.
> >
> > Chris
> >
> >
> >
> > From: Niels Basjes
> > Date: Monday, 2. January 2023 at 14:41
> > To: dev@plc4x.apache.org
> > Subject: Re: Simple modbus application does not terminate
> > I found a workaround by digging through the example code:
> > End the application with an explicit System.exit(0);
> >
> >
> >
> https://github.com/apache/plc4x/blob/b784dedaa787e52e7907085bf096e8ea2e093f3b/plc4j/examples/hello-world-plc4x-read/src/main/java/org/apache/plc4x/java/examples/helloplc4x/read/HelloPlc4xRead.java#L93
> >
> > Then it does terminate the application.
> >
> > Niels
> >
> >
> > On Mon, Jan 2, 2023 at 12:30 PM Niels Basjes wrote:
> >
> > > Hi,
> > >
> > > I'm trying out building some stuff using plc4j/modbus and I have some
> > > questions about that.
> > >
> > > I created a very simple test that connects using modbus-tcp and
> retrieves
> > > some registers.
> > > Essentially it is this example (using the latest snapshot) but with
> > modbus
> > > https://plc4x.apache.org/users/getting-started/plc4j.html
> > > So I use this connect string "modbus-tcp:tcp://127.0.0.1:1502" and
> > > request ModbusTag.of("3x1:UINT[100]").
> > >
> > > The problem I have is that after the data has been read and printed
> > (which
> > > works as expected) the application does not terminate.
> > >
> > >
> > > In the console I see (among other things) at the start:
> > > 12:17:11,811 [INFO ] PlcDriverManager: 48:
> > > Instantiating new PLC Driver Manager with class loader
> > > jdk.internal.loader.ClassLoaders$AppClassLoader@251a69d7
> > > 12:17:11,813 [INFO ] PlcDriverManager: 52:
> > > Registering available drivers...
> > > 12:17:11,818 [INFO ] PlcDriverManager: 59:
> > > Registering driver for Protocol modbus-ascii (Modbus ASCII)
> > > 12:17:11,819 [INFO ] PlcDriverManager: 59:
> > > Registering driver for Protocol modbus-rtu (Modbus RTU)
> > > 12:17:11,820 [INFO ] PlcDriverManager: 59:
> > > Registering driver for Protocol modbus-tcp (Modbus TCP)
> > > 12:17:11,921 [INFO ] TcpChannelFactory : 60:
> > > Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000,
> > > unitIdentifier=1}
> > >
> > > and after my application finished
> > >
> > > 12:17:18,022 [INFO ] NettyChannelFactory : 150:
> > > Channel is closed, closing worker Group also
> > > 12:17:20,025 [INFO ] NettyChannelFactory : 154:
> > > Worker Group was closed successfully!
> > >
> > > and then it just waits...
> > >
> > > When using the debugger in IntelliJ I press pause and have a look at
> the
> > > threads it seems to me it is stuck in some kind of cleanup I do not
> > > understand.
> > > There is actually a thread called DestroyJavaVM so sounds like outside
> of
> > > my actual application.
> > >
> > > How do I fix this?
> > >
> > > --
> > > Best regards / Met vriendelijke groeten,
> > >
> > > Niels Basjes
> > >
> >
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
> >
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
Re: Simple modbus application does not terminate
Thanks for clarifying.
I've added this to the example (+ cleanups):
https://github.com/apache/plc4x/pull/724
On Mon, Jan 2, 2023 at 2:43 PM Christofer Dutz
wrote:
> Hi Niels,
>
> If you find the time to have a little bit deeper look and find a solution
> … we’re super happy about PRs ;-)
> This behavior is sort of know behavior and we never really got to
> addressing it. I would assume it’s generally because of some Netty-Crap … I
> would so love to get rid of Netty.
>
> Chris
>
>
>
> From: Niels Basjes
> Date: Monday, 2. January 2023 at 14:41
> To: dev@plc4x.apache.org
> Subject: Re: Simple modbus application does not terminate
> I found a workaround by digging through the example code:
> End the application with an explicit System.exit(0);
>
>
> https://github.com/apache/plc4x/blob/b784dedaa787e52e7907085bf096e8ea2e093f3b/plc4j/examples/hello-world-plc4x-read/src/main/java/org/apache/plc4x/java/examples/helloplc4x/read/HelloPlc4xRead.java#L93
>
> Then it does terminate the application.
>
> Niels
>
>
> On Mon, Jan 2, 2023 at 12:30 PM Niels Basjes wrote:
>
> > Hi,
> >
> > I'm trying out building some stuff using plc4j/modbus and I have some
> > questions about that.
> >
> > I created a very simple test that connects using modbus-tcp and retrieves
> > some registers.
> > Essentially it is this example (using the latest snapshot) but with
> modbus
> > https://plc4x.apache.org/users/getting-started/plc4j.html
> > So I use this connect string "modbus-tcp:tcp://127.0.0.1:1502" and
> > request ModbusTag.of("3x1:UINT[100]").
> >
> > The problem I have is that after the data has been read and printed
> (which
> > works as expected) the application does not terminate.
> >
> >
> > In the console I see (among other things) at the start:
> > 12:17:11,811 [INFO ] PlcDriverManager: 48:
> > Instantiating new PLC Driver Manager with class loader
> > jdk.internal.loader.ClassLoaders$AppClassLoader@251a69d7
> > 12:17:11,813 [INFO ] PlcDriverManager: 52:
> > Registering available drivers...
> > 12:17:11,818 [INFO ] PlcDriverManager: 59:
> > Registering driver for Protocol modbus-ascii (Modbus ASCII)
> > 12:17:11,819 [INFO ] PlcDriverManager: 59:
> > Registering driver for Protocol modbus-rtu (Modbus RTU)
> > 12:17:11,820 [INFO ] PlcDriverManager: 59:
> > Registering driver for Protocol modbus-tcp (Modbus TCP)
> > 12:17:11,921 [INFO ] TcpChannelFactory : 60:
> > Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000,
> > unitIdentifier=1}
> >
> > and after my application finished
> >
> > 12:17:18,022 [INFO ] NettyChannelFactory : 150:
> > Channel is closed, closing worker Group also
> > 12:17:20,025 [INFO ] NettyChannelFactory : 154:
> > Worker Group was closed successfully!
> >
> > and then it just waits...
> >
> > When using the debugger in IntelliJ I press pause and have a look at the
> > threads it seems to me it is stuck in some kind of cleanup I do not
> > understand.
> > There is actually a thread called DestroyJavaVM so sounds like outside of
> > my actual application.
> >
> > How do I fix this?
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
> >
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
[GitHub] [plc4x] nielsbasjes opened a new pull request, #724: fix: Improve java example
nielsbasjes opened a new pull request, #724: URL: https://github.com/apache/plc4x/pull/724 Some improvements in the example: - No need for close in a try-with-resources block. - Move the exit outside the try-with-resources block. - Use the CompletableFuture (which is the actual return type of execute) which has a `get()` that waits for the completion --> no need for an unreliable sleep. - Document the need for the exit explicitly -- 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: Simple modbus application does not terminate
Hi Niels,
If you find the time to have a little bit deeper look and find a solution …
we’re super happy about PRs ;-)
This behavior is sort of know behavior and we never really got to addressing
it. I would assume it’s generally because of some Netty-Crap … I would so love
to get rid of Netty.
Chris
From: Niels Basjes
Date: Monday, 2. January 2023 at 14:41
To: dev@plc4x.apache.org
Subject: Re: Simple modbus application does not terminate
I found a workaround by digging through the example code:
End the application with an explicit System.exit(0);
https://github.com/apache/plc4x/blob/b784dedaa787e52e7907085bf096e8ea2e093f3b/plc4j/examples/hello-world-plc4x-read/src/main/java/org/apache/plc4x/java/examples/helloplc4x/read/HelloPlc4xRead.java#L93
Then it does terminate the application.
Niels
On Mon, Jan 2, 2023 at 12:30 PM Niels Basjes wrote:
> Hi,
>
> I'm trying out building some stuff using plc4j/modbus and I have some
> questions about that.
>
> I created a very simple test that connects using modbus-tcp and retrieves
> some registers.
> Essentially it is this example (using the latest snapshot) but with modbus
> https://plc4x.apache.org/users/getting-started/plc4j.html
> So I use this connect string "modbus-tcp:tcp://127.0.0.1:1502" and
> request ModbusTag.of("3x1:UINT[100]").
>
> The problem I have is that after the data has been read and printed (which
> works as expected) the application does not terminate.
>
>
> In the console I see (among other things) at the start:
> 12:17:11,811 [INFO ] PlcDriverManager: 48:
> Instantiating new PLC Driver Manager with class loader
> jdk.internal.loader.ClassLoaders$AppClassLoader@251a69d7
> 12:17:11,813 [INFO ] PlcDriverManager: 52:
> Registering available drivers...
> 12:17:11,818 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-ascii (Modbus ASCII)
> 12:17:11,819 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-rtu (Modbus RTU)
> 12:17:11,820 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-tcp (Modbus TCP)
> 12:17:11,921 [INFO ] TcpChannelFactory : 60:
> Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000,
> unitIdentifier=1}
>
> and after my application finished
>
> 12:17:18,022 [INFO ] NettyChannelFactory : 150:
> Channel is closed, closing worker Group also
> 12:17:20,025 [INFO ] NettyChannelFactory : 154:
> Worker Group was closed successfully!
>
> and then it just waits...
>
> When using the debugger in IntelliJ I press pause and have a look at the
> threads it seems to me it is stuck in some kind of cleanup I do not
> understand.
> There is actually a thread called DestroyJavaVM so sounds like outside of
> my actual application.
>
> How do I fix this?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Simple modbus application does not terminate
I found a workaround by digging through the example code:
End the application with an explicit System.exit(0);
https://github.com/apache/plc4x/blob/b784dedaa787e52e7907085bf096e8ea2e093f3b/plc4j/examples/hello-world-plc4x-read/src/main/java/org/apache/plc4x/java/examples/helloplc4x/read/HelloPlc4xRead.java#L93
Then it does terminate the application.
Niels
On Mon, Jan 2, 2023 at 12:30 PM Niels Basjes wrote:
> Hi,
>
> I'm trying out building some stuff using plc4j/modbus and I have some
> questions about that.
>
> I created a very simple test that connects using modbus-tcp and retrieves
> some registers.
> Essentially it is this example (using the latest snapshot) but with modbus
> https://plc4x.apache.org/users/getting-started/plc4j.html
> So I use this connect string "modbus-tcp:tcp://127.0.0.1:1502" and
> request ModbusTag.of("3x1:UINT[100]").
>
> The problem I have is that after the data has been read and printed (which
> works as expected) the application does not terminate.
>
>
> In the console I see (among other things) at the start:
> 12:17:11,811 [INFO ] PlcDriverManager: 48:
> Instantiating new PLC Driver Manager with class loader
> jdk.internal.loader.ClassLoaders$AppClassLoader@251a69d7
> 12:17:11,813 [INFO ] PlcDriverManager: 52:
> Registering available drivers...
> 12:17:11,818 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-ascii (Modbus ASCII)
> 12:17:11,819 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-rtu (Modbus RTU)
> 12:17:11,820 [INFO ] PlcDriverManager: 59:
> Registering driver for Protocol modbus-tcp (Modbus TCP)
> 12:17:11,921 [INFO ] TcpChannelFactory : 60:
> Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000,
> unitIdentifier=1}
>
> and after my application finished
>
> 12:17:18,022 [INFO ] NettyChannelFactory : 150:
> Channel is closed, closing worker Group also
> 12:17:20,025 [INFO ] NettyChannelFactory : 154:
> Worker Group was closed successfully!
>
> and then it just waits...
>
> When using the debugger in IntelliJ I press pause and have a look at the
> threads it seems to me it is stuck in some kind of cleanup I do not
> understand.
> There is actually a thread called DestroyJavaVM so sounds like outside of
> my actual application.
>
> How do I fix this?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Interpreting the modbus registers.
That went off too soon … https://en.wikipedia.org/wiki/IEC_61131-3 Even if we initially had different type names for each driver, we sort of consolidated on using the IEC defaults. However, this doesn’t mean that we can only use these. It should be possible to support additional type names. >From what I read from the spec you referenced, it shouldn’t be too difficult: Int16=INT Uint16=UINT BitField16=WORD Int32=DINT Uint32=UDINT BitField32=DWORD … Float32=REAL Just the Arc and the Enum types I don’t quite know what they are and the scale-factors I haven’t seen before. I would assume a simple translation from the SunSpec names to IEC/PLC4X-Names should get most of the job done. I haven’t tested reading strings however. But in general, I would say: If there’s a need to do so, PLC4X would 100% be extendible to support different types of encoding schemes. Even if it meant having multiple DataIo implementations. https://github.com/apache/plc4x/blob/develop/protocols/modbus/src/main/resources/protocols/modbus/modbus.mspec#L311 Chris From: Christofer Dutz Date: Monday, 2. January 2023 at 14:28 To: dev@plc4x.apache.org Subject: Re: Interpreting the modbus registers. Hi Nils, As it’s the goal of PLC4X to have a shared API over many protocols. We sort of settled on using this as a reference for the supported types: From: Niels Basjes Date: Monday, 2. January 2023 at 13:33 To: dev@plc4x.apache.org Subject: Re: Interpreting the modbus registers. Hi, Just as background info: The Sunspec modbus spec is a standardized way of doing modbus for energy equipment across many vendors with lots of different features. It also has types like a `string` which is a sequence of modbus registers which are then interpreted as ASCII (used for serial numbers, brand names) and a type for an IPv6 address (and many others). https://sunspec.org/ https://sunspec.org/wp-content/uploads/2015/06/SunSpec-Information-Models-12041.pdf https://github.com/sunspec/models Long ago I wrote some code to handle modbus for Sunspec (for my Solar panels at home) and my SDM630 (which measures the power usage of my Geothermal Heatpump at home) See: https://github.com/nielsbasjes/energy I recently got a new Heatpump which supports modbus itself and decided to write some code for that thing too and cleanup/refactor/reconsider the code I wrote a few years ago. As part of this reconsidering I'm having a close look at this project. How does the plc4x project look at having these kinds of very specific decoders as part of this project ? Or do you prefer to have them outside this project ? Niels On Mon, Jan 2, 2023 at 1:00 PM Christofer Dutz wrote: > Hi Niels, > > and welcome to the plc4x community :-) > > In general, we already have a general-purpose mapping layer. However, it’s > not as universal as you would need for that given use-case. > So, if for example you read a register as type “REAL” it will > automatically fetch two registers and interpret the two as 32bit floating > point number. > > However, in your case you currently would need to manually do the > conversion. Unfortunately, I don’t know the “sunspec”, so not 100% sure how > this is encoded. > > Does that help? > > Chris > > > > From: Niels Basjes > Date: Monday, 2. January 2023 at 12:48 > To: dev@plc4x.apache.org > Subject: Interpreting the modbus registers. > Hi, > > The modbus protocol simply talks about 1 bit coils and 16 bit registers and > are retrieved and written back. > Modbus does not assign any meaning to these bits so real applications need > a translation from these register bits to usable values. > In some cases the meaning of the bits even varies with the content of other > registers; For example the sunspec has a "scaling factor" which indicates > how much 10^X a field must be multiplied to get the real value. > > Is there a generic example on how to implement such a mapping layer cleanly > with plc4j? > > I did have a look at the OPM feature but that retrieves all values one by > one; I want all measurements retrieved at the 'exact' same instant. > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes > -- Best regards / Met vriendelijke groeten, Niels Basjes
[GitHub] [plc4x] dependabot[bot] commented on pull request #709: build(deps): bump camel.version from 3.19.0 to 3.20.0
dependabot[bot] commented on PR #709: URL: https://github.com/apache/plc4x/pull/709#issuecomment-1368953230 OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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] hutcheb closed pull request #709: build(deps): bump camel.version from 3.19.0 to 3.20.0
hutcheb closed pull request #709: build(deps): bump camel.version from 3.19.0 to 3.20.0 URL: https://github.com/apache/plc4x/pull/709 -- 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: Interpreting the modbus registers.
Hi Nils, As it’s the goal of PLC4X to have a shared API over many protocols. We sort of settled on using this as a reference for the supported types: From: Niels Basjes Date: Monday, 2. January 2023 at 13:33 To: dev@plc4x.apache.org Subject: Re: Interpreting the modbus registers. Hi, Just as background info: The Sunspec modbus spec is a standardized way of doing modbus for energy equipment across many vendors with lots of different features. It also has types like a `string` which is a sequence of modbus registers which are then interpreted as ASCII (used for serial numbers, brand names) and a type for an IPv6 address (and many others). https://sunspec.org/ https://sunspec.org/wp-content/uploads/2015/06/SunSpec-Information-Models-12041.pdf https://github.com/sunspec/models Long ago I wrote some code to handle modbus for Sunspec (for my Solar panels at home) and my SDM630 (which measures the power usage of my Geothermal Heatpump at home) See: https://github.com/nielsbasjes/energy I recently got a new Heatpump which supports modbus itself and decided to write some code for that thing too and cleanup/refactor/reconsider the code I wrote a few years ago. As part of this reconsidering I'm having a close look at this project. How does the plc4x project look at having these kinds of very specific decoders as part of this project ? Or do you prefer to have them outside this project ? Niels On Mon, Jan 2, 2023 at 1:00 PM Christofer Dutz wrote: > Hi Niels, > > and welcome to the plc4x community :-) > > In general, we already have a general-purpose mapping layer. However, it’s > not as universal as you would need for that given use-case. > So, if for example you read a register as type “REAL” it will > automatically fetch two registers and interpret the two as 32bit floating > point number. > > However, in your case you currently would need to manually do the > conversion. Unfortunately, I don’t know the “sunspec”, so not 100% sure how > this is encoded. > > Does that help? > > Chris > > > > From: Niels Basjes > Date: Monday, 2. January 2023 at 12:48 > To: dev@plc4x.apache.org > Subject: Interpreting the modbus registers. > Hi, > > The modbus protocol simply talks about 1 bit coils and 16 bit registers and > are retrieved and written back. > Modbus does not assign any meaning to these bits so real applications need > a translation from these register bits to usable values. > In some cases the meaning of the bits even varies with the content of other > registers; For example the sunspec has a "scaling factor" which indicates > how much 10^X a field must be multiplied to get the real value. > > Is there a generic example on how to implement such a mapping layer cleanly > with plc4j? > > I did have a look at the OPM feature but that retrieves all values one by > one; I want all measurements retrieved at the 'exact' same instant. > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes > -- Best regards / Met vriendelijke groeten, Niels Basjes
Re: Interpreting the modbus registers.
Hi, Just as background info: The Sunspec modbus spec is a standardized way of doing modbus for energy equipment across many vendors with lots of different features. It also has types like a `string` which is a sequence of modbus registers which are then interpreted as ASCII (used for serial numbers, brand names) and a type for an IPv6 address (and many others). https://sunspec.org/ https://sunspec.org/wp-content/uploads/2015/06/SunSpec-Information-Models-12041.pdf https://github.com/sunspec/models Long ago I wrote some code to handle modbus for Sunspec (for my Solar panels at home) and my SDM630 (which measures the power usage of my Geothermal Heatpump at home) See: https://github.com/nielsbasjes/energy I recently got a new Heatpump which supports modbus itself and decided to write some code for that thing too and cleanup/refactor/reconsider the code I wrote a few years ago. As part of this reconsidering I'm having a close look at this project. How does the plc4x project look at having these kinds of very specific decoders as part of this project ? Or do you prefer to have them outside this project ? Niels On Mon, Jan 2, 2023 at 1:00 PM Christofer Dutz wrote: > Hi Niels, > > and welcome to the plc4x community :-) > > In general, we already have a general-purpose mapping layer. However, it’s > not as universal as you would need for that given use-case. > So, if for example you read a register as type “REAL” it will > automatically fetch two registers and interpret the two as 32bit floating > point number. > > However, in your case you currently would need to manually do the > conversion. Unfortunately, I don’t know the “sunspec”, so not 100% sure how > this is encoded. > > Does that help? > > Chris > > > > From: Niels Basjes > Date: Monday, 2. January 2023 at 12:48 > To: dev@plc4x.apache.org > Subject: Interpreting the modbus registers. > Hi, > > The modbus protocol simply talks about 1 bit coils and 16 bit registers and > are retrieved and written back. > Modbus does not assign any meaning to these bits so real applications need > a translation from these register bits to usable values. > In some cases the meaning of the bits even varies with the content of other > registers; For example the sunspec has a "scaling factor" which indicates > how much 10^X a field must be multiplied to get the real value. > > Is there a generic example on how to implement such a mapping layer cleanly > with plc4j? > > I did have a look at the OPM feature but that retrieves all values one by > one; I want all measurements retrieved at the 'exact' same instant. > > -- > Best regards / Met vriendelijke groeten, > > Niels Basjes > -- Best regards / Met vriendelijke groeten, Niels Basjes
Re: Interpreting the modbus registers.
Hi Niels, and welcome to the plc4x community :-) In general, we already have a general-purpose mapping layer. However, it’s not as universal as you would need for that given use-case. So, if for example you read a register as type “REAL” it will automatically fetch two registers and interpret the two as 32bit floating point number. However, in your case you currently would need to manually do the conversion. Unfortunately, I don’t know the “sunspec”, so not 100% sure how this is encoded. Does that help? Chris From: Niels Basjes Date: Monday, 2. January 2023 at 12:48 To: dev@plc4x.apache.org Subject: Interpreting the modbus registers. Hi, The modbus protocol simply talks about 1 bit coils and 16 bit registers and are retrieved and written back. Modbus does not assign any meaning to these bits so real applications need a translation from these register bits to usable values. In some cases the meaning of the bits even varies with the content of other registers; For example the sunspec has a "scaling factor" which indicates how much 10^X a field must be multiplied to get the real value. Is there a generic example on how to implement such a mapping layer cleanly with plc4j? I did have a look at the OPM feature but that retrieves all values one by one; I want all measurements retrieved at the 'exact' same instant. -- Best regards / Met vriendelijke groeten, Niels Basjes
Simple modbus application does not terminate
Hi,
I'm trying out building some stuff using plc4j/modbus and I have some
questions about that.
I created a very simple test that connects using modbus-tcp and retrieves
some registers.
Essentially it is this example (using the latest snapshot) but with modbus
https://plc4x.apache.org/users/getting-started/plc4j.html
So I use this connect string "modbus-tcp:tcp://127.0.0.1:1502" and request
ModbusTag.of("3x1:UINT[100]").
The problem I have is that after the data has been read and printed (which
works as expected) the application does not terminate.
In the console I see (among other things) at the start:
12:17:11,811 [INFO ] PlcDriverManager: 48:
Instantiating new PLC Driver Manager with class loader
jdk.internal.loader.ClassLoaders$AppClassLoader@251a69d7
12:17:11,813 [INFO ] PlcDriverManager: 52:
Registering available drivers...
12:17:11,818 [INFO ] PlcDriverManager: 59:
Registering driver for Protocol modbus-ascii (Modbus ASCII)
12:17:11,819 [INFO ] PlcDriverManager: 59:
Registering driver for Protocol modbus-rtu (Modbus RTU)
12:17:11,820 [INFO ] PlcDriverManager: 59:
Registering driver for Protocol modbus-tcp (Modbus TCP)
12:17:11,921 [INFO ] TcpChannelFactory : 60:
Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000,
unitIdentifier=1}
and after my application finished
12:17:18,022 [INFO ] NettyChannelFactory : 150:
Channel is closed, closing worker Group also
12:17:20,025 [INFO ] NettyChannelFactory : 154: Worker
Group was closed successfully!
and then it just waits...
When using the debugger in IntelliJ I press pause and have a look at the
threads it seems to me it is stuck in some kind of cleanup I do not
understand.
There is actually a thread called DestroyJavaVM so sounds like outside of
my actual application.
How do I fix this?
--
Best regards / Met vriendelijke groeten,
Niels Basjes
