chrisdutz commented on PR #545:
URL: https://github.com/apache/plc4x/pull/545#issuecomment-1374593134
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.
--
This is an
chrisdutz commented on code in PR #545:
URL: https://github.com/apache/plc4x/pull/545#discussion_r1064040985
##
plc4go/protocols/modbus/readwrite/model/DataItem.go:
##
@@ -24,30 +24,48 @@ import (
"github.com/apache/plc4x/plc4go/spi/utils"
chrisdutz commented on code in PR #545:
URL: https://github.com/apache/plc4x/pull/545#discussion_r1064040882
##
plc4go/protocols/modbus/readwrite/model/DataItem.go:
##
@@ -24,30 +24,48 @@ import (
"github.com/apache/plc4x/plc4go/spi/utils"
chrisdutz commented on code in PR #545:
URL: https://github.com/apache/plc4x/pull/545#discussion_r1064040681
##
plc4go/examples/read/hello_world_plc4go_read.go:
##
@@ -31,7 +31,7 @@ func main() {
drivers.RegisterModbusTcpDriver(driverManager)
// Get a
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
Hi all,
yeah … it seems that most EIP PLCs use EIP and CIP as basis but have their own
set of services with their own IDs.
I think we might need driver variants where we use different constants for
different types of vendors.
Not sure how easily we’ll be able to auto-detect, stuff, but perhaps
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
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.
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
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
I have tried this setting change and I still got the OOM.
Niels
On Fri, Jan 6, 2023 at 8:15 PM Ben Hutcheson wrote:
> Hi Niels,
>
> I tried upgrading to 2022.3.1, which didn't seem to work. However when I
> changed the compiler within Settings->Build, Execution,
> Deployment->Compiler->Java
Ah wait, it might use a different CIP service ID (0x54 instead of 0x5B).
Is there any chance you could get us a packet capture of a successful
connection?
On Sat, Jan 7, 2023 at 1:45 PM Ben Hutcheson wrote:
> Taking a look at it within onConnectOpenConnectionManager within the
>
Taking a look at it within onConnectOpenConnectionManager within the
EipProtocolLogic class, there are a couple of 4002 values (These should
definitely be constants), but changing these to 504 should result in a
smaller message siye being used.
Let us know if this works and if you need some help
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
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
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
16 matches
Mail list logo
