Re: [DISCUSS] Possible changes to discriminator field handling

Can you give examples? On August 25, 2020 at 19:22:40, Łukasz Dywicki (l...@code-house.org) wrote: I been trying to write new mspecs and I found that discriminator handling is quite limiting in current form. For example it is possible to declare a type argument, but it is not possible to use

Re: Protocol encapsulation

I would rather have multiple, clean drivers than one that is so complicated myself. Maybe if there was a way to structure the mspec’s such that you could re-use or re-combine them ( ie have multiple mspecs that in some combinations generate different drivers ). On August 25, 2020 at 19:11:34,

[DISCUSS] Possible changes to discriminator field handling

I been trying to write new mspecs and I found that discriminator handling is quite limiting in current form. For example it is possible to declare a type argument, but it is not possible to use it as a divider. It is also not possible to use a virtual or manual field as a discriminator which

Protocol encapsulation

I come to a point where I need to brainstorm a little bit. I started my inspection of CANopen and it looks like a whole new thing which is built on top of CAN. What's worth to remember is fact that CANbus has many flavors and transport layer can be pretty much anything. Anything means serial

Re: Leaking nioEventLoopGroup threads

Also thanks to you, Stefano, indeed for the nice community work you do! Julian Von: Stefano Bossi Datum: Dienstag, 25. August 2020 um 20:20 An: , Adam Rossi , Julian Feinauer Betreff: Re: Leaking nioEventLoopGroup threads Yupiii !!! good news !!! Regards, S. On 25/08/2020 15:45, Adam

Re: Leaking nioEventLoopGroup threads

Yupiii !!! good news !!! Regards, S. On 25/08/2020 15:45, Adam Rossi wrote: > Juilan, > > My apologies - your fix did indeed work. The issue is that > PooledPlcDriverManager does not seem to be calling the close method on the > connection. Switching back to PlcDriverManager from

Re: Leaking nioEventLoopGroup threads

Hi Adam, sorry form y late response and in facgt thanks for your feedback, happy to hear! I will merge my branch and close the issue, no worries. And you are exactly right, just log another issue fort he Pool and we hope that someone may find the time to have a look there : ) Julian PS.: As

Re: Leaking nioEventLoopGroup threads

Juilan, My apologies - your fix did indeed work. The issue is that PooledPlcDriverManager does not seem to be calling the close method on the connection. Switching back to PlcDriverManager from PooledPlcDriverManager results in your new log comments showing up in the log, and more importantly no

[jira] [Created] (PLC4X-242) nioEventLoopGroup thread leak

Adam Rossi created PLC4X-242: Summary: nioEventLoopGroup thread leak Key: PLC4X-242 URL: https://issues.apache.org/jira/browse/PLC4X-242 Project: Apache PLC4X Issue Type: Bug

Re: Leaking nioEventLoopGroup threads

Hi Adam, it's much better to not forget your problem if you open a new ticket on Jira. here is the link: https://issues.apache.org/jira/projects/PLC4X/summary You should open an account a copy your mail in there. Just a suggestion to keep the things in order. Thanks, S. On 24/08/2020 17:26,

[GitHub] [plc4x] chrisdutz opened a new pull request #181: Feature/plc4c

chrisdutz opened a new pull request #181: URL: https://github.com/apache/plc4x/pull/181 Working on implementing the S7 and the Modbus driver using the generated code. This is an automated message from the Apache Git

Re: Re: plc4j in osgi env

Hi Chris, i will try the Kar bundles of the driver Many thanks, Jeff > -原始邮件- > 发件人: "Christofer Dutz" > 发送时间: 2020-08-25 14:40:21 (星期二) > 收件人: "dev@plc4x.apache.org" > 抄送: > 主题: Re: plc4j in osgi env > > You could try out the Kar bundles every driver should produce. Not 100% sure