You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2018/07/05 09:15:30 UTC
Handling of Datatypes in Drivers
Hi all,
Sebastian and I just had a little off-list discussion and I’m taking this back to the list to get your opinion.
The issue we were discussing is that for example in the S7 driver, we are mapping all supported PLC4X datatypes to corresponding S7 datatypes.
Now there are generally two options:
* For every driver, create code to map all PLC4X supported datatypes to corresponding datatypes
* For every driver to use only the supported types and to throw exceptions for all unsupported ones.
Now I definitely generally favor the first option. As it’s one of PLC4X’s unique selling points that you can write code for any PLC without knowing the details of the protocol used.
This would be violated by the second option, in my opinion, because changing from S7 to Modbus for example would require a change of code, if we were reading a Byte for accessing the 8 Boolean digital input values at once.
If a user wants to for example write a Byte, Integer, Double to a Modbus Coil (Boolean), then I think PLC4X should map a single byte write request into 8 Boolean ones (The larger ones mapped accordingly).
Regarding Floating-Point numbers and Time values however I would not 100% insist on this, because not all PLCs support these and converting a Double into a Boolean pattern doesn’t really make sense, same with converting a Time into a Boolean value (Converting this into an Long however could make sense)
What do you others think?
Chris
Re: Handling of Datatypes in Drivers
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Wrong Thread I guess!?
> Am 09.07.2018 um 12:44 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> If you login to jenkins, you can see the current site here:
>
>
>
> https://builds.apache.org/view/M-R/job/PLC4X/job/PLC4X%20site%20(custom%20skin)/ws/target/site/index.html
>
>
>
> Chris
>
>
>
> Am 09.07.18, 11:05 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>
>
> Ping? Any opinions on this topic?
>
>
>
>
>
>
>
> Chris
>
>
>
>
>
>
>
> Am 05.07.18, 11:15 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>
>
>
>
>
>
> Hi all,
>
>
>
>
>
>
>
> Sebastian and I just had a little off-list discussion and I’m taking this back to the list to get your opinion.
>
>
>
>
>
>
>
> The issue we were discussing is that for example in the S7 driver, we are mapping all supported PLC4X datatypes to corresponding S7 datatypes.
>
>
>
>
>
>
>
> Now there are generally two options:
>
>
>
>
>
>
>
> * For every driver, create code to map all PLC4X supported datatypes to corresponding datatypes
>
>
>
> * For every driver to use only the supported types and to throw exceptions for all unsupported ones.
>
>
>
>
>
>
>
> Now I definitely generally favor the first option. As it’s one of PLC4X’s unique selling points that you can write code for any PLC without knowing the details of the protocol used.
>
>
>
> This would be violated by the second option, in my opinion, because changing from S7 to Modbus for example would require a change of code, if we were reading a Byte for accessing the 8 Boolean digital input values at once.
>
>
>
>
>
>
>
> If a user wants to for example write a Byte, Integer, Double to a Modbus Coil (Boolean), then I think PLC4X should map a single byte write request into 8 Boolean ones (The larger ones mapped accordingly).
>
>
>
>
>
>
>
> Regarding Floating-Point numbers and Time values however I would not 100% insist on this, because not all PLCs support these and converting a Double into a Boolean pattern doesn’t really make sense, same with converting a Time into a Boolean value (Converting this into an Long however could make sense)
>
>
>
>
>
>
>
> What do you others think?
>
>
>
>
>
>
>
> Chris
>
>
>
>
>
>
>
>
>
>
>
>
Re: Handling of Datatypes in Drivers
Posted by Christofer Dutz <ch...@c-ware.de>.
If you login to jenkins, you can see the current site here:
https://builds.apache.org/view/M-R/job/PLC4X/job/PLC4X%20site%20(custom%20skin)/ws/target/site/index.html
Chris
Am 09.07.18, 11:05 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Ping? Any opinions on this topic?
Chris
Am 05.07.18, 11:15 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi all,
Sebastian and I just had a little off-list discussion and I’m taking this back to the list to get your opinion.
The issue we were discussing is that for example in the S7 driver, we are mapping all supported PLC4X datatypes to corresponding S7 datatypes.
Now there are generally two options:
* For every driver, create code to map all PLC4X supported datatypes to corresponding datatypes
* For every driver to use only the supported types and to throw exceptions for all unsupported ones.
Now I definitely generally favor the first option. As it’s one of PLC4X’s unique selling points that you can write code for any PLC without knowing the details of the protocol used.
This would be violated by the second option, in my opinion, because changing from S7 to Modbus for example would require a change of code, if we were reading a Byte for accessing the 8 Boolean digital input values at once.
If a user wants to for example write a Byte, Integer, Double to a Modbus Coil (Boolean), then I think PLC4X should map a single byte write request into 8 Boolean ones (The larger ones mapped accordingly).
Regarding Floating-Point numbers and Time values however I would not 100% insist on this, because not all PLCs support these and converting a Double into a Boolean pattern doesn’t really make sense, same with converting a Time into a Boolean value (Converting this into an Long however could make sense)
What do you others think?
Chris
Re: Handling of Datatypes in Drivers
Posted by Sebastian Rühl <se...@googlemail.com.INVALID>.
Hi Chris,
Currently I prefer using on RequestItem for one coil value as it would get too confusing writing coils.
For example writing then a 42 to a coil address in modbus would mean setting the 3, 5 and 7th coil.
Writing coils requires a quantity which is mapped by the number of items time being. How would you map this in the 42 case?
8 coil fixed? 7 coils depending on the last ‚true‘ value. So IMHO the current solution is the best to just use on item on coil. One thing we could do is something like c logic where 0 =! true.
All in all the modbus implementation is still a WIP and maybe we find better solutions when we have more and more practical use cases.
Sebastian
> Am 09.07.2018 um 11:04 schrieb Christofer Dutz <ch...@c-ware.de>:
>
> Ping? Any opinions on this topic?
>
>
>
> Chris
>
>
>
> Am 05.07.18, 11:15 schrieb "Christofer Dutz" <ch...@c-ware.de>:
>
>
>
> Hi all,
>
>
>
> Sebastian and I just had a little off-list discussion and I’m taking this back to the list to get your opinion.
>
>
>
> The issue we were discussing is that for example in the S7 driver, we are mapping all supported PLC4X datatypes to corresponding S7 datatypes.
>
>
>
> Now there are generally two options:
>
>
>
> * For every driver, create code to map all PLC4X supported datatypes to corresponding datatypes
>
> * For every driver to use only the supported types and to throw exceptions for all unsupported ones.
>
>
>
> Now I definitely generally favor the first option. As it’s one of PLC4X’s unique selling points that you can write code for any PLC without knowing the details of the protocol used.
>
> This would be violated by the second option, in my opinion, because changing from S7 to Modbus for example would require a change of code, if we were reading a Byte for accessing the 8 Boolean digital input values at once.
>
>
>
> If a user wants to for example write a Byte, Integer, Double to a Modbus Coil (Boolean), then I think PLC4X should map a single byte write request into 8 Boolean ones (The larger ones mapped accordingly).
>
>
>
> Regarding Floating-Point numbers and Time values however I would not 100% insist on this, because not all PLCs support these and converting a Double into a Boolean pattern doesn’t really make sense, same with converting a Time into a Boolean value (Converting this into an Long however could make sense)
>
>
>
> What do you others think?
>
>
>
> Chris
>
>
>
>
Re: Handling of Datatypes in Drivers
Posted by Christofer Dutz <ch...@c-ware.de>.
Ping? Any opinions on this topic?
Chris
Am 05.07.18, 11:15 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi all,
Sebastian and I just had a little off-list discussion and I’m taking this back to the list to get your opinion.
The issue we were discussing is that for example in the S7 driver, we are mapping all supported PLC4X datatypes to corresponding S7 datatypes.
Now there are generally two options:
* For every driver, create code to map all PLC4X supported datatypes to corresponding datatypes
* For every driver to use only the supported types and to throw exceptions for all unsupported ones.
Now I definitely generally favor the first option. As it’s one of PLC4X’s unique selling points that you can write code for any PLC without knowing the details of the protocol used.
This would be violated by the second option, in my opinion, because changing from S7 to Modbus for example would require a change of code, if we were reading a Byte for accessing the 8 Boolean digital input values at once.
If a user wants to for example write a Byte, Integer, Double to a Modbus Coil (Boolean), then I think PLC4X should map a single byte write request into 8 Boolean ones (The larger ones mapped accordingly).
Regarding Floating-Point numbers and Time values however I would not 100% insist on this, because not all PLCs support these and converting a Double into a Boolean pattern doesn’t really make sense, same with converting a Time into a Boolean value (Converting this into an Long however could make sense)
What do you others think?
Chris