AW: Supported Datatypes for S7-1200 with PLC4J
Hmmm ok. I agree to that. Writing the bitstring with a single operation (e.g.
for reset purpose) is kind of a convenience operation. For that you simply have
to use the USINT/SINT datatype.
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 15:19
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
Well it does seem, as using BYTE for a non Bit-String in the PLC is where the
actual problem comes from ;-)
So if it's a numeric 8 bit value ... that's what USINT and SINT are there for.
I know technically it's the same and I know a lot of people seem to be using
them identically, but they technically seem to have different intentions behind
them.
But ... if everyone uses them wrong the same way, we might consider adjusting
the driver accordingly.
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 15:14
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christof,
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF); yes, that
way it works but it feels like an ugly "cast" from the software point of view.
Anyway, I can live with it for a while.
Thanks for you patience and the will to help.
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:55
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
unfortunately I think that way it won't work ... your're passing in 8 elements
and expecting it to be mapped to one element in the driver. However I currently
can't tell you which way would work.
Right now, I would suggest you try using a USINT instead of BYTE and then
simply pass in your numeric value.
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF);
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 14:51
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
ok I got it.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
However, I already tried using a List of PlcBool as follows
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", true, true, true,
true, true, true, true, true);
but this gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65)
---snap---
Another form I tried
List list = new ArrayList(Arrays.asList(new PlcBOOL(true),
new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new
PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true) ));
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", list);
This gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
java.util.ArrayList cannot be cast to class java.lang.String
(java.util.ArrayList and java.lang.String are in module java.base of loader
'bootstrap') at org.apache.plc4x.java.spi.values.PlcBYTE.of(PlcBYTE.java:61)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.of(IEC61131ValueHandler.java:129)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.newPlcValue(IEC61131ValueHandler.java:49)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:204)
at java.base/java.util.TreeMap.forEach(TreeMap.java:1002)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:199)
---snap---
Am I doing something terribly wrong here or is it simply not implemented so
far?
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:06
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for
RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
Well it does seem, as using BYTE for a non Bit-String in the PLC is where the
actual problem comes from ;-)
So if it's a numeric 8 bit value ... that's what USINT and SINT are there for.
I know technically it's the same and I know a lot of people seem to be using
them identically, but they technically seem to have different intentions behind
them.
But ... if everyone uses them wrong the same way, we might consider adjusting
the driver accordingly.
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 15:14
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christof,
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF); yes, that
way it works but it feels like an ugly "cast" from the software point of view.
Anyway, I can live with it for a while.
Thanks for you patience and the will to help.
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:55
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
unfortunately I think that way it won't work ... your're passing in 8 elements
and expecting it to be mapped to one element in the driver. However I currently
can't tell you which way would work.
Right now, I would suggest you try using a USINT instead of BYTE and then
simply pass in your numeric value.
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF);
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 14:51
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
ok I got it.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
However, I already tried using a List of PlcBool as follows
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", true, true, true,
true, true, true, true, true);
but this gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65)
---snap---
Another form I tried
List list = new ArrayList(Arrays.asList(new PlcBOOL(true),
new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new
PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true) ));
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", list);
This gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
java.util.ArrayList cannot be cast to class java.lang.String
(java.util.ArrayList and java.lang.String are in module java.base of loader
'bootstrap') at org.apache.plc4x.java.spi.values.PlcBYTE.of(PlcBYTE.java:61)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.of(IEC61131ValueHandler.java:129)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.newPlcValue(IEC61131ValueHandler.java:49)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:204)
at java.base/java.util.TreeMap.forEach(TreeMap.java:1002)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:199)
---snap---
Am I doing something terribly wrong here or is it simply not implemented so
far?
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:06
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi Markus,
BYTE, WORD and DWORD are intentionally implemented that way as in the IEC???
Spec that is how they are defined.
So if you read a USINT, SINT or BYTE should not matter on the protocol level,
In the PLCValue objects however it defines how the data is represented. So, a
BYTE being a bit-string should result in a PlcList with 8 PlcBool elements,
while one of the others
AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christof,
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF);
yes, that way it works but it feels like an ugly "cast" from the software point
of view.
Anyway, I can live with it for a while.
Thanks for you patience and the will to help.
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:55
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
unfortunately I think that way it won't work ... your're passing in 8 elements
and expecting it to be mapped to one element in the driver. However I currently
can't tell you which way would work.
Right now, I would suggest you try using a USINT instead of BYTE and then
simply pass in your numeric value.
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF);
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 14:51
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
ok I got it.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
However, I already tried using a List of PlcBool as follows
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", true, true, true,
true, true, true, true, true);
but this gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65)
---snap---
Another form I tried
List list = new ArrayList(Arrays.asList(new PlcBOOL(true),
new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new
PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true) ));
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", list);
This gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
java.util.ArrayList cannot be cast to class java.lang.String
(java.util.ArrayList and java.lang.String are in module java.base of loader
'bootstrap') at org.apache.plc4x.java.spi.values.PlcBYTE.of(PlcBYTE.java:61)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.of(IEC61131ValueHandler.java:129)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.newPlcValue(IEC61131ValueHandler.java:49)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:204)
at java.base/java.util.TreeMap.forEach(TreeMap.java:1002)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:199)
---snap---
Am I doing something terribly wrong here or is it simply not implemented so
far?
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:06
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi Markus,
BYTE, WORD and DWORD are intentionally implemented that way as in the IEC???
Spec that is how they are defined.
So if you read a USINT, SINT or BYTE should not matter on the protocol level,
In the PLCValue objects however it defines how the data is represented. So, a
BYTE being a bit-string should result in a PlcList with 8 PlcBool elements,
while one of the others should be a numeric value.
This would not be a bug, but a design decision we did to be compliant with the
specs.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 13:41
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
thanks for your clarifications regarding the limitations of the current PLC4J
implementation on S7.
Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I was
RE: Supported Datatypes for S7-1200 with PLC4J
Hi,
unfortunately I think that way it won't work ... your're passing in 8 elements
and expecting it to be mapped to one element in the driver. However I currently
can't tell you which way would work.
Right now, I would suggest you try using a USINT instead of BYTE and then
simply pass in your numeric value.
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:USINT", 0xFF);
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 14:51
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
ok I got it.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
However, I already tried using a List of PlcBool as follows
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", true, true, true,
true, true, true, true, true);
but this gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65)
---snap---
Another form I tried
List list = new ArrayList(Arrays.asList(new PlcBOOL(true),
new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new
PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true) ));
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", list);
This gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
java.util.ArrayList cannot be cast to class java.lang.String
(java.util.ArrayList and java.lang.String are in module java.base of loader
'bootstrap') at org.apache.plc4x.java.spi.values.PlcBYTE.of(PlcBYTE.java:61)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.of(IEC61131ValueHandler.java:129)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.newPlcValue(IEC61131ValueHandler.java:49)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:204)
at java.base/java.util.TreeMap.forEach(TreeMap.java:1002)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:199)
---snap---
Am I doing something terribly wrong here or is it simply not implemented so
far?
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:06
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi Markus,
BYTE, WORD and DWORD are intentionally implemented that way as in the IEC???
Spec that is how they are defined.
So if you read a USINT, SINT or BYTE should not matter on the protocol level,
In the PLCValue objects however it defines how the data is represented. So, a
BYTE being a bit-string should result in a PlcList with 8 PlcBool elements,
while one of the others should be a numeric value.
This would not be a bug, but a design decision we did to be compliant with the
specs.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 13:41
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
thanks for your clarifications regarding the limitations of the current PLC4J
implementation on S7.
Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I was
only able to read/write those bit-by-bit.
Suppose datablock 100, address 817 contains a BYTE variable. I was only able to
write to the individual bits by using the following address format
%DB100.DBX817.0:BOOL
...
%DB100.DBX817.7:BOOL
Trying to write the whole BYTE with a single operation like
%DB100.DBB817:BYTE
gives me a
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to
RE: Supported Datatypes for S7-1200 with PLC4J
Hi All, well it's the way it's currently implemented. That doesn't mean we couldn’t make the driver also handle byte, short, int as inputs. Chris -Original Message- From: Cesar Garcia Sent: Dienstag, 30. November 2021 14:41 To: Apache PLC4X Subject: Re: Supported Datatypes for S7-1200 with PLC4J Hi everyone, Markus, grateful for the table with your observations, Chris, has made the clarifications about the driver's functionalities. In particular, although IEC gives a reference to how the type should be represented, but I also find the handling of bits uncomfortable. Eventually each manufacturer accommodates it to their needs, in the end IEC is a reference, not a requirement. This is where the beauty of the PLC4X API comes in, the flexibility. I'm going to keep an eye on the type implementation, I hope it helps. I inform you this way. Kind regards, El mar, 30 nov 2021 a las 9:06, Christofer Dutz () escribió: > Hi Markus, > > BYTE, WORD and DWORD are intentionally implemented that way as in the > IEC??? Spec that is how they are defined. > So if you read a USINT, SINT or BYTE should not matter on the protocol > level, In the PLCValue objects however it defines how the data is > represented. So, a BYTE being a bit-string should result in a PlcList > with > 8 PlcBool elements, while one of the others should be a numeric value. > > This would not be a bug, but a design decision we did to be compliant > with the specs. > > So in your case, you would need to either initialize a List of PlcBool > values and write that, or you write the BYTE variable with an USINT or > SINT value. > > Chris > > > -Original Message- > From: Markus Franke > Sent: Dienstag, 30. November 2021 13:41 > To: dev@plc4x.apache.org > Subject: AW: Supported Datatypes for S7-1200 with PLC4J > > Hi Christofer, > > thanks for your clarifications regarding the limitations of the > current PLC4J implementation on S7. > > Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far > I was only able to read/write those bit-by-bit. > > Suppose datablock 100, address 817 contains a BYTE variable. I was > only able to write to the individual bits by using the following > address format > > %DB100.DBX817.0:BOOL > ... > %DB100.DBX817.7:BOOL > > Trying to write the whole BYTE with a single operation like > > %DB100.DBB817:BYTE > > gives me a > > ---snip--- > Exception in thread "main" java.lang.ClassCastException: class > org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class > org.apache.plc4x.java.spi.values.PlcList > (org.apache.plc4x.java.spi.values.PlcBYTE and > org.apache.plc4x.java.spi.values.PlcList are in unnamed module of > loader > 'app') at > org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataI > temIO.java:291) > at > org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataI > temIO.java:275) > at > org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializeP > lcValue(S7ProtocolLogic.java:862) > at > org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7Pr > otocolLogic.java:288) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrit > e$2(BaseOptimizer.java:114) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.j > ava:151) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseO > ptimizer.java:114) > at > org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(Abstr > actPlcConnection.java:159) > at > org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(Defa > ultPlcWriteRequest.java:65) > at Siemens.main(Siemens.java:61) > ---snap--- > > Similarily, for reading I receive the individual bits of the BYTE > one-by-one. However, I guess this is expected behaviour as we are > dealing with a bit-field datatype, right? > > Best regards, > Markus > > > Von: Christofer Dutz > Gesendet: Dienstag, 30. November 2021 12:59 > An: dev@plc4x.apache.org > Betreff: RE: Supported Datatypes for S7-1200 with PLC4J > > Hi, > > let me jump in here ;) > > I know with strings there are currently issues. Especially with > smaller S7 devices (which have smaller PDU Sizes). > The problem here is, that the default length of one string already > exceeds the PDU size of the S7 1200 devices I have. > So, you always must provide a max string length. As soon as you do > that, strings are unfortunately handled slightly differently. > > To support normal strings with their full length, the Query optimizer > in > S7 would need to be extended with the ability to split up individual > items into multiple parts. This is something I haven't done yet. > > To support normal strings on larger S7 devices (Where the PDU Size > allows fitting them into the request), we probably need more testing > and for that I would at least need access to such a device. > > LREAL is unfortunately not supported on the S7-1200 devices that
AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
ok I got it.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
However, I already tried using a List of PlcBool as follows
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", true, true, true,
true, true, true, true, true);
but this gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151)
at
org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114)
at
org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65)
---snap---
Another form I tried
List list = new ArrayList(Arrays.asList(new PlcBOOL(true),
new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true), new
PlcBOOL(true), new PlcBOOL(true), new PlcBOOL(true) ));
writeRequestBuilder.addItem("someByte", "%DB100.DBB817:BYTE", list);
This gives me
---snip---
Exception in thread "main" java.lang.ClassCastException: class
java.util.ArrayList cannot be cast to class java.lang.String
(java.util.ArrayList and java.lang.String are in module java.base of loader
'bootstrap')
at org.apache.plc4x.java.spi.values.PlcBYTE.of(PlcBYTE.java:61)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.of(IEC61131ValueHandler.java:129)
at
org.apache.plc4x.java.spi.values.IEC61131ValueHandler.newPlcValue(IEC61131ValueHandler.java:49)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.lambda$build$0(DefaultPlcWriteRequest.java:204)
at java.base/java.util.TreeMap.forEach(TreeMap.java:1002)
at
org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest$Builder.build(DefaultPlcWriteRequest.java:199)
---snap---
Am I doing something terribly wrong here or is it simply not implemented so
far?
Best regards,
Markus
Von: Christofer Dutz
Gesendet: Dienstag, 30. November 2021 14:06
An: dev@plc4x.apache.org
Betreff: RE: Supported Datatypes for S7-1200 with PLC4J
Hi Markus,
BYTE, WORD and DWORD are intentionally implemented that way as in the IEC???
Spec that is how they are defined.
So if you read a USINT, SINT or BYTE should not matter on the protocol level,
In the PLCValue objects however it defines how the data is represented. So, a
BYTE being a bit-string should result in a PlcList with 8 PlcBool elements,
while one of the others should be a numeric value.
This would not be a bug, but a design decision we did to be compliant with the
specs.
So in your case, you would need to either initialize a List of PlcBool values
and write that, or you write the BYTE variable with an USINT or SINT value.
Chris
-Original Message-
From: Markus Franke
Sent: Dienstag, 30. November 2021 13:41
To: dev@plc4x.apache.org
Subject: AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer,
thanks for your clarifications regarding the limitations of the current PLC4J
implementation on S7.
Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I was
only able to read/write those bit-by-bit.
Suppose datablock 100, address 817 contains a BYTE variable. I was only able to
write to the individual bits by using the following address format
%DB100.DBX817.0:BOOL
...
%DB100.DBX817.7:BOOL
Trying to write the whole BYTE with a single operation like
%DB100.DBB817:BYTE
gives me a
---snip---
Exception in thread "main" java.lang.ClassCastException: class
org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class
org.apache.plc4x.java.spi.values.PlcList
(org.apache.plc4x.java.spi.values.PlcBYTE and
org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app')
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291)
at
org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862)
at
org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288)
at
Re: Supported Datatypes for S7-1200 with PLC4J
Hi everyone, Markus, grateful for the table with your observations, Chris, has made the clarifications about the driver's functionalities. In particular, although IEC gives a reference to how the type should be represented, but I also find the handling of bits uncomfortable. Eventually each manufacturer accommodates it to their needs, in the end IEC is a reference, not a requirement. This is where the beauty of the PLC4X API comes in, the flexibility. I'm going to keep an eye on the type implementation, I hope it helps. I inform you this way. Kind regards, El mar, 30 nov 2021 a las 9:06, Christofer Dutz () escribió: > Hi Markus, > > BYTE, WORD and DWORD are intentionally implemented that way as in the > IEC??? Spec that is how they are defined. > So if you read a USINT, SINT or BYTE should not matter on the protocol > level, In the PLCValue objects however it defines how the data is > represented. So, a BYTE being a bit-string should result in a PlcList with > 8 PlcBool elements, while one of the others should be a numeric value. > > This would not be a bug, but a design decision we did to be compliant with > the specs. > > So in your case, you would need to either initialize a List of PlcBool > values and write that, or you write the BYTE variable with an USINT or SINT > value. > > Chris > > > -Original Message- > From: Markus Franke > Sent: Dienstag, 30. November 2021 13:41 > To: dev@plc4x.apache.org > Subject: AW: Supported Datatypes for S7-1200 with PLC4J > > Hi Christofer, > > thanks for your clarifications regarding the limitations of the current > PLC4J implementation on S7. > > Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I > was only able to read/write those bit-by-bit. > > Suppose datablock 100, address 817 contains a BYTE variable. I was only > able to write to the individual bits by using the following address format > > %DB100.DBX817.0:BOOL > ... > %DB100.DBX817.7:BOOL > > Trying to write the whole BYTE with a single operation like > > %DB100.DBB817:BYTE > > gives me a > > ---snip--- > Exception in thread "main" java.lang.ClassCastException: class > org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class > org.apache.plc4x.java.spi.values.PlcList > (org.apache.plc4x.java.spi.values.PlcBYTE and > org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader > 'app') at > org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291) > at > org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275) > at > org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862) > at > org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151) > at > org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114) > at > org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159) > at > org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65) > at Siemens.main(Siemens.java:61) > ---snap--- > > Similarily, for reading I receive the individual bits of the BYTE > one-by-one. However, I guess this is expected behaviour as we are dealing > with a bit-field datatype, right? > > Best regards, > Markus > > > Von: Christofer Dutz > Gesendet: Dienstag, 30. November 2021 12:59 > An: dev@plc4x.apache.org > Betreff: RE: Supported Datatypes for S7-1200 with PLC4J > > Hi, > > let me jump in here ;) > > I know with strings there are currently issues. Especially with smaller S7 > devices (which have smaller PDU Sizes). > The problem here is, that the default length of one string already exceeds > the PDU size of the S7 1200 devices I have. > So, you always must provide a max string length. As soon as you do that, > strings are unfortunately handled slightly differently. > > To support normal strings with their full length, the Query optimizer in > S7 would need to be extended with the ability to split up individual items > into multiple parts. This is something I haven't done yet. > > To support normal strings on larger S7 devices (Where the PDU Size allows > fitting them into the request), we probably need more testing and for that > I would at least need access to such a device. > > LREAL is unfortunately not supported on the S7-1200 devices that I have, > and therefore I could never really test that. Same with the Time datatypes. > > So, all in all, I thank you for your list of things we need to improve. I > promise that we will work on this. > > However, I can't give you an ETA on which I personally will be able to > work on this, as I'm currently working on other things. Perhaps someone in > the community can jump
RE: Supported Datatypes for S7-1200 with PLC4J
Hi Markus, BYTE, WORD and DWORD are intentionally implemented that way as in the IEC??? Spec that is how they are defined. So if you read a USINT, SINT or BYTE should not matter on the protocol level, In the PLCValue objects however it defines how the data is represented. So, a BYTE being a bit-string should result in a PlcList with 8 PlcBool elements, while one of the others should be a numeric value. This would not be a bug, but a design decision we did to be compliant with the specs. So in your case, you would need to either initialize a List of PlcBool values and write that, or you write the BYTE variable with an USINT or SINT value. Chris -Original Message- From: Markus Franke Sent: Dienstag, 30. November 2021 13:41 To: dev@plc4x.apache.org Subject: AW: Supported Datatypes for S7-1200 with PLC4J Hi Christofer, thanks for your clarifications regarding the limitations of the current PLC4J implementation on S7. Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I was only able to read/write those bit-by-bit. Suppose datablock 100, address 817 contains a BYTE variable. I was only able to write to the individual bits by using the following address format %DB100.DBX817.0:BOOL ... %DB100.DBX817.7:BOOL Trying to write the whole BYTE with a single operation like %DB100.DBB817:BYTE gives me a ---snip--- Exception in thread "main" java.lang.ClassCastException: class org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class org.apache.plc4x.java.spi.values.PlcList (org.apache.plc4x.java.spi.values.PlcBYTE and org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app') at org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291) at org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275) at org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862) at org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114) at org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159) at org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65) at Siemens.main(Siemens.java:61) ---snap--- Similarily, for reading I receive the individual bits of the BYTE one-by-one. However, I guess this is expected behaviour as we are dealing with a bit-field datatype, right? Best regards, Markus Von: Christofer Dutz Gesendet: Dienstag, 30. November 2021 12:59 An: dev@plc4x.apache.org Betreff: RE: Supported Datatypes for S7-1200 with PLC4J Hi, let me jump in here ;) I know with strings there are currently issues. Especially with smaller S7 devices (which have smaller PDU Sizes). The problem here is, that the default length of one string already exceeds the PDU size of the S7 1200 devices I have. So, you always must provide a max string length. As soon as you do that, strings are unfortunately handled slightly differently. To support normal strings with their full length, the Query optimizer in S7 would need to be extended with the ability to split up individual items into multiple parts. This is something I haven't done yet. To support normal strings on larger S7 devices (Where the PDU Size allows fitting them into the request), we probably need more testing and for that I would at least need access to such a device. LREAL is unfortunately not supported on the S7-1200 devices that I have, and therefore I could never really test that. Same with the Time datatypes. So, all in all, I thank you for your list of things we need to improve. I promise that we will work on this. However, I can't give you an ETA on which I personally will be able to work on this, as I'm currently working on other things. Perhaps someone in the community can jump in. Or even you might be interested in helping. If you think you are able to do that, I am more than willing to help mentor you. Chris -Original Message- From: Markus Franke Sent: Dienstag, 30. November 2021 09:34 To: dev@plc4x.apache.org Subject: AW: Supported Datatypes for S7-1200 with PLC4J Hi Cesar, so far my experiences are as follows: datatypereadwrite = BOOLok ok BYTEok ok(only bitwise) WORDok ok(only bitwise) DWORD ok ok(only bitwise) SINTok ok USINT ok ok INT ok ok UINTok ok DINTok ok UDINT ok ok REALok ok LREAL nok nok CHARok nok WCHAR ok nok STRING
AW: Supported Datatypes for S7-1200 with PLC4J
Hi Christofer, thanks for your clarifications regarding the limitations of the current PLC4J implementation on S7. Regarding the bitfield datatypes such as BYTE, WORD and DWORD, so far I was only able to read/write those bit-by-bit. Suppose datablock 100, address 817 contains a BYTE variable. I was only able to write to the individual bits by using the following address format %DB100.DBX817.0:BOOL ... %DB100.DBX817.7:BOOL Trying to write the whole BYTE with a single operation like %DB100.DBB817:BYTE gives me a ---snip--- Exception in thread "main" java.lang.ClassCastException: class org.apache.plc4x.java.spi.values.PlcBYTE cannot be cast to class org.apache.plc4x.java.spi.values.PlcList (org.apache.plc4x.java.spi.values.PlcBYTE and org.apache.plc4x.java.spi.values.PlcList are in unnamed module of loader 'app') at org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:291) at org.apache.plc4x.java.s7.readwrite.io.DataItemIO.staticSerialize(DataItemIO.java:275) at org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.serializePlcValue(S7ProtocolLogic.java:862) at org.apache.plc4x.java.s7.readwrite.protocol.S7ProtocolLogic.write(S7ProtocolLogic.java:288) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.lambda$optimizedWrite$2(BaseOptimizer.java:114) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.send(BaseOptimizer.java:151) at org.apache.plc4x.java.spi.optimizer.BaseOptimizer.optimizedWrite(BaseOptimizer.java:114) at org.apache.plc4x.java.spi.connection.AbstractPlcConnection.write(AbstractPlcConnection.java:159) at org.apache.plc4x.java.spi.messages.DefaultPlcWriteRequest.execute(DefaultPlcWriteRequest.java:65) at Siemens.main(Siemens.java:61) ---snap--- Similarily, for reading I receive the individual bits of the BYTE one-by-one. However, I guess this is expected behaviour as we are dealing with a bit-field datatype, right? Best regards, Markus Von: Christofer Dutz Gesendet: Dienstag, 30. November 2021 12:59 An: dev@plc4x.apache.org Betreff: RE: Supported Datatypes for S7-1200 with PLC4J Hi, let me jump in here ;) I know with strings there are currently issues. Especially with smaller S7 devices (which have smaller PDU Sizes). The problem here is, that the default length of one string already exceeds the PDU size of the S7 1200 devices I have. So, you always must provide a max string length. As soon as you do that, strings are unfortunately handled slightly differently. To support normal strings with their full length, the Query optimizer in S7 would need to be extended with the ability to split up individual items into multiple parts. This is something I haven't done yet. To support normal strings on larger S7 devices (Where the PDU Size allows fitting them into the request), we probably need more testing and for that I would at least need access to such a device. LREAL is unfortunately not supported on the S7-1200 devices that I have, and therefore I could never really test that. Same with the Time datatypes. So, all in all, I thank you for your list of things we need to improve. I promise that we will work on this. However, I can't give you an ETA on which I personally will be able to work on this, as I'm currently working on other things. Perhaps someone in the community can jump in. Or even you might be interested in helping. If you think you are able to do that, I am more than willing to help mentor you. Chris -Original Message- From: Markus Franke Sent: Dienstag, 30. November 2021 09:34 To: dev@plc4x.apache.org Subject: AW: Supported Datatypes for S7-1200 with PLC4J Hi Cesar, so far my experiences are as follows: datatypereadwrite = BOOLok ok BYTEok ok(only bitwise) WORDok ok(only bitwise) DWORD ok ok(only bitwise) SINTok ok USINT ok ok INT ok ok UINTok ok DINTok ok UDINT ok ok REALok ok LREAL nok nok CHARok nok WCHAR ok nok STRING nok nok WSTRING nok nok TIMEok nok DATEok nok TIME_OF_DAY ok nok So it seems like writing is currently unsupported for quite a few datatypes. Also reading (W)STRING and LREAL seems to be an issue currently. Any comments on this? Thanks in advance, Markus Von: Cesar Garcia Gesendet: Montag, 29. November 2021 17:38 An: Apache PLC4X Betreff: Re: Supported Datatypes for S7-1200 with PLC4J Hi Markus, Can you put an example of the required formats? Best regards, El lun, 29 nov 2021 a las 11:27, Markus Franke () escribió: > Dear all, > > I am currently connecting to a S7-1200 by using PLC4J 0.9.0. > > As I have problems with reading/writing certain datatypes from a > datablock, I was wondering whether there are currently any restriction > what kind
RE: Supported Datatypes for S7-1200 with PLC4J
Hi, let me jump in here ;) I know with strings there are currently issues. Especially with smaller S7 devices (which have smaller PDU Sizes). The problem here is, that the default length of one string already exceeds the PDU size of the S7 1200 devices I have. So, you always must provide a max string length. As soon as you do that, strings are unfortunately handled slightly differently. To support normal strings with their full length, the Query optimizer in S7 would need to be extended with the ability to split up individual items into multiple parts. This is something I haven't done yet. To support normal strings on larger S7 devices (Where the PDU Size allows fitting them into the request), we probably need more testing and for that I would at least need access to such a device. LREAL is unfortunately not supported on the S7-1200 devices that I have, and therefore I could never really test that. Same with the Time datatypes. So, all in all, I thank you for your list of things we need to improve. I promise that we will work on this. However, I can't give you an ETA on which I personally will be able to work on this, as I'm currently working on other things. Perhaps someone in the community can jump in. Or even you might be interested in helping. If you think you are able to do that, I am more than willing to help mentor you. Chris -Original Message- From: Markus Franke Sent: Dienstag, 30. November 2021 09:34 To: dev@plc4x.apache.org Subject: AW: Supported Datatypes for S7-1200 with PLC4J Hi Cesar, so far my experiences are as follows: datatypereadwrite = BOOLok ok BYTEok ok(only bitwise) WORDok ok(only bitwise) DWORD ok ok(only bitwise) SINTok ok USINT ok ok INT ok ok UINTok ok DINTok ok UDINT ok ok REALok ok LREAL nok nok CHARok nok WCHAR ok nok STRING nok nok WSTRING nok nok TIMEok nok DATEok nok TIME_OF_DAY ok nok So it seems like writing is currently unsupported for quite a few datatypes. Also reading (W)STRING and LREAL seems to be an issue currently. Any comments on this? Thanks in advance, Markus Von: Cesar Garcia Gesendet: Montag, 29. November 2021 17:38 An: Apache PLC4X Betreff: Re: Supported Datatypes for S7-1200 with PLC4J Hi Markus, Can you put an example of the required formats? Best regards, El lun, 29 nov 2021 a las 11:27, Markus Franke () escribió: > Dear all, > > I am currently connecting to a S7-1200 by using PLC4J 0.9.0. > > As I have problems with reading/writing certain datatypes from a > datablock, I was wondering whether there are currently any restriction > what kind of datatypes are actually supported for reading/writing with > this hardware setup? > > Thanks and best regards, > Markus > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
AW: Supported Datatypes for S7-1200 with PLC4J
Hi Cesar, so far my experiences are as follows: datatypereadwrite = BOOLok ok BYTEok ok(only bitwise) WORDok ok(only bitwise) DWORD ok ok(only bitwise) SINTok ok USINT ok ok INT ok ok UINTok ok DINTok ok UDINT ok ok REALok ok LREAL nok nok CHARok nok WCHAR ok nok STRING nok nok WSTRING nok nok TIMEok nok DATEok nok TIME_OF_DAY ok nok So it seems like writing is currently unsupported for quite a few datatypes. Also reading (W)STRING and LREAL seems to be an issue currently. Any comments on this? Thanks in advance, Markus Von: Cesar Garcia Gesendet: Montag, 29. November 2021 17:38 An: Apache PLC4X Betreff: Re: Supported Datatypes for S7-1200 with PLC4J Hi Markus, Can you put an example of the required formats? Best regards, El lun, 29 nov 2021 a las 11:27, Markus Franke () escribió: > Dear all, > > I am currently connecting to a S7-1200 by using PLC4J 0.9.0. > > As I have problems with reading/writing certain datatypes from a > datablock, I was wondering whether there are currently any restriction what > kind of datatypes are actually supported for reading/writing with this > hardware setup? > > Thanks and best regards, > Markus > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
