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/08/02 14:10:36 UTC
How to handle datatype optimizations
Hi all,
I just had a little technical discussion with Sebastian and I thought it would be worth to include you guys.
We were discussing how we handle datatypes and optimized access to fields.
Sebastian is currently working on the Modbus integration. Here digital inputs can be accessed via so-called coils which are nothing else than Boolean values.
The main point of the discussion was, that I initially had the position, that if I want to read multiple consequent bits, that I should be able to for example read one or more bytes.
As I know that for Siemens this is exactly how reading the Boolean values is used quite often. My argument was that I would like PLC4X to allow the same optimizations no matter what protocol we are using.
But in this discussion, Sebastian managed to convince me that it is indeed better to not do this.
During this discussion I realized that I was doing some sort of optimization I knew the driver could support for one protocol and forcing the other drivers to allow the same.
If I want to read multiple consequent bits, for example, I should implement my application to do exactly that.
Optimizing the access path to group multiple bits to one byte request should be handled by the driver.
This would be the only true driver-independent way to implement the application.
I know that the way Siemens memory is setup, I could not prevent someone from reading all digital inputs in one byte, but the request going over the wire should be exactly the same if I request one byte or I request 8 subsequent bits because ideally the driver should perform the optimization for me. We will have to implement this sort of optimization anyway as if I read bytes 2,3,4,6 it is always better to simply read one array containing bytes 2-6 and simply ignore byte 5.
Do you agree on this?
Chris
Re: How to handle datatype optimizations
Posted by Otto Fowler <ot...@gmail.com>.
Sorry for the late reply, but I don’t see anyone else replying ( I’m trying
to catch up )
Can you sum up what you are trying to say?
On August 2, 2018 at 10:10:50, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi all,
I just had a little technical discussion with Sebastian and I thought it
would be worth to include you guys.
We were discussing how we handle datatypes and optimized access to fields.
Sebastian is currently working on the Modbus integration. Here digital
inputs can be accessed via so-called coils which are nothing else than
Boolean values.
The main point of the discussion was, that I initially had the position,
that if I want to read multiple consequent bits, that I should be able to
for example read one or more bytes.
As I know that for Siemens this is exactly how reading the Boolean values
is used quite often. My argument was that I would like PLC4X to allow the
same optimizations no matter what protocol we are using.
But in this discussion, Sebastian managed to convince me that it is indeed
better to not do this.
During this discussion I realized that I was doing some sort of
optimization I knew the driver could support for one protocol and forcing
the other drivers to allow the same.
If I want to read multiple consequent bits, for example, I should implement
my application to do exactly that.
Optimizing the access path to group multiple bits to one byte request
should be handled by the driver.
This would be the only true driver-independent way to implement the
application.
I know that the way Siemens memory is setup, I could not prevent someone
from reading all digital inputs in one byte, but the request going over the
wire should be exactly the same if I request one byte or I request 8
subsequent bits because ideally the driver should perform the optimization
for me. We will have to implement this sort of optimization anyway as if I
read bytes 2,3,4,6 it is always better to simply read one array containing
bytes 2-6 and simply ignore byte 5.
Do you agree on this?
Chris