Hi Cesar,
Thanks for that input. I'll try digging through it.
But I think we have to distinguish between the datatypes on the plc and the
datatypes in the plc4x api.
Is live to use pure iec61131 for the communication between the api and the user
application. The drivers than should take care o
Maximilian created PLC4X-343:
Summary: Issue with Modbus Write -- PLC Connection Exception:
Error Creating Channel
Key: PLC4X-343
URL: https://issues.apache.org/jira/browse/PLC4X-343
Project: Apache PLC4X
Andy, I'm not sure if you're aware but there is a scraper
https://plc4x.apache.org/users/tools/scraper.html which you can use to
continuously poll data even when the driver doesn't support subscriptions.
On Mon, May 30, 2022 at 7:42 AM Łukasz Dywicki wrote:
> The simulation of subscriptions requ
The simulation of subscriptions require probably more options than just
"event" or so. You probably need to configure higher frequency for
polling and ideally manage thread pool for that independently from
netty/connection itself to have control over its reliability.
If I could have one sugges
hmmm... I should probably push those CIP changes first :)
On Wed, May 25, 2022 at 10:14 AM Christofer Dutz
wrote:
> Hi Andy,
>
> It still is our plan :-)
>
> Just nobody did it yet ;-)
>
> Chris
>
> -Original Message-
> From: Andy Grebe
> Sent: Mittwoch, 25. Mai 2022 15:58
> To: dev@pl
Hello Chris,
The application of IEC61131-3 for PLC manufacturers has always been a
history of "what I have and do not want to change" with respect to "what
should be".
The best example is my dear Simatic, which Siemens says complies with
IEC61131-3 [1], but when you go to reality it doesn't look
Hi ... I just wrote down everything here:
https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
Chris
-Original Message-
From: Christofer Dutz
Sent: Sonntag, 29. Mai 2022 18:09
To: dev@plc4x.apache.org
Subject: RE: [DISCUSS] how to read boo
I wrote down all the bit, byte etc. related stuff here:
https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
As I saw that in Can and KNX there are some types where byte is used for
transporting raw data, I would propose to add a new type: "RAW" w
Ups ... sorry ... yeah ... the 17bits was miss-typed, should have been 16
-Original Message-
From: jl hong
Sent: Donnerstag, 5. Mai 2022 06:01
To: dev@plc4x.apache.org
Subject: Re: [DISCUSS] how to read bool and bool-arrays?
Sorry, I forgot to answer in English, embarrassing 😅
I also
And I just stumbled over something related to this:
If we have a dataIo case of type "List", then we currently can't control the
type of the individual elements.
Currently the code uses the default PlcValue type defined for a given "uint 8"
or "float 32" type. But this might not be what we want.
And I guess we would also have to discuss what's going to be the default
behaviour when reading something like:
BYTE[3] ... will this be 3 lists of each 8 bits, one list of 24 bits, or a list
of 3 signed/unsigned values.
Chris
-Original Message-
From: Christofer Dutz
Sent: Sonntag, 2
Hi all,
today again I'm wasting lots of time trying to align the way we are handling
bit strings :-(
According to IEC61131 the types: BYTE, WORD, DWORD and LWORD are bit strings
... therefore series of bits.
However, many people treat BYTE as a numeric value.
That's actually what USINT (Unsigne
12 matches
Mail list logo